Solving real-world RTOS problems; a case of priority inversion

May 12, 2015 // By Graham Prophet
Debug visualisation specialist Percepio has collected a series of case studies of how its Tracealyzer product has resolved specific issues for its customers and has recreated similar issues to illustrate the benefits of the tools for embedded software developers. This is the latest in the series.

In this case, a design team had an issue with a randomly occurring reset. By placing a breakpoint in the reset exception handler, they figured out that it was the watchdog timer that had expired. The watchdog timer was supposed to be reset in a high priority task that executed periodically.

The ability to insert custom User Events comes in handy in this case. They are similar to a classic “printf()” call and events have here been added when the watchdog timer was reset and when it expired. User events also support data arguments, and this has been used to log the timer value (just before resetting it) to see the watchdog “margin”, i.e., remaining time. The result can be seen in Figure 1, in the yellow text labels.

We can see that the SamplerTask is running, but it does not clear the watchdog timer in the last execution of the task, which resets the system after a while (“Watchdog reset!”). So why didn’t SamplerTask reset the watchdog timer? Let’s enable Kernel Service calls to see what the task was doing. (Figure 2, next page).