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]

@STea @Peter BENSCH 

Please, give some advice, or find someone at ST who knows about the PTP offload.

I finally found the time for some programming.

I followed the programming guidelines (RM0468, 63.9.10) - but no SYNC messages are sent.

These are the register settings, read via UART: (all %08lX hex values)

PTP hardware offload
MACPOCR 00000043
         0 domain number
         DelReq/Resp auto gen OFF
         PEER DelReq trigger OFF
         SYNC trigger OFF
         PEER DelReq auto gen OFF
         SYNC auto gen ON
         PTP offload enable ON
MACLMIR 000001FD
         1 DelReq-Sync ratio
         -3 SYNC interval
MACSPI0R 0190D15C
MACSPI1R 00006C02
MACSPI2R 0000CAFE
MACTSCR  0000CC03 control register
         TSMSTRENA
         TSEVNTENA
         TSIPENA
         v2 EN
         TSCFUPDT update: fine
         TSENA
MACIER   00001000

PS: ethernet is working with own driver, with LWIP, http server, TCP data streaming, SNTP, PTPd via UDP - but I could really use the PTP offload.

[LCE]

bump...

[Pavel A.]

It looks like STM32 community folks are unable to help. Send OLS request to access the documentation on the Synopsys ETH IP?

[LCE]

Yes, probably the only way to get some info from ST.

But it's a little frustrating that the ST employees "jump" on to some threads, but others are completely ignored.

At least some statement like "we have no idea" would help, then I would start going further.

[LCE]

One part of the solution found:

I changed the router between the H7 board and my laptop to a cheap one, and surprise:

I saw SYNC packets in Wireshark!

The "smarter" router didn't let these packets pass, because I had not set the MAC address in hardware, only for the LWIP "net interface". So source address was FFF... 

So I set the HW MAC in the MACA0HR / L registers, and then the smarter router let's the SYNC packets pass.

Oh my...

Still no TX timestamps from interrupt!

[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?