Memory and resource management

Real-time systems fail in time and in space. A control loop can miss its deadline, but it can also overflow its stack, run out of heap after three days of uptime, or have its variables overwritten by a buggy logging task. Memory faults are among the hardest embedded bugs to find, because the code that crashes is often not the code that caused the damage. This lesson covers how memory is laid out on a microcontroller, why dynamic allocation is avoided or tightly controlled in real-time code, how to size and monitor stacks, how memory protection units contain faults, and the coding rules, such as MISRA C, that safety-related robot software commonly follows.

The memory map of an embedded program

A microcontroller program occupies a few distinct regions. Code and constant data live in flash. RAM holds the data section (initialized globals, copied from flash at start-up), the bss section (zero-initialized globals), the heap (memory handed out at run time by malloc or an RTOS allocator) and one or more stacks: the main stack used at start-up and by interrupt handlers, and in an RTOS a separate stack for each task. Many processors also have small tightly coupled memories, fast RAM directly attached to the core with single-cycle access and no cache effects, which are ideal for the hottest control code and its data.

The linker script decides where everything goes, and the map file it produces lists the size and address of every function and variable. Reading the map file is a basic real-time skill: it shows which modules use the most RAM, whether critical code landed in fast memory, and how much space is left.

Why dynamic allocation is avoided

General-purpose malloc and free have two problems for real-time code. Their execution time is variable and often unbounded, because the allocator searches free lists that change with the history of allocations. And repeated allocation and freeing of different-sized blocks fragments the heap: after hours or days, enough memory may be free in total but not in any single block large enough for a request, so an allocation fails in a system that passed every test. Both problems get worse the longer the system runs, which is exactly the wrong property for a robot expected to run for weeks.

The common rules are therefore: allocate everything at start-up and never free it; use fixed-size block pools, whose allocate and free operations take constant time and cannot fragment; or use static allocation throughout. FreeRTOS supports fully static creation of tasks, queues and semaphores (the xTaskCreateStatic family), and offers several heap implementations, from heap_1, which allocates but never frees, to heap_4 and heap_5, which coalesce free blocks. Zephyr provides memory slabs (fixed-size blocks) and statically defined kernel objects. In C++ robot code on Linux, real-time threads avoid heap allocation in the control loop by preallocating containers, reserving vector capacity and using custom allocators; ROS 2's real-time guidance makes the same point.

# Fragmentation: interleaved lifetimes leave free memory in small pieces
HEAP = 64 * 1024
blocks = []                        # (start, size, kind)
addr = 0
while addr + 264 <= HEAP:          # a message buffer, then a long-lived record
    blocks.append((addr, 200, "msg")); addr += 200
    blocks.append((addr, 64, "rec")); addr += 64
used = sum(n for a, n, k in blocks)
# later, all short-lived message buffers are freed; records stay
free = [(a, n) for a, n, k in blocks if k == "msg"] + [(addr, HEAP - addr)]
total_free = sum(n for a, n in free)
largest = max(n for a, n in free)
print("heap %d bytes, %d blocks allocated" % (HEAP, len(blocks)))
print("after freeing messages: %d bytes free (%.0f %%)" % (total_free, 100 * total_free / HEAP))
print("largest free block: %d bytes in %d pieces" % (largest, len(free)))
for request in (128, 512, 1500):
    print("request %4d bytes:" % request, "ok" if largest >= request else "FAILS")

heap 65536 bytes, 496 blocks allocated
after freeing messages: 49664 bytes free (76 %)
largest free block: 200 bytes in 249 pieces
request  128 bytes: ok
request  512 bytes: FAILS
request 1500 bytes: FAILS

Three quarters of the heap is free, yet no request larger than 200 bytes can succeed, because every free piece is trapped between long-lived records. Real heaps fragment more slowly and less neatly, through the random interleaving of allocations with different lifetimes, but the end state is the same. A fixed-size pool for each common block size cannot fragment this way, because any freed block fits any future request of the same size.

