Debugging any RTOS application is a tricky task. Most of the times the tasks are communicating via message queues or blocked by semaphores and interrupts are setting semaphores or sending messages to mailboxes.
It is hard to keep track of which tasks are there, if - and how many, messages there are in mailboxes when debugging.
To help out a bit, there is a special Eclipse plugin available that can show the status of tasks and queues. This plugin is available in the LPCXpresso tools, just go to the menu Window - Show View - Other and select the OpenRTOS viewer, there you can select what you want to see.
Task Table view
The task table view (in the bottom pane) gives an overview of tasks.
It shows the task number, the priority (also the actual priority in case of priority inversion), stack, state and in case a task is waiting (blocked) it shows the queue it is waiting on.
Queue table view
The queue table view shows all queues that you register.
For this you need to add some code to your program:
vQueueAddToRegistry( xCanRxQueue, (signed char*)"CanRxQueue" );
will show this queue in the table with per queue its size, and if there are tasks waiting to send to or receive from this queue.
A bug is found!
My program crashed after adding some debugging code (I am logging debug data to an SD card).
Have a look at the attached view and compare it to the correct view in the section above.
In the first view there is a green line, stating that this is the current running task, but in the second view this line is gone. Further investigation of both views shows that the task (SPD) is gone: it is replaced by a funny line with stange numbers at the bottom of the view.
From previous debugging sessions I remember that both the TCB (task control block) and the stack of a task are placed on the heap. The TCB is placed immediately below the stack and the stack grows down ...
Bells immediately start ringing when I see this: the stack is growing outside of its designated area (stack checking is switched off) and it overwrites the TCB.
A very simple bug but a bit harder to find without the OpenRTOS Viewer