S32K388 TCP/IP stack 5.0.0 not working

[James_Zhang_SE]

Hi @PavelL,

I was able to run the example TCP/IP stack example project previously with the following configuration:

• S32KDS version 3.6.5
• RTD (Real-Time Drivers) version 7.0.0
• TCP/IP Stack version 4.0.0

However, after upgrading to the following versions and did the same setup procedure, it is not working:

• S32KDS version 3.6.8
• RTD (Real-Time Drivers) version 7.0.1
• TCP/IP Stack version 5.0.0

I have attached my project. Thanks for the help again.

[PavelL]

Hello @James_Zhang_SE ,

I need time for investigation. I'll do my best to reply within this week.

Thank you for your understanding.

Best regards,

Pavel

[PavelL · Accepted solution]

Hello @James_Zhang_SE ,

I apologize for delayed response caused by my workload.

The root cause is EthIf_Cfg.c , as we've already discussed in this thread S32K388 tcpip stack 4.0.0 missing lwip folder while compiling

The example is working now on my S32K388EVB-Q289.

Anyway, I did lots of changes in your project but the most critical is the EthIf_Cfg file. All modified files can be found in the attached zip. You may check the changes by yourself.

Please notice that provided code is without any warranty.

Once you replace files by the patch, please do not forget to do Update Code.

Best regards,

Pavel

[James_Zhang_SE]

Hi Pavel,

Thank you so much for your help! After applying the same steps as before, I was able to ping and test the TCP loopback. I have a few quick questions:

1. For the Ethif Config fix and RTD workarounds, will they be added in future releases of the driver and example project?
2. Since I'm not too familiar with this stack. When something is not working, do you have a suggested systematic way to debug?

[PavelL]

Hello @James_Zhang_SE ,

Thank you for sharing your current status.

If my previous post helped to solve the issue, please mark it as a solution, as this may help other users facing a similar problem.

Regarding point 1:

I have reported the EthIf_Cfg issue to the responsible software team. The release date of the fix is not known yet. There is still an internal discussion about where the RTD workaround should be implemented, whether in the MAC driver or in the clock configuration area. For now, we need to accept the current situation and apply the workaround manually.

Regarding point 2:

My usual debug flow is to check the pin configuration, clock configuration, interrupt configuration, FIFO sizes and the required RTD workaround code. The gPTP examples are also a very good reference, because they provide functional Ethernet-related configurations that can be used for comparison.

Best regards,

Pavel