I made a working Stm32H723 PTP example publicly available, but I need some help with a few quirks

[chris1seto]

Hi,

I noticed there is no Stm32H7 Ethernet PTP example available anywhere. The ST support for PTP is very poor. I wanted to make an example and get it out for review to bring more visibility to the issues with PTP and see if I could solve some issues which are bugging this implementation.

Link: https://github.com/chris1seto/Stm32H723NucleoPtpExample

ST, could you please comment on the issues covered in this example? For any others, if you have solutions to any of these problems, could you fork/PR to add fixes or just post here so I can include fixes?

Issues are detailed in the readme, but I copy and pasted them below:
"

• Tail pointer issue
  • With the stock HAL code which is supposed to correctly implement Eth RX tailpointer calculation, reception doesn't work with timestamping enabled.
  • In this project's Eth hal driver, I simply write the tail pointer to 0. It's not clear how the tailpointer is supposed to work and the documentation doesn't clearly explain it.
• The Stm32CubeH7 HAL's Eth RX timestamp retrevial is broken
  • Bug filed here: STMicroelectronics/stm32h7xx_hal_driver#63
  • I patched it in the HAL eth driver in this project
  • The idea behind the patch is that if a timestamp is available for a packet, we do not return from HAL_ETH_ReadData() until we collect the timestamp
  • There is a buffer associated with the descriptor which ends up being used as context descriptor, but I don't think the descriptor needs to be rebuilt (buffer relinked) after the descriptor is used. I think the buffer is still associated with the descriptor, and of course it wasn't used for data, so I think the only thing required to do to recycle this descriptor for use again is simply returning it to DMA with the OWN bit. Is this correct?
• The clock state oscillates between PTP_UNCALIBRATED and PTP_SLAVE
  • I don't really know why yet
  • I do have a port of this project on another board where this doesn't happen. Possibly a hardware clock issue?
• Optimization: RX descriptor use could be less intensive if the Eth mac only timestamped PTP packets,
  • I have yet to figure out how to make this work.
  • Right now, all RX packets are timestamped with TSENALL set
  • It seems like with the RESET value of the MACTSCR (3094/3357 RM0468 Rev 3), the version bit is reset but mac processing of UDP IPV4 PTP messages is enabled with TSIPV4ENA being set. So this should mean that the only thing needed to do to get the MAC to automatically timestamp UDP PTP packets is to set TSVER2ENA. If you keep TSENALL reset but set TSVER2ENA, reception works until right after DHCP, and then reception is halted with HAL_ETH_GetDMAError() = 0x1100 (RPS set, FBE set, REB = 0). I have no idea why this is happening.

"

[chris1seto]

I believe I have found an issue with the tail pointer management in the HAL, which affects this project, where I set the tail pointer to zero during descriptor processing because it wasn't working with the original tail pointer management code and it wasn't clear to me what purpose the tail pointer served. Now I think I understand why the tail pointer is necessary. 

See:
https://github.com/STMicroelectronics/stm32h7xx_hal_driver/issues/65

https://github.com/STMicroelectronics/stm32h7xx_hal_driver/issues/65

ST has confirmed that the tail pointer is an *absolute address* (NOT an offset, as indicated by the ref manual): https://community.st.com/t5/stm32-mcus-products/stm32h723-ethernet-dma-tail-pointer/m-p/698263/highlight/true#M255294

[STea]

Hello @chris1seto ,

I would like to thank you for your continuous and constructive feedback.
the issues that you raised on GitHub will be treated and it seems that your description of the issue seems to be convenient for me.

just want to know now if the issue that you are raising in this thread are currently under investigation in 
Ethernet PTP timestamp retrieval is entirely wrong · Issue #63 · STMicroelectronics/stm32h7xx_hal_driver (github.com)
and

Ethernet tail pointer setup is incorrect, and tail pointer management does not work with timestamping enabled · Issue #65 · STMicroelectronics/stm32h7xx_hal_driver (github.com) 
which are related to the first two points in this thread.
regarding:

-The clock state oscillates between PTP_UNCALIBRATED and PTP_SLAVE I don't get how this is Happening, and I think it would be difficult to reproduce.
-Optimization: RX descriptor use could be less intensive if the Eth mac only timestamped PTP packets
to try and test this first of all do you confirm that the current example published on GitHub is working to try and reproduce the issue on it? and to wrap this out you need to optimize the timestamping functionality to only timestamp PTP packets.

Regards

[chris1seto]

Hi @STea , thanks for the response.

For the issue about the clock oscillating between uncalibrated and slave, don't worry about that. I'll figure that one out. My custom Stm32H723 board *isn't* doing this, so there is some setup which does work correctly. 

The other issue though, about *only* timestamping PTP packets rather than relying on TSENALL, I'd like your help with. I can't seem to get a combination of settings here which work and don't cause the FBE bit to be set. I don't even understand why there'd be a bus error occurring in the first place, since, the timestamping storing and retrieval does work with my patch. There's very little documentation which describes how this works, so I'm at somewhat of a dead end.

Could you modify the example so that rather than TSENALL, the Eth mac is configured to only timestamp PTP packets which would be relevant to a PTP slave? 

Thank you,

[chris1seto]

@STea It's been over a month, any updates? I still need help on these issues.

[STea]

Hello @chris1seto ,

Sorry for the delayed response. I confirm the behavior you are describing.

this issue is tracked internally (Ticket number 189048 for internal usage only)
I will try to update you on this issue as soon as possible.
Regards

[chris1seto]

@STea Any updates on this? This issue is actively blocking my progress on a commercial project. We're at the almost 2 month point after I wrote the example to demonstrate this issue.

[STea]

Hello @chris1seto ,

We are still actively investigating this issue internally. I'll update you as soon as possible sorry again for the delay. hope this will be answered soon.
Regards