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]

The more I look at it, the more I feel that this was only "half-cooked"...

Especially creating Announce messages for PTP-over-Ethernet - why have these not been included?
The user either has to build their own ethernet TX message, or get back to LWIP.

[LCE]

Some further clarifications needed on:

80-bit Source Port Identity

From the programming guidelines it's not clear to me if the master or slave ever needs to change the MACSPIxR contents.

Is source port ID constant for one device, no matter if slave or master?
Or does it need to change, depending on what is sent or received, from source to receiver address? 

[Pavel A.]

Me: Dear AI, in Precise Time Protocol (PTP) over ethernet, what is the Source port identity?

AI: <quote>

In Precise Time Protocol (PTP) over Ethernet, the Source Port Identity is a unique identifier assigned to each PTP port participating in the network. It consists of:
1. Clock Identity – A globally unique identifier for the device.
2. Port Number – A numerical value distinguishing different ports on the same device.

This identity helps in synchronization by ensuring that messages exchanged between PTP nodes are correctly attributed to their respective sources. 

The Source Port Identity remains constant for a given device, regardless of whether it is acting as a master or slave. Since the Clock Identity is unique to the device, it does not change based on its role in the network. However, the Port Number may vary if the device has multiple PTP-enabled ports.

</quote>

Low level ETH tests for specific ETH features without any IP stack, even a simple packet generator & receiver,  would be very helpful - but alas.

 

 

[LCE]

Thanks Pavel & AI :D

I know that each device must have its own and constant ID, but the description in the RM is terribly worded.
To me some lines in "63.9.10 Programming guidelines for PTP offload feature" of RM0468 sound like the MACSPIxR registers might need the destination address.

Anyway, packing and unpacking the ETH-PTP packets will mostly be kinda routine work, but I wonder why they not added auto ANNOUNCE message (probably because these are not time-sensitive).

[Pavel A.]

This question should be directed to Synopsys. Maybe PTP has been improved in other incarnations of this IP (even in STM32MP1?) ... or not.

[LCE]

Well, I don't care where the info is coming from.

But I'm using a product from ST, so they should at least provide some "better" documentation - or any link to Synopsis / whatever would be okay, too.

 

[LCE]

Just checked MP1 repo:

https://github.com/STMicroelectronics/stm32mp13xx_hal_driver/blob/main/Src/stm32mp13xx_hal_eth.c

...

 -@- The PTP offload feature is not supported in this driver.

laughing with tears in my eyes...

[Pavel A.]

Have you tried Stack Overflow? Openstlinux? This or newer/bigger IP is known in linux world as "stmmac". The Linux docum lists  two ST authors who may be able to help.

 

 

[LCE]

Yes, just found it this morning - but nobody seems to use PTP offload. 

Probably because it's directly over Ethernet and not UDP, preferred by Linux ?

I'll look for the authors again...

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