嵌入式C程序任务堆栈中未使用的空白

Question

In an embedded C development running an RTOS with multiple tasks, where each task has its own stack, why would a stack have an unused gap in between used sections?

The stacks are populated with a known pattern at startup to determine worst-case stack usage. When the stack contents are viewed at run-time using an IDE memory viewer, a gap of the known pattern can be seen between normal stack data.

For example:

Stack top
-----------------
unused area
-----------
used area 2
-----------
unused area
-----------
used area 1
-----------------
Stack bottom

Why would normal stack use leave a gap instead of contiguous data?

Any suggestions appreciated, thanks

Update

To answer the questions, a single gap of 96 bytes has been seen on a single stack where the total stack size is 0x400 bytes.

Thank you for all of your comments, there are some great suggestions. In this case I can rule Alignment due to the size of the gap and the single occurrence. An uninitialised array is probably the cause as all other RAM is initially populated with the same pattern as the stacks.

My other (concerning) thought was a corrupt stack pointer but this seems unlikely as the software runs without issue.

Answer 1

The signature pattern is a method of determining stack usage, but is not a perfect mechanism - if nothing is ever written to a variable, the pattern will not be modified.

"Unused" is a misleading term; rather not modified is a better description.

This would commonly occur in instances of buffers that might not be fully utilised. For example if you had say:

char string_buff[128] ;

sprintf( string_buf, "%s", "hello" ) ;

only 6 characters of string_buff will be written, and show as a 122 byte "unused" gap.

If the code were modified thus:

char string_buff[128] = {0} ;

sprintf( string_buf, "%s", "hello" ) ;

The entire buffer would show as used at the expense of initialising the entire buffer.

Answer 2

I am not completely sure I understand you. The gaps between stacks can come from the linker inserting a safety threshold on "top" (that is, in the direction of stack increase) of each stack to protect from the situation where a tasks stack is used up completely by task routines and an interrupt occurs - in an unmanaged situation the interrupt, in fact all possible interrupts which are allowed by the priority protocol of your CPU, may add on top of each tasks maximum stack usage. In a managed situation (most RTOS manage interrupt handling, or can at least be configured to do so) at least a small portion for the interrupt entry will temporarily reside on the task stack until the OS vectoring has moved to a system stack which will handle stacking the current and all higher priority ISRs. Thus also in a managed interrupt scheme there needs to be a safety margin on top of each stack.