lwip_FreeRTOS_s32k396' example project and failure

[zhangzhixing]

I'm currently using the S32K396 MCU with a raw TCP client implementation, which works fine. However, my module supplier requires me to switch to lwIP with FreeRTOS.

After importing the 'lwip_FreeRTOS_s32k396' example project and flashing it to my K396 board, the program enters the vPortEnterCritical() function when executing prvPortStartFirstTask(). How can I resolve this issues

S32DS versioln  3.5

RTD version 4.0

lwip version 1.0.4

freeRTOS version 4.0 

[PavelL]

Hello @zhangzhixing ,

I apologize for delayed response caused my workload.

The board was successfully brought up without any issues. However, a few minor adjustments to the project are necessary:

Peripherals > Pins: The TX_CLK signal did not have a specified direction — it has been set to Input. I also selected Fastest settings as the initial option.

Peripherals > Managed SDK Components: The Pins driver component was missing and has been added.

Clock settings: Configuration is correct — the FXOS 40 MHz clock matches the crystal used on the board.
PHY initialization: The call to Eth_T_InitPhys(); in device.c was commented out, as it is not required. The TJA1103 PHY relies solely on pin strapping for basic configuration.

I use TJA1103-SDBR board - TJA1103 needs to be in rev-RMII mode to generate clock on TXC -> added jumper 2-3 to CONFIG4

Update:

To improve behavior after power up, comment all rows with PIT in device.c (PIT is not used in this example):

// IntCtrl_Ip_InstallHandler(PIT0_IRQn, PIT_0_ISR, NULL_PTR);
// IntCtrl_Ip_SetPriority(PIT0_IRQn, 4);
// IntCtrl_Ip_EnableIrq(PIT0_IRQn)

// Pit_Ip_Init(PIT_INST, &PIT_0_InitConfig_PB_VS_0);
// Pit_Ip_InitChannel(PIT_INST, PIT_0_CH_0);
// Pit_Ip_EnableChannelInterrupt(PIT_INST, CH_0);

// PitPeriod = Clock_Ip_GetClockFrequency(PIT0_CLK) / 1000;
// Pit_Ip_StartChannel(PIT_INST, CH_0, PitPeriod);

Best regards,

Pavel

[zhangzhixing · Accepted solution]

I didn't add any code, but this issue occurred when I just compiled, downloaded, and debugged the lwip_FreeRTOS_s32k396 project.

there is another question：

why setting uxCriticalNesting to 0 ，

[PavelL]

Hello @zhangzhixing ,

Initialize the variable uxCriticalNesting to 0 serves to several important purposes:

1. System starts outside of any critical section
   At system startup, no critical sections have been entered yet. Initializing uxCriticalNesting to 0 reflects this clean state and ensures that interrupts are enabled by default.

2. Per-task context tracking
   Each task in FreeRTOS maintains its own uxCriticalNesting value as part of its Task Control Block (TCB). This value is saved and restored during context switches to preserve the correct interrupt state per task.

3. Ensures system stability
   Setting a non-zero value at initialization could result in interrupts being unintentionally disabled, leading to unexpected behavior or system hangs. A zero value guarantees that the scheduler and interrupt handling start in a consistent and safe state.

In lwIP examples (especially when using the threaded API or raw API), proper interrupt and critical section management is essential. Starting with uxCriticalNesting = 0 ensures that the network stack and scheduler operate reliably from the beginning

Best regards,

Pavel