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...