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

[AvaTar]

Posted on May 30, 2018 at 12:36

Some while ago worked on the implementation of time correction based on PTP, but on a x86 device under VxWorks.

If I remember correctly, you need a working IP stack. And in my experience, you are already running into trouble here.

A Cortex M4 (ST as well as others) is definitely not capable of following a busy 100MB/s ethernet traffic, let alone 1GB/s. You can expect the network code to eat up most of available performance, and still having missed packets.

Look closely at Fig.17 of said AN3411 document. There are only PTPv2 messages visible in the Wireshark log, with no visible filter activated. This is not quite a real-world scenario for networks.

But to be fair, I didn't try the last few month ...

[Tesla DeLorean]

Posted on May 30, 2018 at 14:28

I think that's why some of the support is in hardware, to achieve some level of time-transfer.

Now whether that's applicable to real world applications, I don't know, got to be better than NTP, and someone surely must have done some basic validation to put the claim in the data sheet.

https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_mac10_100_universal

 

My problem isn't that it might not work in a totally desirable fashion, but the amount of work needed to even evaluate it, ST really should have examples supporting items they keep calling out on slide decks and sell sheets. These should be the dev teams priority drivers.

[AvaTar]

Posted on May 30, 2018 at 14:49

I think that's why some of the support is in hardware, to achieve some level of time-transfer.

For instance with using an ethernet phy that can store several 'Jumbo frames', before bothering the main processor.

Now whether that's applicable to real world applications, I don't know, got to be better than NTP, and someone surely must have done some basic validation to put the claim in the data sheet.

As other network applications, I have no doubt it runs nicely in a controlled environment, meaning a very limited number of network nodes and frames/protocols. And I'm sure ST application engineers (like those of competitors) noticed the fragility of network applications. But the whole IoT thing is such a great marketing opportunity - accross-the-board of MCU manufacturers...

[Imen.D]

Posted on May 30, 2018 at 13:29

Hello

_ZDEM_R.Emre

,

The application note

AN3411it is not available on ST web site, it is obsolete.

Currently, ST doesn't provide the PTP feature.I will raise your request to our development team to implement this feature. But, unfortunately is not at the short term planning.

With Regards,

Imen.

[Tesla DeLorean]

Posted on May 30, 2018 at 14:20

>>Currently, ST doesn't provide the PTP feature.

Support for IEEE 1588 is still listed on the part's sell sheet and data sheet... Perhaps someone at ST can dig up some basic validation work that supports the specs.

Not sure if the Ethernet uses this

https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_mac10_100_universal

 

http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f4-series/stm32f427-437/stm32f427ai.html

 

[cwparker]

​ST really needs step up on this. The IEEE 1588 hardware support in the STM32Fxxx is really good, but lack of good documentation and sample code is preventing or at least making it hard for people to use it. AN3411 (which is no longer available on the ST website) is very helpful in understanding how to configure the PTP registers, but having current demonstration software would make it a lot easier for developers to understand how to program them. The hardware even provides sniffing for the IEEE 1588 packets, but thee is absolutely NO documentation on how this work.

Come on ST, you put a lot of time into adding this hardware to the STMFxxx, how about documenting it so people can easily use it?

Clint

[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.

[anotherandrew]

Check out the repo at https://github.com/mpthompson/stm32_f4_ptpd -- it looks like it is the rescued AN3411 PTP implementation ported to the STM32F4-Discovery boards. Porting it to your specific hardware looks to be straightforward. Time stamping is not supported in the STM32 HAL (not even through an extension API) but the code in that repo shows how it was done for the other devices. It looks like your specific device is already supported by that repo.

[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...

[Cedric Boudinet]

Hello

This topic is quite old, but is there any new information about ptp integration into HAL?

Bests

[emre ozdemir]

Hi Cedric,

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

Regards.

[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.

[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...