MQX RTOS Task Aware Debugging plug-in (TAD) is an optional extension to a debugger tool which enables easy debugging of multi-tasking applications. With TAD, we can inspect task contexts and kernel objects. Typical use cases include
--view task error codes
--Examine stack usage for each task
--Examine memory usage
-- Debug TCP reception problems
--Examine socket and PCB data
--Observe memory pool / message pool utilization levels
-- Observe synchronization objects
The following is a description of MQX task aware debugger and an example to debug a stack overflow. It is based on web_hvac demo in the MQX installation folder, it also applies to other applications.
The MQX pull down menu is as below picture shows.
The task summary window shows all the tasks in the system, the task name , task id , task state, priority and Task error code. The idle task is also listed since this is still treated by MQX as a task, and can be helpful to know what’s happening with it.
The stack usage window shows what percentage that allocated for a task interrupt have been used so far. This is a high watermark not the amount of the stack currently been used. If more than allocated stack is being used as some point, then you will see an over flow has been indicated at last column. Also for reference, the address for both the base for up and down are shown.
The kernel data window can be useful for confirming the environment you are running is actually what was loaded. You give them some key data such as the version of MQX running, the CPU, the PSP. The settings of the time component and a number of the compile time configuration settings to confirm if you have things like the kernel logging or stack monitor turned on.
The memory blocks window shows all of the blocks of memory that memory manager has currently reserved for kernel objects or application tasks. Listed is starting address for each block , the size of each block in hexadecimal , who is the owner of each block. Which can be either the system or specific tasks, and shows the type of block. We see different types such as the block for interrupts stack, system stack, task ready queue, block associated with interrupts. The logging feature, message pools etc. Down to the bottom, we see the stacks specific memory blocks including the task descriptor and task space. TAD knows what the task descriptor is so it gives all the information related to the task.
The next group of windows are related to various synchronizations that MQX supports. Such as semaphores and events ,mutexes. If some are greyed out and that because application doesn’t use it.
Example of Debugging with TAD
In order to gain experience using the Task Aware Debugging (TAD) feature and to learn how it can be used to debug an application, I created a stack overflow in the shell task in web_hvac demo by reducing the task stack size from 2400 to 500.
If I now run the application, we can see the application run into idle task quickly.
Opening up the stack usage window, we see that indeed an overflow was detected.
And that the stack information for the Shell task has been corrupted as a result. The task summary window also has the corrupted information for the shell task.
If you look closely, the listed tasks are short than before, and if you compare the list of tasks what you expected to be there. You noticed to shell task has completed disappear. But when we look at the console, we see that it clearly started.
So where did it go? The stack overrun is a good clue. But also recommend scanning check for errors window.
By reviewing the task summary, stack usage and errors windows, and doing a sanity check again the states values that expecting can be very helpful ,make sure all the tasks are there. Check for error codes, and look for stack issues. To debug an application, the following steps should be follow:
- Review key TAD windows:
- Task Summary Window
- Stack Usage Window
- MQX Errors Window
- Audit various system parameters:
- Which tasks are running.
- Task states
- Check for identified errors
- Look for stack overflows
