I’m having problems with crashing on an STM32. If I remove one thread it at least starts running, even if it crashes when a queue gets something in it that delves into a certain other thread. I’ve created a spreadsheet, listing stack sizes and queues trying to work out whether I’m anywhere near running out of RAM. It would appear not, even though I must be. One thing I am not clear about is chars, ints and longs and how much space they take on the STM32 with free RTOS. If I have a queue that is ten chars long, is it really ten longs long? ie does a char, really take up four bytes, ie a long? (As well as the standard 76 bytes? A queue always takes?) Also, that 76 byte overhead for the queue, is that really 76 longs? I do have a LOT of queues (possibly naivety on my part) and I suppose if every byte really took up a long, I would be hitting the heap size. Many thanks.

AFIAK, on STM32 all sizes are the same as you would expect on any 32 bit processor. chars are 1 byte, ints and longs are 4 bytes. Also you have not mentioned what crash are you seeing. Stack overflow, heap overflow or some other ? - Kaustubh

If I have a queue that is ten chars long, is it really ten longs long?

No, but neither is it ten chars long.  The space taken is the size of the queue structure itself, and the size of the queue storage area.  The size of the queue structure is fixed.  In the case of this example, the queue storage area is 10 bytes (the size that was requested).

Also, that 76 byte overhead for the queue, is that really 76 longs?

No, otherwise it would be 304 bytes. What makes you think you are running out of RAM.  RAM for queues comes from the FreeRTOS heap (http://www.freertos.org/a00111.html).  If you want to know if you are running out of FreeRTOS heap you can defined a malloc failed hook function (http://www.freertos.org/a00016.html), or depending on the memory alloctor being use xPortGetFreeHeapSize(). Regards.

Could you show me your task create function call?

Thanks for the replies and and sorry for the delay in replying, I didn’t get a notification of a reply. I think it’s RAM because removing a task took it from crashing to not crashing (with a HardFaultException).  What I did was remove the USB code as it’s not often used in normal operation and it went from crashing once a key is pressed to not crashing unless you go into “set-up mode”. Once this mode is entered, code that is not normally executed is called, so I assumed I was overflowing its stack; increasing its stack size brings the other problem back where it crashes on a keypress, which made me think I was right on the edge of code usage. I have also had situations where it would crash as soon as the scheduler was started unless I did something like reduce the size of the stack in a thread to free up an extra bit of memory. I think it’s a fair question to ask about longs v  bytes, because reserving a byte on the STM32 seem to take up a long. 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. An example of task creation is: xTaskCreate(ProcessKeys, ( signed char * ) “Process Capacitive Keys”, PROCESS_KEYS_STACK_SIZE, NULL, mainProcessKeys_TASK_PRIORITY, NULL ); When I looked at where FreeRTOS had crashed when it hit a HardFaultException, it was usually the same task, but not always.

And indeed, I just hit an application task overflow error. Increasing the stack size of the offending task crashes the scheduler!

Do you have a build map that shows the RAM and Flash usage for your project? I have found the HardFaultException was usually a bad pointer or bad array use – it did not ever seem to be related to the RTOS. In FreeRTOSConfig.h you allocate heap for the OS. It uses that to create your stacks and Queues (btw, I meant to ask for an example of the xCreateQueue call). If it can’t alloc what it needs, it will call the vApplicationMallocFailedHook (assuming you’ve enabled it). Point a break point in there and see if ever happens. I also found the size of bytes and ints a bit of a struggle to figure out. 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. What is the structure of the data you are posting around in the messages? Are you using vApplicationIdleHook – that’s really useful to see if you system is locking up somewhere as this is only serviced when there is nothing for the OS to handle. Are you clearing the interrupt pending bit inside the interrupt handlers? If that bit remains set then as soon as the interrupt is complete it will run again and again – this can also lead to a hard fault. What heap file are you using (heap_1,2 or 3). If you are using heap 3 with full malloc and free functionality and not freeing memory after allocating it at run time then you’ll blow up also. Regards
travfrog

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.