Post navigation

FreeRTOS V9.0.0 with Static Memory Allocation

I’m using FreeRTOS in most of my applications. There were only a few exceptions where an RTOS has to be used in safety critical systems: there usually it is not permitted to use any dynamic memory allocation because this adds the risk that a memory allocation could fail at runtime because of memory fragmentation or memory leak. And FreeRTOS uses a dynamic memory (heap) for the task stacks and the RTOS resources including semaphore, mutex and queues.

This is now a thing of the past. This week a new FreeRTOS Version 9 was released which does not need any dynamic memory allocation anymore: it is possible now to build completely statically allocated systems with FreeRTOS :-).

Dynamic and Static Memory Allocation in FreeRTOS V9.0.0

FreeRTOSConfig.h: Static or Dynamic?

Beside of avoiding a ‘out of memory’ at application runtime, static allocation for the RTOS resources has another benefit: if using the heap, I always have to make sure it is large enough. Means that usually it needs to be somewhat larger than really needed. That way some RAM is wasted which is a problem for small embedded systems. So having things statically allocated is a better approach to me. But using static memory allocation in FreeRTOS does not mean that I cannot use dynamic memory any more: actually I can have both if I want :-).

To configure how the memory is used,The FreeRTOSConfig.h has two more defines:

The above functions are versions of their ‘dynamic’ counterparts. Each of the ‘static’ API functions needs to have at least one additional pointer to the persistent (not on the dynamic stack!!) allocated buffer memory. For the task API an additional data pointer is needed for the TCB (Task Control Block) memory. I’m showing in the next sections examples how the API is used. I’m using macros from the FreeRTOSConfig.h to make things portable between ‘static’ and ‘dynamic’ implementations.

Application Functions for Idle and Timer Tasks

When turning on static memory allocation (configSUPPORT_STATIC_ALLOCATION), then the IDLE task will be allocated in a static way. In that case I have to provide the memory for the IDLE task with the following code:

Currently not everything in the SDK allows for static allocation. For example the USB stack in the SDK is still using dynamic allocation methods. I assume this will be updated in a next release. Otherwise you can see in the above example how I have made some of the allocation static.

Other Changes in FreeRTOS V9.0.0

New function xTaskAbortDelay() to force a task out of the blocked state by another task.

If a task gets deleted by another task with vTaskDelete(), the task stack and TCB (Task Control Block) was freed by the Idle task. Now it the memory is released right away except the task deletes itself, then still the Idle task does the release.

New hook vApplicationDaemonTaskStartupHook() which executes when the RTOS timer task starts.

Tickless idle mode can now be used with cooperative multitasking mode (configUSE_PREEMPTION set to 0).

Summary

The avoidance of any dynamic memory allocation in FreeRTOS greatly extends the usage of this already very popular RTOS especially into safety critical systems or any other critical systems. For example we have now migrated a space project at the university from different RTOS to FreeRTOS as now it fulfils the our requirements for running a payload system on a satellite. I have migrated a few robotics project from FreeRTOS V8.x.x to the V9.0.0 version without any issues.

About Erich Styger

13 thoughts on “FreeRTOS V9.0.0 with Static Memory Allocation”

The possibility of building fully statically allocated applications was one of the main requirements of the original CMSIS++ RTOS specifications, and one of the first complaints to the ARM CMSIS RTOS specs (#37, unfortunately ignored, like most others suggestions filed).

It’s good to see that other RTOSes acknowledged this important feature.

Great feature drilldown! As a developer of a safety critical filesystem for FreeRTOS (www.datalight.com/reliance-edge), the static memory allocation was great news for me. I also appreciated that they kept the version 9 changes backwards-compatible, so that users can drop in the update without redoing their code base.