cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4, FreeRTOS, WLIP stops working after hours, no fault captured in STM32CubeIDE.

XKwau.1
Associate II

I created a simple program for STM32f407 discovery that has FreeRTOS (10.0.1) and LWIP (2.0.3) in STM32CubeIDE 1.1.0. It uses a task to start LWIP and dhcp and kills the task. It has a software timer that blinks an LED and printf a counter. I implemented _write to redirect to TIM. That's it. In debug I have SWV. data trace timeline and fault analyzer. I kept the host PC run all the time without going to sleep. The board worked for hours (>6) and the LED doesn't blink any more. Pinging from host PC has no response. No fault was captured.

When I tried to restart debugging, hit the run nothing happened. I had to cycle the board power.

Before this I tried many times using FreeRTOS with LWIP, the board always dies in a couple of hours.

Any thoughts on the combination of FreeRTOS and LWIP and how to improve debugging?

Thanks.

7 REPLIES 7
XKwau.1
Associate II

I put the project here: https://github.com/xmkllc/FreeRTOS_LWIP_Auto_Reconnect

Last run died in about 2 hours.

XKwau.1
Associate II

Thanks. I will take a look.

XKwau.1
Associate II

After 12 hours the program eventually hung and this was captured by the debugger:

0690X00000BucDiQAJ.png

XKwau.1
Associate II

0690X00000BucDnQAJ.png

XKwau.1
Associate II

0690X00000BucDsQAJ.png

Piranha
Chief II

Those images doesn't help much... Call stack could provide something useful, but there is no sense in spending time on such debugging until the fundamental bugs are fixed.

  1. At least MX_LWIP_Init() and EthInitTask() are not respecting lwIP multithreading requirements.
  2. Link status processing code misuses NETIF_FLAG_UP instead of NETIF_FLAG_LINK_UP and the respective wrong API.

All of this and more is described in my topic... Additionally your code uses CMSIS-RTOS mixed with FreeRTOS native API, which can easily break things.