IEEE1588 PTP - how to calculate ADDEND (app note unclear)

[anotherandrew]

I'm reading AN3411, and section 4.4 details how to compute the values for the time stamp unit registers.

It shows two equations under Equation 1:

tick = ((increment * 10^9) / 2^31)

and the other is corrupted (typo?): Adden(d * increment) = 2^63/SysClk

I *think* it's saying addend (increment) = 2^63 / SysClk.

It then goes on to make a statement that has no logic leading to it: "For example, if SysClk is 72MHz, we can chose tick approximately 20ns"

How can we determine what tick should be? The period for 72MHz is 13.9ns. I don't understand how the app note comes to choose the value of tick. The remaining text in this section just uses that 20ns value to calculate increment without explaining why you would choose a tick value of 20ns nor how to determine a value of tick for other SysClk frequencies.

I've ported the example code found on github to work with STM32F756, and while it appears to be working, there is a fixed offset of 500ms (yes milliseconds) from the grandmaster clock. The actual variation from the master is every very small (nanoseconds) but there is a huge 500ms offset.

I'm trying to go through the MAC setup to make sure I haven't missed something, but I cannot figure out how to calculate the correct value for addend for the 216MHz SysTick frequency that the STM32F756 is using.

How do you select an appropriate "tick" value?

[anotherandrew · Accepted solution]

Nevermind; I found an old post and better notes in the code.

"tick" is the PTP tick, and has nothing to do with the registers nor the system frequency; 20ns is pretty common for a PTP tick value, which is where this number comes from. Slower tick values may be needed for slower SysClk values (so you don't overflow the 32-bit addend register).

The typo'd formula in the app note is actually

addend * increment = 2^63 / SysClk

the "increment" variable is independent of clock frequency. It's still 43 (20ns * 2^31 / 10^9). At 216MHz, the addend value is 2^63 / 216MHz / 43 or 0x3b309d72.

With this fixed I do achieve good sync (~20us) but I appear to have a bug in the one-way delay; as soon as ptpd tries to calculate that I get a huge negative seconds offset and the system never recovers. But that's my doing, not the chip. :)