cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F753 LWIP stack not initializing after reboot

JohnnyB
Associate II

We're running into what seems to be a low-level race-condition when initializing LWIP on boot. The LWIP always initializes successfully after using the STLink to flash the .elf either in debug and release modes. After flashing, I verify by sending a ping command to the Ethernet interface and get a good response with TTL. I then subsequently cycle the power and ping returns the infamous "Request timed out" message.

It's difficult to debug because the initialization issue goes away once I start a debug session. So, I'm completely in the dark on this one. Any and all help/suggestion/insight is much appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions

I solved this problem by adding a HAL_Delay() in main.c before LWIP is initialized. The reason for the delay was based on my hunch of power instability. So, the delay allowed the entire device to reach a steady-state. 

View solution in original post

6 REPLIES 6

@JohnnyB wrote:

It's difficult to debug because the initialization issue goes away once I start a debug session. So, I'm completely in the dark on this one. .


Shine light with, eg, UART output; LEDs to show progress; etc ...

Thanks. The UART works as we have serial communication with the board and we have onboard LEDs to indicate the board is in a running state. It's just the Ethernet stack is not initialized.

So sprinkle UART status output through the LwIP process - so that you can see progress when the debugger's not connected.

Compare & contrast with when it doesn't work ...

Do the LEDs indicate that the board is in a "running state" when this happens?

 

EDIT:

Not surprisingly, it seems LwIP has printf dbugging built in:

https://lwip.fandom.com/wiki/Debugging_lwIP#:~:text=lwIP%20is%20developed%20with%20some%20nice%20support%20for%20enabling%20various%20debug%20print%20options

 

See also:

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-activate-debug-messages-for-lwip/td-p/234162

 

And:

https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/Enabling-debug-output/ta-p/1128854 

I solved this problem by adding a HAL_Delay() in main.c before LWIP is initialized. The reason for the delay was based on my hunch of power instability. So, the delay allowed the entire device to reach a steady-state. 

If you're happy with that, then please mark it as the solution.

 

Andrew, just wanted to send a quick thank you for promptly chiming in to try to help. Cheers.