STM32F753 LWIP stack not initializing after reboot

JohnnyB · ‎2024-05-20

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.

JohnnyB · ‎2024-05-20

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

Andrew Neil · ‎2024-05-20

@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 ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

JohnnyB · ‎2024-05-20

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.

Andrew Neil · ‎2024-05-20

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

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

JohnnyB · ‎2024-05-20

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.

Andrew Neil · ‎2024-05-21

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

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

JohnnyB · ‎2024-05-21

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