Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

RAM usage: bytes vs long on STM32

Posted by DiBosco on November 9, 2012
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.

RE: RAM usage: bytes vs long on STM32

Posted by Kaustubh on November 10, 2012
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

RE: RAM usage: bytes vs long on STM32

Posted by Richard on November 10, 2012
“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.

RE: RAM usage: bytes vs long on STM32

Posted by Richard on November 10, 2012
Could you show me your task create function call?

RE: RAM usage: bytes vs long on STM32

Posted by DiBosco on November 12, 2012
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.

RE: RAM usage: bytes vs long on STM32

Posted by DiBosco on November 12, 2012
And indeed, I just hit an application task overflow error. Increasing the stack size of the offending task crashes the scheduler!

RE: RAM usage: bytes vs long on STM32

Posted by Richard on November 12, 2012
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

RE: RAM usage: bytes vs long on STM32

Posted by MEdwards on 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS