Why does my STM32CubeIDE -> Window -> Show View -> FreeRTOS -> FreeRTOS Task List -> FreeRTOS Task List -> Stack Usage only show 1/4 of the actual usage in percent for Tmr_Svc?

[arnold_w]

I'm working with the "NUCLEO-U575ZI-Q" development board and I compile using STM32CubeIDE 1.11.0. My project uses FreeRTOS and I have clicked Window -> Show View -> FreeRTOS -> FreeRTOS Task List. When I look at the Stack Usage for Tmr_Svc it appears that it reports 4 times as much than what has been truly allocated, resulting in the usage percent being one quarter of what it should be. So, if I truly allocate 256 bytes (configTIMER_TASK_STACK_DEPTH 256) of stack for Tmr_Svc and end up using 128 bytes of it, then this column will show 128/(4 x 256 + 4) = 12.5% when the true usage is actually 50%. What am I doing wrong?

[Bob S]

Stack size is number of 32-bit words not bytes. So your configTIMER_TASK_STACK_DEPTH of 256 means 256 DWORDS or 1024 bytes.

[arnold_w]

I looked at the address of the stack in RAM and then went backwards until I found all the 0xA5-bytes and I counted 308 bytes (not words) in this range. Hence, my application needed 308 bytes of stack. When I set configTIMER_TASK_STACK_DEPTH  to less than 308 then my application would eventually hang, but it would work fine if I set configTIMER_TASK_STACK_DEPTH  to 312 or higher. According to Window -> Show View -> FreeRTOS -> FreeRTOS Task List -> Stack Usage I was using 312 and when I set configTIMER_TASK_STACK_DEPTH to 312 then it said my utilization was 25%. Again, whenever my utilization was below 25%, my application would work fine, but when it went above 25% then application would eventually hang. I would expect the limit to be at 100%, not 25%.

[Bob S]

Maybe this is a bug in the STM32U5 FreeRTOS cmsis code, or CubeIDE 1.11. I can't verify that as I haven't used the STM32U family, don't have any F4/F7 projects handy with stack monitoring enabled. But somewhere there is obviously a missing "multiply by 4".

Maybe the U5xx is different, but I would be surprised if the stack size were declared as "bytes" rather than "32-bit words" for any 32-bit ARM CPU. Search for everywhere configTIMER_TASK_STACK_DEPTH is used in the code. At least on the F4/F7 chips, in xTaskCreate() the malloc() call allocates "depth*4" bytes. And if timer task stack is statically allocated then the stack is declared in vApplicationGetTimerTaskMemory() as type "StackType_t", which is an alias for "uint32_t" (again, for the F4/F7 family).

I can't see how you are looking at memory to verify you are really counting bytes and not words.

It is also possible to have "unmodified" sections of stack. For example, is you allocate something like "int array[100]" in a function, that will allocate 4*100 bytes on the stack. But if you only store data in the first 10 elements, there will be 90 elements (360 bytes) that look like "unused stack" between that array and any other local variables and/or stack frame data. I don't know if the FreeRTOS timer task does anything like that.

[Bob S]

or maybe bug in CubeIDE's STLink FreeRTOS "RTOS proxy"?