Memory usage

witc wrote on Monday, August 05, 2019:

Hi,

I use CubeMX from ST with FreeRTOS version 10.0.1. I use pvPortMalloc and free in my code and sometimes it seems like the allocted memory will get corrupted. I chose heap_4. Now I am confused about memory allocation:
In Cube I can chose mem allocation as Dynamic, Static or mixed - do not exactly understand it.
Allocation for tasks I chose Static because I want to know the size of my code in RAM at link time, rather then run-time. But then I would like to know If I call pvPortMalloc() in Task_A - where it takes the mem? Does it take space from Task_A Stack?

Thanky you for explaining.

Best Regards Jan.

rtel wrote on Monday, August 05, 2019:

Like the standard C library malloc() function, pvPortMalloc() always
allocated memory from the heap - provided the heap has enough free
memory for the allocation to complete. How the heap is allocated
depends on whether you are building heap_1, heap_2, heap_3, heap_4 or
heap_5: https://www.freertos.org/a00111.html

witc wrote on Tuesday, August 06, 2019:

Thank you.

Now I have 3 static allocated tasks - altogether they have 9216 B. Also had FreeRTOS timer with 400 B and 3 queues - 888 B. Total sum is 10504 Bytes. It means the value of TOTAL_HEAP_SIZE should be set above this value is not it? For example if I set HEAP SIZE to 12000 B, then there is about 12000-10504 = 1496 Bytes for pvPortMalloc allocation?

But:
I do not understand why is possible in CubeMX to set Total Heap Size only on 8000 Bytes and everything seems to work properly even if I use a lot of pvPortmMalloc and vPortFree (which is value under the space is needed for Stacks, TCB, Queues etc.) I must point out that Tasks and queues are allocated statically with Heap_4.

Thank you for advice.

rtel wrote on Tuesday, August 06, 2019:

Statically allocated memory, by definition, does not come out of the heap. The amount of memory available for use as the heap is the total memory available, minus statically allocated memory (minus the .data section, etc.). This is how compilers and linker behave, regardless if what your build includes FreeRTOS or not.

witc wrote on Wednesday, August 07, 2019:

I am sorry but I still don’t understand.
I set TOTAL_HEAP_SIZE to 1000 Bytes, but why I can not set stack size for 3 statically allocated tasks for example to 256 words (every stack size 256 words)? At least CubeMX will not allow it.

Because as you said, if it is allocated statically -the stacks for tasks will not come form the heap memory.

rtel wrote on Wednesday, August 07, 2019:

Why can’t you set the 3 statically allocated tasks stack sizes to 256
words? What is preventing you? Is it just CubeMX that won’t let you do
it - and if so - how does it prevent you? (for example, will it just
not let you enter the number or does it let you enter the number but
then not let you link the application?

What is configSUPPORT_STATIC_ALLOCATION set to?
What if you just edit the FreeRTOSConfig.h file without using CubeMX?

witc wrote on Wednesday, August 07, 2019:

configSUPPORT_STATIC_ALLOCATION = 1 (default from Cube)

Screenshot is enclosed - this windows pops up when I try to change for example first stack size to 256

Cube allows me to set 3x 256 words but only when I increase the TOTAL_HEAP_SIZE

rtel wrote on Wednesday, August 07, 2019:

The dialog box in the screenshot seems to indicate that the stack sizes
were updated. What makes you think CubeMX is not allowing the stack
sizes to be updated?

witc wrote on Wednesday, August 07, 2019:

Please just look at my video: https://www.youtube.com/watch?v=ookcCYnF4k4&feature=youtu.be

witc wrote on Friday, August 09, 2019:

Hi Richard,
do you thing the behavior on the video is correct? (In case of static allocation of queues and tasks)

Thank you very much.

Best regards, Jan.

rtel wrote on Friday, August 09, 2019:

No idea - it is not a tool I use myself - suggest you ask ST.

dnadler wrote on Tuesday, August 13, 2019:

This is a bug in CubeMX and nuthing to do with FreeRTOS…
CubeMX stupidly checks total requested static stack space against TOTAL_HEAP_SIZE…

aggarg-aws wrote on Wednesday, August 14, 2019:

Thanks Dave. I verified this using STM32Cube IDE and the same bug exists there.

Jan, TOTAL_HEAP_SIZE and the stack sizes for statically allocated tasks are not related. You should modify the generated code.

TOTAL_HEAP_SIZE is defined in FreeRTOSConfig.h:

#define configTOTAL_HEAP_SIZE                    ((size_t)2000)

Task sizes of the statically allocated tasks are defined at the time of task creation:

osThreadId myTask02Handle;
uint32_t myTask02Buffer[ 128 ]; /* Update the stack size here. */
osStaticThreadDef_t myTask02ControlBlock;

/* Pass the updated stack size to osThreadStaticDef instead of 128. */
osThreadStaticDef(myTask02, StartTask02, osPriorityIdle, 0, 128, myTask02Buffer, &myTask02ControlBlock);
 myTask02Handle = osThreadCreate(osThread(myTask02), NULL);

Just FYI, you can directly use xTaskCreateStatic instead of going via osThreadCreate wrapper.

Thanks.

witc wrote on Wednesday, August 14, 2019:

Thank you all.

Now I’m clear about that!

Jan.