lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit

[Anna_Anna]

Hello! I am working with the 3-Phase Permanent Magnet Synchronous Motor Control Development Kit with S32K396 MCSPTR2AK396. To test the base firmware, I installed the following stack:
S32DS_3.6.5_RFP_win32
S32K3_ETPU_SW_4.9_2.0.1_D2512
SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512
SW32K3_FreeMASTER_Driver_1.5.0_D2512
S32K3xx_AMMCLIB_RTM_1_1_45_BIN
MCSPTR2AK396_SW
GCC version 10.2

After several unsuccessful attempts to synchronize all software versions, it finally worked, and the base firmware started functioning. However, I wanted to test the Ethernet communication functionality next, and that’s where I encountered unresolved issues at the moment.

I additionally installed:
SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603
SW32K3_TCPIP_STACK_4.0.0_D2512
And I took the test project lwip_FreeRTOS_s32k396, but it never compiled without errors; there were always conflicts in descriptions and other issues. I tried using the latest version of SW32K3_TCPIP_STACK_5.0.0_CD01_D2605, and I had to apply a file replacement during the update code process. In the end, the firmware compiled with warnings but no errors.

After that, I moved on to testing. I set up the system as follows: personal computer -> GeekStore 100BT1-PRO2 Automotive Converter (http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/) -> MCSPTR2AK396. I aligned the IP addresses of the Ethernet connection on the computer and the one specified in the firmware so they would be in the same subnet. However, attempting to ping the motor's assigned IP from the computer was unsuccessful, although it seems the network polling is ongoing, as indicated by the converter.

What could be the issue? Could it be that I shouldn’t have used the latest version of TCPIP_STACK? Are there possible issues with the board itself? On the controller board stickers, revisions B1 and B are indicated. Is it possible to obtain additional documentation specifically for these revisions (on the website, I only saw documentation for revision A)? I would appreciate any advice or clarifying questions.

[Julián_AragónM]

Hello @Anna_Anna,

Firstly, I am not sure what errors were present with TCPIP v4.0.0, since it is also compatible with RTD 7.0.0 & FreeRTOS 7.0.0 CD01 packages, however, latest TCPIP stack (v5.0.0) is OK. Can you share what was the file modification?

I was able to import, generate and compile the project without problem. My environment: S32DS v3.6.0, RTD v7.0.1, FreeRTOS v7.0.0 CD 01 and TCPIP Stack version 5.0.0 CD 01.

It seems that MCSPTR2AK396 has a design oversight. EMAC_MII_RMII_RX_DV (PTD14) is not connected to RX_CTL - CONFIG6: MCSPTR2AK396 EVB ethernet connectivity, CRS_DV signal clarification.

That said, is the task and OS is running? 

• xTickCount — this should be incrementing continuously if the RTOS tick interrupt is active.
• xSchedulerRunning — this should be set to 1 if the scheduler is running.

Best regards,
Julián 

[Anna_Anna]

Hello @Julián_AragónM!

The issue with building the test project using TCPIP v4.0.0 was resolved by excluding two files, fsdata.c and EthIf.c, from the build. This conflict seems to have been automatically resolved in version 5.0.0.

I also checked the values of the variables xSchedulerRunning and xTickCount through the Expressions window in the S32DS debugger. xSchedulerRunning indeed takes the value 1, and the second one increases sequentially (1, 5001, 10001...), leading me to conclude that FreeRTOS is functioning correctly on the board, and the problem is not in the software. If I understand correctly, the only remaining cause is a hardware issue—the absence of a connection between CRS_DV (CONFIG6) on the TJA1103A and pin PTD14? To resolve this, do I need to solder these two contacts together? Please confirm.

Best regards,
Anna 

[Julián_AragónM]

Hello @Anna_Anna,

Yes, the fsdata.c and EthIf.c in previous release was reported and fixed; EthIf.c file from RTD is just a stub. We provide our own minimal implementation for EthIf, so the file from RTD can be safely excluded from the project.

Secondly, yes, from your description, it seems that the example works properly. The connection is needed and should be done as mentioned (routing/soldering CRS_DV to PTD14). 

Best regards,
Julián

[Julián_AragónM]

Hello 

Regarding the design files, I can see that the HW Design Package for MCSPTR2AK396 includes revision B2:

Best regards,
Julián

[Anna_Anna]

Thanks, I'll try this approach a little later and report back on the results.