Electronics > Microcontrollers

Weird issue with local variables located *outside* a FreeRTOS task stack

(1/3) > >>

peter-h:
ST 32F417 (arm32). ST Cube IDE.

This is the relevant part of a task called APP:


--- Code: ---// 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;
}


--- End code ---

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).

abyrvalg:
Stack on Thumb grows downwards, so the initial SP of APP is 100051F8 + 2k = 100059F8, so your buf is well within the declared area and “Top of stack” is SP value after grows downwards.

peter-h:
All stacks I have ever seen grow downwards; it is the value being reported in the FreeRTOS debugging feature in Cube (Eclipse) which shows only a part of it.

I think the distance between these two points in the memory dump is actually the stack value specified in the task invocation



It would be good to be able to see the stack remaining for each task during operation. The ST sample code includes an http server in which you can see the stack high water mark e.g.



but those values aren't directly usable either. What is needed is a task which plots the whole RTOS memory (the whole 64k CCM in this case) onto a graphical LCD, a pixel for each byte which is 0xA5 :) A good programming exercise ;)

bson:
Perhaps FreeRTOS allocates stacks on the heap when tasks/threads are created.

jc101:

--- Quote from: bson on May 18, 2022, 05:30:46 pm ---Perhaps FreeRTOS allocates stacks on the heap when tasks/threads are created.

--- End quote ---

Yep, a task's stack is allocated from the FreeRTOS heap when the task is created...

https://www.freertos.org/a00125.html

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version