STM32F427 PTP Implementation

[emre ozdemir]

Posted on May 30, 2018 at 12:08

Hi everyone,

We are using the STM32F427.We have devices that need to work synchronously.So we decided to use PTP but we have no experience in this matter.

I have reviewed the AN3411 document to learn how to use PTP.But I do not fully understand and I can't implement it.

I could not find the project mentioned in this file.I also could not find the PTP libraries.(ptpd-1.0.0 & ptpd-2.0.0).

We are currently using our devices as a tcp server.

We don't use RTOS.

Any help would be great.

#an3411 #ieee-1588 #ptp #stm32f427

[emre ozdemir]

Hi Cedric,

I didn't check this for a while.We handled this situation with our custom algorithm.

Regards.

[Nikita91]

I don't think ST spent a lot of time integrating this IP: They took it as given by the vendor.

The proof is that they don't have the code to test it.

[SHers]

I am also looking for PTP support for an STM32F4. I've examined the Github project; unfortunately for me, it has neither copyright notices nor a license statement, so I can at most use it as a guide to develop my own independent implementation. This is needlessly tedious. ST should never have removed their application note...

[Piranha]

With the reworked ETH drivers ST have added an API for PTP, which some people wanted so much. As the PTP hardware programming is pretty simple, of course, the API basically consists of a trivial functions like in LL "drivers". Let's look at the usefulness of it.

For example, the HAL_ETH_PTP_GetTime() function. Effectively there are just two lines of code. Of course, it is much easier and efficient to just read those two registers directly in variables, which your code actually needs, not some intermediate structure. The worst part is the code doesn't even implement a consistent readout of those counters, like, for example, it's done in Zephyr or generally explained there. And for fun the PTP configuration state macros are spelled in a clear frenglish.

So... Are people happy? Do those few line functions help someone? In my opinion they are useless, exactly like LL "drivers".

[Nikita91]

It's still staggering such a gross error on the part of professional programmers of a reputable brand...

I would rather expect such a function to provide reliable read when used by non-seasoned developers.

As written this function is not only useless but toxic: it introduces a bug in the code.

[anotherandrew]

Agreed, it's frustrating to say the least.

It's been several years now (!) since we first interacted and you'd mentioned that you had a workable solution which allowed both maximum throughput by fixing the DMA issues in the demo/HAL implementation as well as a PTP solution you might be able to share with the community.

My specific project is now long over (successful, fortunately) and I'm hopeful that you are still able to share your specific implementation since you have both the expertise and the command of English that others might be able to learn from. And who knows, maybe also something ST might be able to incorporate. :)

Are you able to share your high throughput ethernet implementation with the rest of the community? I am going to contact my old client to see what I might be able to share, but I do recall that my specific implementation was not something I'm particularly proud to claim ownership of, even if the IP hurdles are successfully cleared.

[Piranha]

It gets even better! The HAL_ETH_PTP_SetTime() and HAL_ETH_PTP_AddTimeOffset() functions don't actually modify the system time. They are just writing time stamp update registers, which doesn't do anything with the actual system time. For the system time to be initialized or updated, after writing time stamp update registers the TSSTI (initialize - overwrite) or TSSTU (update - add or subtract) bit in ETH_PTPTSCR register must be set. Currently those functions effectively do nothing, which clearly shows that nobody in ST has even tried using those functions...

In addition I'm not sure about the logic they've implemented in HAL_ETH_PTP_AddTimeOffset() for negative time values - the reference manuals don't require such math.

Also the following functions have wrong Doxygen comment descriptions:

• HAL_ETH_PTP_SetTime
• HAL_ETH_PTP_GetTime
• HAL_ETH_PTP_AddTimeOffset
• HAL_ETH_PTP_InsertTxTimestamp
• HAL_ETH_PTP_GetTxTimestamp
• HAL_ETH_PTP_GetRxTimestamp
• HAL_ETH_TxPtpCallback

[Piranha]

Another bug related to the PTP implementation:

https://community.st.com/s/question/0D53W00001sKgBASA0/bug-stm32f429zi-eth-ptp-receive-timestamp

EDIT: And another:

https://community.st.com/s/question/0D53W00001t0vFBSAY/bug-stm32f429zi-eth-ptp-tim2-itr1

@KDJEM.1​ 

[KDJEM.1]

Hello @Piranha​,

Thank you for bringing these proposals and possible issues to our attention.

I reported them internally.

Internal ticket number: 137427 (This is an internal tracking number and is not accessible or usable by customers).

Kaouthar

[Piranha]

Three months after these reports ST released CubeH7 v1.11, which doesn't fix any of these PTP related issues. And, of course, it also doesn't fix any of the countless issues reported in this topic. So... just wait another year for the next release, which probably will still not fix it! And then another year. And another...