Variable created inside task, where should it be allocated?

Hi there,
I’m a newbie in FreeRTOS and at my second “real” project using it, i’m still trying to understand

  • How much size should the task stack have
  • What does the task stack actually hold

For context, the device is a dsPIC33CK and i am using the Microchip Port for freeRTOS v9 present on their github —> GitHub - MicrochipTech/freeRTOS-PIC24-dsPIC-PIC32MM: This repository contains the freeRTOS demos for Microchip device families like PIC24, dsPIC33E, dsPIC33F , dsPIC33C and PIC32MM.
compiler is XC16 v1.70
(by the way, the main site and official repo demos should really be updated to use current development tools)

In my project i do not use the heap, but all tasks, queues etc are created using the “static” api calls.

Now, to my question: it was my understanding that automatic variables created inside a task would be allocate inside the task’s stack so let’s take this code

//There will be a 256 byte buffer #define BUFSIZE 256UL //The stack size will be of 300 words - 600bytes in the dsPIC port (machine word is 16bit!) #define STACKSIZE 300

StaticTask_t xTaskBuffer; StackType_t xTaskStack[STACKSIZE];

void vTaskCreate(void) { xTaskCreateStatic(&vTask, "TASK", STACKSIZE, NULL, configMAX_PRIORITIES-1, xTaskStack, &xTaskBuffer); }

void vTask(void *prvTaskData) { uint8_t buf[BUFSIZE]; while(true) { //Do stuff } }

To my understanding the address of “buf” should be between the address of xTaskStack and that plus 600bytes.
Instead i see in the debugger that
xTaskStack is at address 0x14CE
buf is at address 0x13C4, 266 bytes before

Also, checking with the FreeRTOS Viewer plugin in MPLABX shows stack usage of 71 words, same as the idle task

What am i missing here?

The stack is usually growing downwards. Seems this also applies to your platform.

Well, yes it is.
But how does it help with my question?

I thought you were asking why the address of buf is lower than stack start :thinking:
For me the buf address looks good.
Or do you want to know why MPLABX shows a stack size you don’t expect ?
You might try to init buf e.g. filling it with zeroes and check again with MPLABX.
I guess it’s determining the end of stack by searching for the stack fill pattern applied with stack checking enabled as far as I know.

The stack grows up on a dsPIC: FreeRTOS-Kernel/portmacro.h at V10.4.6 · FreeRTOS/FreeRTOS-Kernel · GitHub

The compiler and linker determine where variables get allocated, so whether using FreeRTOS or not, dynamic variables will normally end up on the stack (or possibly just in a register, depending on its size and the compiler optimisation level). If that isn’t the case then look in the map file to see if the variable got allocated somewhere else, and/or in the assembly code to see how the compiler is using the stack on function entry and how the function is accessing the variable. It might be the compiler is doing some fancy optimisation to minimise stack use - which would be worrying as that would also make it non thread safe.

1 Like

today i have resumed development and strangely enough (not) things are now as expected.
Yesterday MPLABX was acting fuzzy all day, refusing to solve identifiers and paths and today things are back to normal (It’s not unheard of. It does affect programming and debugging, somehow. This is probably the third time it happens to me in more than six years. Usually a reboot will suffice)

So, i launched a new debug session and now the Task stack is at address 0x17A6, the local buffer is at address 0x17A8, the word after the start of task stack. The RTOS viewer plugin reports a higher number of bytes of stack used, from a quick calculation that checks out

Should i declare it a case closed?

Done that for you. You can still post again if you have more information on the same subject.