ST 32F417 (arm32). ST Cube IDE.
This is the relevant part of a task called APP:
// Simple RTOS thread for testing stuff
void vAPPTask(void *pvParameters)
{
uint32_t count=0;
uint32_t err=0;
uint32_t page=0;
uint8_t buf[512];
// some code to stop buf[] getting optimised out
for (int i=0; i<512; i++)
{
buf[i]=0xfe;
}
In Cube IDE you can get a display of the FreeRTOS tasks (once stopped e.g. with a breakpoint) e.g.
Notice the APP task stack start and end addresses.
Now look at where buf[] is located in the variables list
It is entirely outside the task stack.
The SP is 0x100057e8 i.e. at the address of buf[0].
It looks like the stack allocation declared by FreeRTOS is
after all local (stack based) variables within that task have been allocated.
I prefill the whole FreeRTOS stack area with 0xA5 so this memory dump shows (the uppermost part) the unused part of it
It also shows buf[512] filled with 0xFE with my loop, as expected. In between the two is some stuff like initialised variables.
At the very bottom of the memory dump is the unused stack of the next task. And so it goes, all the way up the memory (which is the CCM actually, 0x10000000 and for 64k).
Is this how it is supposed to work?
The APP task is created with
xTaskCreate(vAPPTask, "APP", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL);
so it gets 512 words i.e. 2k bytes of stack.
But all these numbers are a bit vague and don't really add up.
The only foolproof way I have found of checking that the allocated stacks aren't overflowing is to look at the memory dump and see there is plenty of 0xA5s left for each task.
FreeRTOS offers a stack check feature which I think check if there is enough each time it switches tasks (only).