STM32F4, FreeRTOS, WLIP stops working after hours, no fault captured in STM32CubeIDE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 9:06 AM
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.
- Labels:
-
Ethernet
-
FreeRTOS
-
STM32CubeIDE
-
STM32F4 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 10:26 AM
I put the project here: https://github.com/xmkllc/FreeRTOS_LWIP_Auto_Reconnect
Last run died in about 2 hours.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 12:38 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 3:34 PM
Thanks. I will take a look.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 8:04 PM
After 12 hours the program eventually hung and this was captured by the debugger:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 8:35 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-13 8:46 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-12-14 3:48 AM
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.
- At least MX_LWIP_Init() and EthInitTask() are not respecting lwIP multithreading requirements.
- 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.
