Understanding FreeRTOS Task Stack Usage and Kernel Awareness Info
Diving into FreeRTOS' Task Lisk in MCUXPresso can be confusing at first. Let's look into how to examine and understand how your stack is being used.
Join the DZone community and get the full member experience.Join For Free
When using the FreeRTOS Task List in the Eclipse-based MCUXpresso IDE, it shows the list of tasks with their stack size used. But with the default FreeRTOS settings, it is not able to determine the correct stack size and shows a warning icon:
The warning should tell me that the information shown about the stack size is wrong: I did create the App Task with 110 stack units (each 4 bytes) so it should show 440 bytes, but it shows only 308 bytes.
Why is that? The reason is that the debugger (or FreeRTOS Kernel Awareness in Eclipse) does not know the total size of the memory allocated for the task.
On ARM Cortex, the stack is growing from the higher to the lower addresses, as shown in the image below:
What FreeRTOS stores in its TCB (Task Control Block, the descriptor of the task) is the pxTopOfStack (current task stack pointer, Stack Top in the Kernel Awareness view) and pxStack (the end of the stack, Stack Base in the Kernel Awareness view). The beginning of the task stack is not stored in the TCB as not necessary for the Kernel.
The ‘Stack High Water Mark’ is something very useful: FreeRTOS fills the stack space at task creation time with a 0x5a byte pattern. The debugger or the RTOS can find out the ‘high water mark’ for each task that way.
The solution is to add the following macro to the FreeRTOSConfig.h file:
#define configRECORD_STACK_HIGH_ADDRESS (1)
With this turned on, FreeRTOS stores an extra pointer pxEndOfStack in each Task TCB:
Below is such a TCB in the Global Variables View in Eclipse (MCUXpresso IDE):
With this, the debugger or FreeRTOS Task Awareness knows the real size of the stack and can show the correct information:
Actually, it is still showing 432 bytes because it does not count the first and last entry on the stack.
The image below should help you understand the information provided:
- Blue: At the bottom, there is the currently used stack. The stack is growing upwards here (from the higher to the lower addresses).
- Orange: Used stack so far (high water mark) as it has overwritten the 0xA5 pattern.
- Yellow: Unused stack space so far with the 0xA5 pattern.
Of course, there is a reason for FreeRTOS not storing that pxEndOfStack by default: It is not needed by the Kernel. So enabling configRECORD_STACK_HIGH_ADDRESS will need 4 more bytes of RAM for each task, plus a few code bytes to set that value. But for debugging purposes, this is very well spent.
Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.