Request to Update AN12149 for Modern SDKs and Middleware

[mastupristi]

Hi everyone,

I’ve been working with the application note AN12149 ("Implementing an IEEE 1588 V2 on i.MX RT Using PTPd, FreeRTOS, and lwIP TCP/IP stack") published by NXP in 2018. While it’s a great starting point, it’s severely outdated:

• It relies on SDK 2.4.x (current version is 2.16.100, which is vastly different).
• It uses FreeRTOS 10.0.1 (current version is 11.1.0).
• It uses a patched version of lwIP 2.0.3 (current version is 2.2.0).
• The PTPd version is 2.2.2, heavily patched to run on a microcontroller. This project, originally POSIX-based and designed for Linux, isn’t well-suited for microcontroller environments. It requires significant memory (both code and data) and isn’t particularly optimized or efficient.

The example is also limited to the RT1020, RT1050, and RT1060. We managed (with considerable effort) to port it to the RT1170, but we’re still struggling to get 100M Ethernet working reliably.

Given these challenges, I’d like to request that NXP updates AN12149 to:

1. Use the latest SDK, FreeRTOS, and lwIP versions.
2. Replace PTPd with a more microcontroller-friendly solution.

For reference, Zephyr now includes support for PTPv2, which we may consider in the future. However, for now, we’re bound to lwIP and FreeRTOS.

I believe an updated application note would greatly benefit the community. Is this something NXP could consider?

Thanks for your support!

[diego_charles]

Hi @mastupristi 

I am glad that you asked about this. With your report we already know what you need and we will try to deliver this.

Regarding your issue, please help us to create another thread. 

Diego

[mastupristi]

Hi @diego_charles 

Thank you for your response and for considering the update to AN12149, this is very encouraging!

Regarding your request to create another thread, I’d like to clarify the situation. The Ethernet functionality on the RT1170 generally works, as I managed to port the 2018 sources to the latest SDK and lwIP. However, we use Ethernet for audio transport over IP (AES67), which requires precise synchronization with a master clock. It’s in this context that we experience occasional issues.

Unfortunately, I’m not authorized to share our sources, which limits how much detail I can provide about the current implementation. That’s why I’m anxiously awaiting a new version of AN12149 and the associated software, it would allow us to base our work on a more reliable and modern software platform.

Could you clarify what you expect me to include in the new thread? I’m happy to provide more details about the issues we’re encountering if it would be helpful.

Looking forward to your guidance!

Best regards,

Max

[diego_charles]

Hi @mastupristi 

Thank you again for your interest and for the additional context!

I forwarded your comments internally, and I am aligning internally to see what can be planned to do. I understand that since you made your own port it is difficult to share SW.  Does having our updated SW removes the involve of troubleshooting your current issues?

Thank you,

Diego

[mastupristi]

Hi @diego_charles 

Thank you for forwarding my comments and for aligning internally, much appreciated!

I firmly believe that having an updated version of your software will address the issues I’m currently facing. A modernized implementation, based on the latest SDK and middleware, would provide a much more reliable foundation for our work and likely resolve the problems we’re encountering.

Thanks again for your support, and I’m looking forward to any updates you can share!

best regards

Max

[diego_charles]

Hi @mastupristi 

Thank you for your reply, we are glad to help!

I am checking this internally, we have some updated code already, but license scan must be done. I will maintain you updated.

Diego

[mastupristi]

Hi @diego_charles ,

Thank you for your support and for keeping me updated! I truly appreciate your efforts and will eagerly wait for your updates, hoping for positive news.

Thanks again for your help!

Best regards,

Max

[diego_charles]

Hi @mastupristi 

It is a pleasure to help! We really thank you for your interest!

Let me be transparent on this,  At this moment I can not push further to release the code, as the colleague who is creating it is currently busy with more  tasks, so I can not compromise us with a deadline or with a close  date to have this. As much I would like to give to you what we already have, I can't,  it needs to have license scan to met our legal criteria, and I don't have this ability and tools. 

My message is that update is coming and it will be released as soon it is possible for us. I do not want to keep you with uncertainty, Are you okay if you come back to the thread for follow up, on the middle of next month? If I get any news before I will let you know too. 

Diego

[mastupristi]

hi @diego_charles 

Sorry for the delay in replying, I was in the holiday season and got back to work today.

Are you okay if you come back to the thread for follow up, on the middle of next month?

Of course, that means middle of January, right?

best regards

Max

[diego_charles]

Hi @mastupristi 

I hope you had some good rest, I  was on holiday season too, no worries. 

Yes, I  meant at the middle of  January, anyway I already asked internally. 

Diego

[mastupristi]

Hi @diego_charles 

do you have any news?

