PTP offload H7: one-step timestamp from HW?

[LCE]

Heyho,

a few questions to those who already used the PTP offload function (not via IP / UDP, but PTP directly over ethernet, MAC packet type 0x88F7), which can auto-generate SYNC and DelayRequest messages:

1) As this feature does not auto-generate FollowUp messages (so no "two-step" timestamp), I assume that the timestamp sent with the auto-generated SYNC message is the "exact timestamp" when the packet leaves the STM32's MAC, so that 2-step is absolutely not required ?

2) And was this ever tested at STM? -->> examples...

3) Why was no automatism created for Announce messages? (Okay, these are timing-wise not important)

Using the HW would greatly reduce speed and code size, because LWIP would be completely unused for PTP, and my modified PTPd could be reduced greatly (much less "manual" packet processing)

Anyway, one more request for example source code!

@STea please, or whoever ...

[LCE]

Next problem solved:

only in the "fine print" in a footnote one can find that the TXTSIS interrupt is only triggered for Delay Request messages. This gives the timestamp "t2".

 

Still, the documentation is missing so much info, mostly about "t0 .. t3" :

• Where do we get all the timestamps "t0 .. t3" that we need for correction (only "t2" is clear, see above) ?
• Is the timestamp we get from the RX descriptor of a SYNC message "t1" = receive time at slave, or is it the master's TX "originTimestamp" = "t0" from within the PTP message?
• If the master's TX "originTimestamp" is not in the RX descriptor (which I assume), where do I get that ? Do I have to analyse the PTP message "manually" or is there some automatism ?
• Same problem for "t3", the master's RX timestamp of the slave's delay request ?

And another one:

• What does this magic OSTC bit in TDES3 context descriptor do ? 

"bit 27 OSTC: One-Step Timestamp Correction Enable
When this bit is set, the DMA performs a one-step timestamp correction
with reference to the timestamp values provided in TDES0 and TDES1."

What actually does the DMA "correct" ?

 

What a nightmare...

[Pavel A.]

"DMA" here means the DMA sub-system of the ETH, which accesses the shared host RAM. So it has some logic that reads the PTP timestamps and writes something back. /* If you were ST, would you rigorously validate all these fine points or would accept the vendor (Synopsys) results as is? */

 

[LCE]

@Pavel A. 

>  If you were ST, would you rigorously validate all these fine points or
> would accept the vendor (Synopsys) results as is?

You're asking the wrong person, I am working on measurement &  test equipment in industrial environment, so everything we develop, build, and sell must be "rigorously validated"... :D

At least ST could have given more and better information about the hardware features. As you said, more info from Synopsis.

BTW, I contacted OLS, and they sent me PTP sources from here:
https://github.com/STMicroelectronics/x-cube-azrtos-h7/tree/main

