Kernel Troubleshooting#
General Considerations#
While developing your application, care must be taken to ensure that every call to a service that pends has a call that posts. Furthermore, the OSTaskSuspend() and OSTaskResume() functions and the OSSchedLock() and OSSchedUnlock() functions should be called in pairs. Indeed, the suspend and lock levels can be nested, and there should be an equal number of calls to both function pairs.
The Kernel offers multiple services that allow you to control the access to shared resources. As a general rule, if the resource can be shared by more than one task at a time, use a semaphore. However, if the resource can be used by only one task at a time, use a mutex. The mutex in the Kernel is implemented in such a way as to prevent priority inversion by using the priority ceiling protocol.
My Application Deadlocks#
Make sure that at any one point in time, at least one of the four rules in the deadlocks section of Resource Management is false.
My Application Behaves Erratically#
Sometimes, tasks can overflow their stack space if the required size for the stack was underestimated when the task was first created.
This situation can go undetected if the stack overflows into an unused region of memory. But that region can sometimes be used by other parts of the code, which can cause the application to fail. Worse, a overflowed stack can cause an application failure at a seemingly random point in time, which complicates the debugging effort. In those cases, the general behavior of your application would appear erratic.
To verify if one of your tasks is behaving badly, you can use the Redzone Stack Checker, which can be enabled in the compile-time configuration . Another option (also in the compile-time configuration ) is to enable both the Statistics task and the Stack checker, which monitor the stack usage of the tasks. When you find that a task is overflowing its stack, you should adjust the stack size so that it does not overflow. Review the stack section of the Tasks page for more information.
An Important Task in My Application Does Not Run#
If you feel that a task that should run more frequently than it is doing, verify the effective task priorities and ensure that there is not a priority inversion caused by the use of a semaphore. First, correct any priority inversion issues by using mutexes instead of semaphores. Then, verify the assigned task priorities. A good starting point in assigning task priorities can be found on the Tasks page.
My Application Is Not Responsive#
This may be a sign that your application is blocking external stimuli for an extended period of time. If your application has long critical sections, the microcontroller you are using may be executing the various ISRs with a high latency. This would in turn cause your tasks that depend on external events to be executed with an even longer latency.