cancel
Showing results for 
Search instead for 
Did you mean: 

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

chris1seto
Associate II

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.


"

0 REPLIES 0