Either I have not found it, or this simply uses PTP via UDP, so no PTP offload. :(

[LCE]

Okay, got it! 

Still using the PTPd functions for calculation and correction, but messaging all done by PTP offload.

Still having some bug, http is working, but I somehow killed my audio streaming. :(

I can only share the setup and some notes, see below.

• documentation is so poor - and that's the nice way to put it
• interestingly, path delays are about 30% smaller with offload, which should not be the case with HW timestamps, maybe the offload packets have higher priority ? or is it the router ? -> documentation, sigh...
• lots of stuff to do, right now PTP master and slave are "fixed", still have to "build" announce messages and its analysis for PTP's BMC

/* +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ */
/* PTP with H7 hardware offload

	NOTE:
		TX messages don't seem to use descriptors
		RX messages arrive normally -> RX descriptors, check PMT

	HW timestamps t0 .. t3 :

	t0 SYNC TX @ master
		slave gets this from:
			SYNC message from master
				-> RX descriptor pointer to buffer / payload

	t1 SYNC RX @ slave
		slave gets this from:
			SYNC RX DESC
				-> RX write-back descriptor TSA -> context descriptor

	t2 DEL REQ TX @ slave
		slave gets this from:
			own message:
				-> TXTSIS interrupt

	t3 DEL REQ RX @ master
		slave gets this from:
			DELAY RESPONSE message from master
				-> RX write-back descriptor pointer to buffer / payload

 */

void PtpH7HwOfflInit(uint8_t u8MstrSlv)
{
	uint32_t u32TempReg = 0;

/* MACTSCR: Timestamp control Register */
	/*	ETH_MACTSCR_SNAPTYPSEL 	= 00
	 *	ETH_MACTSCR_TSMSTRENA 	= 1 for master only
	 *	ETH_MACTSCR_TSEVNTENA 	= 1
	 *	ETH_MACTSCR_TSIPENA 	= 1
	 */

	/* disable timestamp */
	ETH->MACTSCR &= ~ETH_MACTSCR_TSENA;

	/* copy */
	u32TempReg = ETH->MACTSCR;

	/* ... no IP4/6 */
	u32TempReg &= ~(ETH_MACTSCR_TSIPV4ENA | ETH_MACTSCR_TSIPV6ENA);
	/* PTP over Ethernet Packets */
	u32TempReg |= ETH_MACTSCR_TSIPENA;

	/* PTP v2 */
	u32TempReg |= ETH_MACTSCR_TSVER2ENA;

	/* timestamp all PTP messages */
	u32TempReg &= ~ETH_MACTSCR_SNAPTYPSEL;
	/* timestamp for EVENT messages */
	u32TempReg |= ETH_MACTSCR_TSEVNTENA;
	/* NOT timestamp for ALL messages */
	u32TempReg &= ~ETH_MACTSCR_TSENALL;

	/* overwrite unread TX timestamp */
	//u32TempReg |= ETH_MACTSCR_TXTSSTSM;

	/* re-enable timestamp */
	u32TempReg |= ETH_MACTSCR_TSENA;

	/* MASTER only:
	 *	enable timestamp snapshots for master
	 */
	if( PTP_MS_MASTER == u8MstrSlv ) u32TempReg |= ETH_MACTSCR_TSMSTRENA;
	else u32TempReg &= ~ETH_MACTSCR_TSMSTRENA;

	/* write register */
	ETH->MACTSCR = u32TempReg;

/* MACSPIxR: PTP Source Port Identity Registers
 *	MAC address is used
 *		+ some extra
 */
	/* copy from MAC address registers */
	ETH->MACSPI1R = ETH->MACA0HR;
	ETH->MACSPI0R = ETH->MACA0LR;
	ETH->MACSPI2R = (uint32_t)PTP_HWOFFL_DEF_ID2 & (uint32_t)0xFFFF;

/* MACLMIR: PTP Log message interval register */
	/* auto-reset / set:
	 *	ETH_MACLMIR_LMPDRI 	= 0 	-> PEER delay stuff, unused
	 *	ETH_MACLMIR_DRSYNCR = 0 	-> 1 DELAY REQUEST per SYNC
	 *			 			= 1 	-> 1/2 DELAY REQUEST per SYNC
	 *	ETH_MACLMIR_LSI 	= x 	-> master SYNC interval
	 */
	u32TempReg = 0;
	u32TempReg |= (uint32_t)PTP_HWOFFL_DEF_DELREQ_SYNC_RATIO << ETH_MACLMIR_DRSYNCR_Pos;
	u32TempReg |= (ETH_MACLMIR_LSI_Msk & (uint32_t)((int8_t)PTP_HWOFFL_DEF_SYNC_INTERVAL));
	ETH->MACLMIR = u32TempReg;

/* MACPOCR: PTP Offload control register */
	/* auto-reset / set:
	 *	ETH_MACPOCR_DRRDIS 		= 0 	-> ON: auto-generation of Delay Request / Response
	 *	ETH_MACPOCR_APDREQTRIG 	= 0 	-> OFF: Automatic PTP Pdelay_Req message Trigger
	 *	ETH_MACPOCR_ASYNCTRIG 	= 0 	-> OFF: Automatic PTP SYNC message Trigger
	 *	ETH_MACPOCR_APDREQEN 	= 0 	-> OFF: Automatic PTP Pdelay_Req message Enable
	 *	ETH_MACPOCR_ASYNCEN 	= 0 	-> OFF: Automatic PTP SYNC message Enable
	 *	ETH_MACPOCR_PTOEN 		= 0 	-> OFF: PTP Offload Enable
	 */
	u32TempReg = 0;
	/* set domain number - must be same for all devices */
	u32TempReg |= ((uint32_t)PTP_HWOFFL_DEF_DOMAIN_NR_DISCOM << ETH_MACPOCR_DN_Pos);

	/* MASTER only:
	 *	set auto SYNC
	 */
	if( PTP_MS_MASTER == u8MstrSlv ) u32TempReg |= ETH_MACPOCR_ASYNCEN;

	/* enable PTP offload */
	u32TempReg |= ETH_MACPOCR_PTOEN;

	/* write register */
	ETH->MACPOCR = u32TempReg;

	/* SLAVE only:
	 *	enable interrupt for TX timestamp
	 *	for slave's DELAY REQUEST
	 */
	if( PTP_MS_MASTER != u8MstrSlv ) ETH->MACIER |= ETH_MACIER_TSIE;
	else ETH->MACIER &= ~ETH_MACIER_TSIE;

	/* MASTER only:
	 *	set PTP sync quality
	 */
	if( PTP_MS_MASTER == u8MstrSlv ) u8PtpSynced = PTP_SYNC_QLVL_BEST;
}

[Pavel A.]

> interestingly, path delays are about 30% smaller with offload, which should not be the case with HW timestamps

The recorded (received) timestamps are not consistent with measured delays?

 

[LCE]

@Pavel A. I'm not sure what you mean.

From the pure timestamps, the path delays are not so easy to see, I can only rely on PTPd's algorithms, which I also use for the offload version.

Mean Path Delay:

~ 21 µs with offload

~ 29 µs with PTPd over lwIP / IPv4 / UDP

 

Anyway, I found the bug and have the audio streaming running again (it was taking care of PTPd's messaging and blocked itself in offload mode).

BUT... now the audio streaming makes the PTP sync even worse with PTP offload than with PTPd over lwIP / IPv4 / UDP.

Even at about half of max audio data rate (max is ~50 Mbps) PTP offload sync is always off at ~25 Mbps, getting back in sync only when audio streaming stops. Even with lucky packet filters.

Very frustrating, all for nothing it seems right now... Let's see what I can do. 

[LCE]

> now the audio streaming makes the PTP sync even worse with PTP offload

My mistake, slave's SYNC interval was not set correctly. Now reading it from each SYNC message.

Dear ST, there are still a few things I'd like to know...

[Pavel A.]

Unmark the thread as solved if you want them to look?

[LCE]

OLS doesn't even read their own ref manuals correctly...

And no comment on getting more / any Synopsis documentation.

Maybe anybody else from ST who already helped on other PTP related threads?

@OlivierK 

@STea 

@STackPointer64 

@Christophe Guibout 

 

 

[LCE]

Status:

1) Without PTP offload -> PTP via lwIP / UDP is rock solid. Lucky packet filtering vs packet delay variation. This an absolute must when traffic goes up with even "medium" traffic.

2) With PTP offload: is one-step only, and right now I doubt that the SYNC messages really send out a hardware timestamp. With the same clock correction function as in 1), synchronization is good, but only until traffic goes up, then it 's getting horribly bad.
I already wasted too much time with the PTP offload, no time to verify my assumptions.

We need more documentation & clarification!

So, please, dear...

@OlivierK 

@STea 

@STackPointer64 

@Christophe Guibout