Tmr Svc appears to stop working and threads waiting for event bits become non-responsive - How should I debug this?

Kernel
1

I’m writing code for an STM32 microcontroller and I compile using GCC (STM32CubeIDE). After my project has been running for a while, it hangs and threads that are blocked waiting for event bits to be set don’t wake up when the appropriate bits are set. I can also see in the FreeRTOS Task List in STM32CubeIDE that Tmr Svc has disappeared, but uxTaskGetNumberOfTasks still reports that all expected tasks exist (I checked that in an interrupt that was triggered from a button on my development board). The stacks seem to be ok (I checked both in the FreeRTOS Task List in STM32CubeIDE and double-checked them by manual inspection of the RAM). I have the ability to follow the flow of execution (up to 512 functions) by transmitting a unique 9-bit word over a 4MBaud UART and then look at it on an oscilloscope, but I have no idea what to look out for. This is my first time using FreeRTOS so I would like to ask for some advice on how to attack this problem.

2

Hi @arnold_w, there are a few things to check.

  • What is the definition of configASSERT()?
  • What is the definition of configCHECK_FOR_STACK_OVERFLOW?
  • How does configTIMER_TASK_PRIORITY compare to the priorities of your own tasks?
  • Have you provided a malloc-failed hook?

This post has some helpful links for the above questions.

In your case I would add an auto-reload timer to determine if the Timer task is still working. (The debugger doesn’t seem to be helping you determine that.) So when your app hangs, put a breakpoint in the callback function for your auto-reload timer. If your callback executes, the timer task is still working.

3

Thank you for your input. I found the problems, I changed configTIMER_TASK_PRIORITY from 2 to ( configMAX_PRIORITIES - 1 ) and made sure no interrupts in my code have more urgent priorities than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY.

4

Glad you resolved it. Thanks for reporting back.