Hi Nxp team,
We would like to use S32K324 to integrate "SW32K3_TCPIP_STACK_1_0_1_D2205", but many build error. Even we tried to add define S32K324 to make project no error as below picture, but it still ping fail.
We also have S32k344EVM with phy JA1101B and it can ping successfull in RTOS and Baremetal mode when we use "SW32K3_TCPIP_STACK_1_0_1_D2205". Now we have below questions, please help to answer us as soon as possible. Thanks.
1. Please let us know if S32K324 could integrate "SW32K3_TCPIP_STACK_1_0_1_D2205" or not.
If not, does NXP have other TCPIP SDK for S32K324?
If yes, could NXP provide sample project for our easy development?
2. Since we only have "SW32K3_TCPIP_STACK_1_0_1_D2205" for S32K344, could we use S32K344 code base flash on S32K324 chip? Is there any side effect?
SW32K3_TCPIP_STACK_1_0_1_D2205 should be adapt with S32K324. Unfortunately, we haven't performed validation on S32K324, or we don't provide the example for S32K324. Since the different between S32K324 and S32K344 is the cores, you can use SW32K3_TCPIP_STACK_1_0_1_D2205 for S32K324.
Actually, we already integrated S32k324 with SW32K3_TCPIP_STACK_1_0_1_D2205 as attached project, and it could ping successful base on ubuntu environment now . But we found reponse time is too long(over one sec) as below figure 1 than we use S32k344 lwip sample code as below figure 2. You can see S32k344 lwip reponse time is reasonable. Please check our project and let us know how to solve it. Thanks a lot.
By the way, we use S32k324 code base to flash on S32k344 EVM since we still wait for our board(S32K324).
Sorry for late reply. Unfortunately, although everything seems to be correct I couldn't understand why it took long time for a ping command. My test team hasn't validated the stack with S32K324, so I have no clue at the moment. My suggestion is you can re-create your project with only one core available (M7_0) and see whether it helps.
Have you flash my project on S32K324? Or you only flash my project on S32K344EVM?
Since we still only have S32K344EVM, if you can test our project on S32K324, please help us to test it and let us know if ping time is still long. Thanks!!
Sorry for late reply, but we are working on that. One of my colleague found that the linker file you have been using is inappropriate, and he has rebuilt the project. Please find attachment the project we have been working, and try out in your site. Unfortunately, we see the same behavior as your observation. We will let you know once we found the solution.
Firsr, we already tried your project, but we also see the same behavior as before. Ping tims is very long.
Second, we tried to re-create new project with only one core available (M7_0) as well, but it's no helpful.
We still would like to know which IC you flash, S32K324 or S32K344?
Thanks for your help to find the solution, please update to us if any good news form your side. Thanks you.
Sorry for late response. Here is the feedback from our team:
The current lwip stack based on RTD 2.0.0 is only tested with K344 not K324, thus, some changes must be implemented when porting the K344 lwip demo on to K324:
1. The linker files of 2 projects CM7_0 and CM7_1 should be kindly tweaked to ensure there is no overlap between two cores. In this case, you can use new empty K324 project CM7_0 linker file and startup code to replace it. Besides, you need to cut down the freeRTOS heap size / lwip stack heap size to reduce the ram cost, or increase you CM7_0 linker file memory region (and decrease CM7_1 linker file memory region), and ensure your compile result would not overlap.
2. Tweaks for compile errors after step 1. In the "OsIf_rtd_port.c", the SCB relative configurations should be changed for K324, not K344. Please note, you need to change these settings every time you re-generate code from .mex file, due to they would be refreshed correspondingly.
3. The default project setting enabled Cache, and the lwip heap memory was allocated from cacheable region. Thus there are risks about data inconsistency when CPU and EMAC uDMA access asynchronously. Two way to avoid this issue:
① Just disable the D-cache, the original Lwip_s32k344 demo use the same way. It's convenient, but lower running efficiency for other applications.
② Allocate the lwip heap from non-cacheable region. Thus the cache can keep enable, it's good. When use this way, you need to make below changes:
a) Increase the non-cacheable region (decrease shareable region) in linker file and add the lwip non-cacheable heap region for next use.
b) Add lwip memory allocation macro in .mex tcpip component "user setting" page, thus it would be generated in lwipcfg.h, and to replace the default allocation way in "arch.h" which allocate memory from shareable region.
Please find attachment for the demo. Let me know if it works.