Stacks: sizing and overflow

Each task's stack holds its local variables, function return addresses and saved registers, and in a preemptive kernel its full context when it is not running. Interrupt handlers on Cortex-M use a separate main stack, which must hold the deepest possible nesting of interrupts. A stack that is too small overflows silently into whatever lies next to it, corrupting another task's data or a kernel structure; a stack that is too large wastes scarce RAM. Stack overflow is one of the most common causes of mysterious resets in embedded robots.

There are two ways to size stacks. Static analysis tools compute the worst-case depth from the call graph and each function's frame size, which compilers such as GCC report with the -fstack-usage option; this is exact for code without recursion or function pointers, which is one reason coding standards ban recursion. Measurement uses stack painting: fill each stack with a known pattern at start-up, run the system hard, and see how much of the pattern has been overwritten. FreeRTOS reports this as the high-water mark (uxTaskGetStackHighWaterMark), the minimum free stack ever seen.

Overflow detection should be on in every build that goes near a robot. RTOSes can check the stack pointer and a guard pattern at each context switch (FreeRTOS's configCHECK_FOR_STACK_OVERFLOW), Armv8-M processors have stack-limit registers that fault immediately on overflow, and a memory protection unit can place a no-access guard region at the end of each stack so that the first stray access faults instead of corrupting data.

Memory protection

A memory protection unit (MPU), found on most Cortex-M3 and higher cores and on Cortex-R processors, lets privileged code define a small number of regions (typically 8 or 16) with access permissions: read-only, read-write, no execute, privileged only. A task that touches memory outside its regions triggers a fault instead of silently corrupting something. MPUs differ from the memory management units of application processors: they do not translate addresses or provide virtual memory, so they add almost no timing uncertainty, which suits real-time use. Zephyr's user mode and FreeRTOS's MPU ports run tasks unprivileged with access only to their own stacks and explicitly shared regions, so a bug in a communications task cannot overwrite the control task's data.

Protection is how mixed-criticality systems are built. A robot controller may combine a safety-related joint monitor, a hard real-time control task and a large, frequently updated communications stack. Placing them in separate protection domains, or on separate cores, contains faults so that a bug in the large, less trusted code cannot break the small, trusted code. Lesson 11 returns to this as freedom from interference, a requirement of the functional safety standards.

Coding standards for real-time and safety code

Many robot companies, and all safety-certified projects, write embedded C to a coding standard. MISRA C, first published by the Motor Industry Software Reliability Association in 1998 and now in its 2023 edition, is the most widely used. Its rules restrict the parts of C whose behaviour is undefined, implementation-defined or error-prone: no dynamic memory allocation after initialization, no recursion, explicit types and casts, no unreachable code, limited use of pointers, and every switch with a default case. Many rules exist precisely to make timing and memory possible to analyse: banning recursion makes worst-case stack depth computable, and banning heap use after start-up removes fragmentation and unbounded allocation time. AUTOSAR's C++14 guidelines and the MISRA C++ 2023 standard play the same role for C++, and CERT C focuses on security. Static analysis tools check conformance automatically, and deviations must be justified and recorded.

Rust is attracting interest in embedded robotics because its ownership rules prevent data races and many memory errors at compile time, and it can run without a heap. A safety-qualified Rust compiler (Ferrocene) has been certified to ISO 26262 and IEC 61508, which has started to make Rust usable in safety-related projects, though C and C++ remain dominant in shipped robot firmware.

Other resources: buses, peripherals and energy

Memory is not the only shared resource with timing consequences. A single SPI or I2C bus shared by several sensors serializes their transfers, so a long transfer to one device delays the others; the bus is a resource with its own critical sections, and its worst-case wait belongs in the blocking term of each task that uses it. DMA channels, hardware timers and crypto accelerators are similar. On battery-powered robots, energy is also a resource: low-power modes save energy but add wake-up latency, which must be counted in interrupt latency budgets.