STM32H755 with Precision Time Protocol.

[Leon_MS]

Hello all,

I am learning to implement a bare-minimal code that let PTP(OC, slave mode) works with STM32H755(Nucleo-H755ZI-Q with FreeRTOS). I have read RM0399, UM2217 as well as stm32h7xx_hal_eth.c with corresponding chapters. And here is the first draft I have done: https://codefile.io/f/vny07A1hYW. In this implementation only PTP-over-Ethernet (PTPv2) will be considered.

So basic ideas are:

+ "DataQ_PTP_Init" implements RM0399 §61.9.9 "Initializing the System time generation". This function will be called with ETH_Init(). As well as when network cable status is changed(connected).
+ "DataQ_PTP_DeInit" will be called when e.g. network cable is disconnected.
+ "DataQ_PTP_SysTime_Fine_Correction" implements RM0399 Page 3037 "System time correction" algorithm, with Fine-Correction only.
+ "DataQ_PTP_TSI_ISR" will verify Addend Register, has been updated correctly. By referencing RM0399 Page 3037 "System time correction" algorithm step 3-8. (When TSI interrupt is triggered.)
+ "DataQ_PTP_Rx_ISR" will update Master_Sync_Time and Slave_Clock_Time, used by Fine-Correction algorithm. (When Rx interrupt is triggered.)

My questions:
+ Could experts here help to identify logical / implementation errors?
+ From RM0399 Page 3037 "System time correction" Step 6. Should be "bit 3/TSUPDT" instead of "bit 4" shown on the document?
+ Why "System time correction" algorithm, step 8, says "reprogram ETH_MACTSAR with old value"? Should be the value updated from the next round of algorithm?
+ How "t3" and "t4" being used in this algorithm, with illustrated in Figure 831 from RM0399?
+ Does "Fine-correction" could be suitable used for initialization e.g. huge time differences between Slave and Master? I am thinking it will take long time elapsed till clock converged.
+ Seems the variable "Master_To_Slave_Delay" never got updated based on "System time correction" algorithm.
+ How to determine the value written to "MACPPSTTSR" and "MACPPSTTNR", from step 4 of "System time correction".

Sorry to say but this is the first time I touched PTP. So for sure there might be some misunderstanding or "guess-work"....

Big Thanks for your kindly help!

Best regards,

[Leon_MS]

Just trying to translate the "programming guide" from reference manual to code. Does anyone able to help? Many thanks in advance!

[Leon_MS]

Would be really appreciate if someone could help! Actually the reason why I am implementing this code, is because I would believe the "programming guide" contains all details that makes PTP application works and, porting ptpd might unnecessary in this case.(I mean with an existing programming guide already exists.)

[FBL]

Hello @Leon_MS 

The typo is reported. Internal ticket number: 168837 (This is an internal tracking number and is not accessible or usable by customers)", 

According to the questions, I am still waiting for a response from experts.

Thank you for your feedback

[Pavel A.]

As always, help is waiting for you here and here. You can request not only writing the code or ("translate the "programming guide" from reference manual to code") but do the needed research too.

[Leon_MS]

Thanks a lot @FBL! And sorry for my late reply.

For those days I have tried different kind of code to test how PTP feature works with STM32H755 Ethernet MAC. I have used a Ubuntu PC with ptp4l (command shown below), generating IEEE 1588 Ethernet frames:

sudo ptp4l -2 -S -m -i en1

Interesting thing is: It seems so that after the first "Announce"-"SYNC"-"Follow_Up" packets group being received successfully by STM32H755(LwIP is used also.). It's not possible for MAC for receiving any incoming Layer-2 frames after that.

(Without knowing how this MAC has been implemented by ST/Synopsys). Should I highly suspect that there is a internal state-machine (located somewhere in Ethernet MAC) which is used for tracking how those PTP packets are generated / received? So in my situation, the only thing I could/should do after receiving the "Follow_UP" message, was generating a "Delay_Req" to bring the MAC back to functionality again?

And... I am now researching how PTP offloading feature should work. I would like the MAC generating Delay_Req automatically after SYNC was received.

Thanks!

[Leon_MS]

Maybe some other findings I would like to share as well @FBL :

I have tried 2 different scenarios under PTP packet receiving. The first one is just running ptp4l and the second one is running "ping" command, while at the same time ptp4l is running.

On the first scenario. I can only receive 1-set of PTP messages (Announce-SYNC-Follow_UP) but, on the second scenario, I can receive 2-sets. But Ethernet MAC under all scenarios refused to receive any packet then.

Another interesting finding is, even though from DMA descriptor the "TSA" bit has been set for the first received "SYNC" packet. Timestamp fields are all zeros from context DMA Rx descriptor RDES0 and RDES1.

But under scenario 2, the second SYNC packet contains correct timestamp from RDES0 and RDES1.

I haven't changed any "Clock" configurations so seems, this MAC was running under 64MHz from "AHB1, 2 and Peripheral Clocks". While from RM0399 all examples are given by 50MHz clock, could be 64MHz too fast for this MAC?

Thanks!

[FBL]

Hello @Leon_MS 

Still waiting for suggestions from experts, I guess the reworked Ethernet HAL driver brings support to PTP starting from V1.11.0.

Regarding your specific issue with the ETH MAC not receiving any incoming Layer-2 frames after the first 'Announce'-'SYNC'-'Follow_Up' packets group, it's difficult to pinpoint the exact cause without more information. It could be related to the internal state-machine of the Ethernet MAC, or it could be a timing issue.

Have you tried different source clock instead of HCLK?

[Leon_MS]

Hello @FBL ! I am now using STM32CubeH7 v1.11.1 so, I guess it should include that rework.

I have done some testing from my side, and based on the observations:

+ Changing CPU / AHB1 frequencies are not helpful. I am now using CM7 @ 400MHz, CM4 @ 200 MHz. Slow interfaces e.g. APBx is running @ 100MHz.

+ Increasing number of pbufs and RX DMA descriptors have very limited help.

BUT....

I accidentally disabled TSIPENA bit from MACTSCR. And then I could freely received any amount of PTP packet but without timestamping feature.

The same phenomena could be seen from UDPv4 as well.(If TSIPV4ENA is set then MAC will stuck after few rounds of PTP packets are received. But when TSIPV4ENA is cleared MAC will always work but without timestamp feature.)

[Leon_MS]

I have also observed the RX timestamping, from RX DMA context descriptor actually contains the timestamp from the 2nd last packet received. Not from the one just received....