Can update you on a problem that we are definitely experiencing. In some scenarios we detect packet leaks. We are pretty sure that it is the SW that is “losing” these packets. I say this because we are talking about RTP packets containing audio samples, so we can hear by ear the lost packets, plus the packets are tagged with progressive numbers, so it is easy to realize lost packets (never arrived, even out of order).
In addition, there are other devices in the same network that receive the same audio stream and have no problem. So we know that on the network the packets are all there.
Finally by querying the ENET devices and the PHY no reception problems are found. So the packets should all be received, and therefore it must be the SW that loses them.

I would remind you that the current driver code is the result of a porting that itself was already a porting. So if I had to bet on where the problem might be, I would bet on the component highlighted in green:

We have been trying to get to the bottom of this problem for a few weeks now, without any kind of success, and I make no secret of the fact that the updated code of AN12149 would be like a ray of light.

regards

Max

[diego_charles]

Hi @mastupristi 

Thank you for the reply and more detailed explanation of your issue. I am very sorry to tell you that I still do not have good news. I am sending  a reminder internally about your request.

Diego

[diego_charles]

Hi @mastupristi 

Thank you for your patience! 

I have more news. Our colleagues plan to start working on  the release of the FW this week. but we may require more time after that. 

We also noticed that gen AVB stack could also help you. We have an open source genAVB/TSN stack which may meet your requirements, but to  access the demo code you need to have an  NDA. If this works for you, please let me know and I will create another separate and internal ticket for you!

Diego

[mastupristi]

Hi @diego_charles 

Ah, wonderful! After months of waiting and specifically requesting that AN12149 be updated to include support for the RT11xx series, NXP surprises us with a new version that… completely ignores the RT11xx. Despite our detailed discussions and explicit requests in this thread, it seems the RT11xx was just forgotten.

Perhaps this is an invitation to go back to using outdated technologies or—better yet—to reinvent the wheel ourselves from scratch.

I wonder, should we now expect a brand new application note dedicated solely to the RT11xx? Or is that too much to ask from a document that’s supposed to address developers’ actual needs?

regards
Max

[Leonardo_Fibucchi]

Hi @diego_charles,

I am interested as well on this SW. Are there any current news on release date?

Thank you

[Littell]

I'm curious about the Ethernet problems you're having with the RT1170 and if you're attempting to get some help in a different thread?  In any case, good luck with all that!

[mastupristi]

Hi @Littell 

Unfortunately, I have no certainty about that.

As I have already written, we developed our entire SW stack on an RT1051, “roughly” bringing in patches from AN12149's SW.

We “reinterpreted” the patches and had to slightly patch the ENET driver as well.

Things seemed to work well, though. Our products are amplifiers that play audio from an RTP packet stream (in AES67 standard). And on these we haven't had any major problems so far.

Then we approached the RT1170s. The ENET device IPs (I'm talking about the 10/100) is the same as the RT1051. And in fact the driver on SDK is the same.

Then we approached the RT1170s. The ENET device IPs (I'm talking about the 10/100) is the same as the RT1051. And in fact the driver on SDK is the same.
We had to reinterpret the patches further, though.
What we observe is that in the RTP stream (one packet every millisecond) we occasionally lose some packets, up to a few dozen per second with non-constant rate.

Of course we do the tests side by side with devices with RT1051, which have no problems.
Right now the main suspect is the patches we made (to be precise, it's the interpretation of said patches that is under investigation).
The first patches though were made by NXP in AN12149, and this prompted me to ask for an AN update to support newer microcontrollers and perhaps find (or write from scratch) an alternative to PTPd, which is an extremely inefficient piece of SW, both in terms of machine cycles and memory footprint.

regards

Max

[mastupristi]

Hi @Littell 

Thanks for your reply and your curiosity about the Ethernet issues with the RT1170. Let me explain briefly the challenges I’m facing:

I'm curious about the Ethernet problems you're having with the RT1170

To make PTP work on the RT1170, I first need to figure out which patches were applied in the 2018 example. This is already a daunting task because:

• It’s unclear which files from the 2018 example were modified.
• There’s no precise information about the exact SDK version NXP used. I’ve found SDK 2.4.0, 2.4.1, and three different releases of 2.4.2, but I don’t know which one served as the base.

Even if I manage to understand the required patches, applying them to the newer SDK is a completely different challenge. The file structure has changed significantly. For instance, the file enet_ethernetif_kinetis.c, which is critical for Ethernet management today, didn’t exist in the older SDK. And it is not the only example.This means I can’t simply patch the code; I have to manually adapt it, which increases the likelihood of errors.

And that is only considering the SDK, then there would be to consider all the middleware (lwip, freertos, etc.) and not least PTPd

you're attempting to get some help in a different thread?

no, I haven’t created a separate thread for this.

Thanks again for your interest!

Regards

Max