Motivation
On both armv7m and ppce500, documentation for the stack_size parameter of each task seems to be inconsistent with the implementation.
From the stack_size documentation (assumes bytes):
This configuration item specifies the task's stack size in bytes (also see [Task Stacks]).
From the context initialization code comments (assumes bytes):
@param stack_size The size in bytes of the stack memory area reserved for this execution context.
From the context initialization code on armv7m (assumes words):
uint32_t *context;
context = stack_base + stack_size - CONTEXT_SIZE;
From the RTOS stack code on armv7m (assumes words):
static uint32_t stack_{{idx}}[{{stack_size}}] __attribute__((aligned(8)));
So the armv7m implementation assumes words (it also does on ppce500).
But the documentation and comments assume bytes.
Since the linker just uses sections for task stacks, the implementation looks fine to me, and explains why we haven't run into this as a bug before.
Note that these stack sizes are distinct to the vectable stack size, which is only used for main before the RTOS starts. (This seems to actually correspond to the documentation (both in bytes))
Goals
- Make the documentation consistent with the implementation.
- Can either make both use words, or both use bytes
Motivation
On both
armv7mandppce500, documentation for thestack_sizeparameter of each task seems to be inconsistent with the implementation.From the
stack_sizedocumentation (assumes bytes):From the context initialization code comments (assumes bytes):
From the context initialization code on armv7m (assumes words):
From the RTOS stack code on armv7m (assumes words):
So the armv7m implementation assumes words (it also does on ppce500).
But the documentation and comments assume bytes.
Since the linker just uses sections for task stacks, the implementation looks fine to me, and explains why we haven't run into this as a bug before.
Note that these stack sizes are distinct to the vectable stack size, which is only used for
mainbefore the RTOS starts. (This seems to actually correspond to the documentation (both in bytes))Goals