edwards3 wrote on Monday, November 12, 2012:
Are you using stack overflow protection? http://www.freertos.org/Stacks-and-stack-overflow-checking.html
Your problems sound to apparently random and like the linker script or the start up code is not configured correctly, unless it is just a plain old bug in your code.
because reserving a byte on the STM32 seem to take up a long
.
The STM32 is a 32 bit machine and as such required 4 byte alignment. If you reserve a byte, it will place it in a 32 bit word. If you reserve a two byte array it will place it in two bytes of a 32 bit word. Byte bytes that are left over in the 32 bit word will not be used.
I assume from what’s been said, FreeRTOS is very neat with how it uses memory and it somehow packs chars within a long for queues.
FreeRTOS does nothing clever. It just expects the compilers being used to comply with the C standards. If you allocate 4 bytes it will give you 4 bytes, which happen to fit in a 32 bit word. If you allocate 5 bytes it will give you five bytes, which fit in two 32 bit words with 3 bytes left over (to make up the second 32 bit word). If you allocate 400 bytes, it will give you 400 bytes. That is just C code behaving like C code.
From Travfrog:
What heap file are you using (heap_1,2 or 3).
There is also heap_4.c now.
when you are defining a stack size of a heap size, the number is the number of ints so the number of bytes is 4x that
That is right. When you define a stack size it is in stack units, and on the STM32 each stack variable is 32 bits. So specifying a stack depth of 100 will allocate 100 stack variables, which is 400 bytes. That is how the API is specified and not to be confused with normal memory allocation.