Skip to main content
XKwau.1
Associate
December 13, 2019
Question

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

  • December 13, 2019
  • 7 replies
  • 2197 views

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.

This topic has been closed for replies.

7 replies

XKwau.1
XKwau.1Author
Associate
December 13, 2019

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

Last run died in about 2 hours.

Piranha
Principal III
December 13, 2019
XKwau.1
XKwau.1Author
Associate
December 13, 2019

Thanks. I will take a look.

XKwau.1
XKwau.1Author
Associate
December 14, 2019

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

0690X00000BucDiQAJ.png

XKwau.1
XKwau.1Author
Associate
December 14, 2019

0690X00000BucDnQAJ.png

XKwau.1
XKwau.1Author
Associate
December 14, 2019

0690X00000BucDsQAJ.png

Piranha
Principal III
December 14, 2019

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.