Memory Management in Embedded C: Static Allocation, Pool and Arena Patterns

For years I treated memory management in embedded C as an afterthought, something the compiler and linker would quietly handle while I focused on peripherals and protocols. That changed after a deployment of battery-powered sensor nodes that ran flawlessly for three weeks and then started failing with silent data corruption and sporadic resets. The root cause was not a hardware bug or a stack overflow in the traditional sense, but heap fragmentation from occasional use of malloc() and free() in a driver. On a 64 KB RAM Cortex-M4, the heap had degraded into unusable fragments, and there was no MMU to save us. Since then, I have moved every production firmware project to a strict no-heap policy, relying on three patterns: disciplined static allocation, fixed-block memory pools, and arena allocators. Each solves a different lifecycle problem, and understanding when to apply them is what separates firmware that passes lab tests from firmware that survives years in the field.

Why malloc() and Friends Become a Liability on Resource-Constrained MCUs

In my experience, the standard C heap is a poor fit for most microcontrollers. It was designed for general-purpose systems with virtual memory, large RAM pools, and an operating system that can reclaim resources. On an MCU with 32 KB to 512 KB of SRAM, no MMU, and real-time deadlines, its non-deterministic behavior introduces risks that are difficult to test for and nearly impossible to debug in the field.

The Hidden Costs of the C Heap

A typical newlib or newlib-nano heap implementation uses a linked list of free blocks with first-fit allocation. Allocation time is O(n) where n is the number of free blocks, and free() must coalesce adjacent blocks. Under load, this creates two problems: timing jitter and fragmentation. I once measured malloc(128) on an STM32F407 at 1.2 µs when the heap was clean and over 18 µs after 48 hours of simulated network traffic that allocated and freed variable-sized MQTT payloads. That jitter is unacceptable if you are calling it from a task that feeds a control loop or services a time-sensitive peripheral.

Fragmentation is the more insidious issue. Even if you always free what you allocate, the heap can become partitioned into small, non-contiguous holes. If you need a 1 KB contiguous buffer for a TLS handshake and the largest free block is 512 bytes, the allocation fails despite having 4 KB free in total. On embedded targets, failure handling is often limited to resetting the device, which masks the underlying defect. The FreeRTOS Documentation explicitly warns about this and provides alternative schemes that avoid the standard heap entirely for this reason.

Determinism Over Convenience

The alternative is to trade runtime flexibility for compile-time predictability. If you know at compile time how many CAN frames, sensor samples, or network packets can be in flight simultaneously, you can pre-allocate for that worst case. The firmware either works from power-on or it fails to link, which is a far better outcome than failing after 30 days. This philosophy also simplifies safety certification and watchdog analysis, because memory usage becomes a static property you can inspect in the map file rather than a dynamic property you must infer from testing.

That does not mean you should ban all dynamic behavior. I still allocate dynamically, but I do it through structures I control, with bounded capacity and constant-time operations. That is where pools and arenas come in.

Sizing and Placing Static Buffers Without Wasting Flash or RAM

Static allocation is the foundation. Every global, static, and file-scope buffer is placed by the linker, so you know exactly where it lives and how much it costs. The challenge is doing it without creating wasteful, oversized buffers or accidentally placing large objects in the wrong memory region.

On multi-region MCUs like the STM32H7 or nRF5340, you often have DTCM, SRAM1, SRAM2, and backup SRAM with different wait states and DMA accessibility. I have seen projects where a 20 KB DMA buffer was placed in DTCM, making it invisible to the DMA controller and causing a bus fault. The fix is to be explicit with section attributes and linker scripts rather than relying on defaults.

// static_buffers.h
#include <stdint.h>
#include <stddef.h>

#define SENSOR_SAMPLE_COUNT  256
#define DMA_BUFFER_SIZE      2048

// Place DMA-accessible buffers in a dedicated section
__attribute__((section(".sram1_dma"), aligned(32)))
static uint8_t dma_rx_buffer[DMA_BUFFER_SIZE];

__attribute__((section(".sram1_dma"), aligned(32)))
static uint8_t dma_tx_buffer[DMA_BUFFER_SIZE];

// DTCM for fast, CPU-only data
__attribute__((section(".dtcm")))
static int16_t sensor_history[SENSOR_SAMPLE_COUNT];

// Compile-time check: fail build if we exceed budget
_Static_assert(sizeof(sensor_history) + sizeof(dma_rx_buffer) < (32 * 1024),
               "Static buffers exceed SRAM1 budget");

// Zero-initialized vs. No-init: use .noinit for buffers you don't need cleared on reset
__attribute__((section(".noinit")))
static uint8_t reboot_preserved_log[512];

Three practices have saved me significant RAM. First, use _Static_assert to enforce memory budgets in code, not just in documentation. Second, prefer .noinit or .bss over .data for large buffers to avoid consuming flash for initial values that are all zeros anyway. Third, always align DMA buffers to cache line size (typically 32 bytes on Cortex-M7) and flush/invalidate caches explicitly. Misalignment does not just hurt performance; on cache-coherent MCUs it causes silent corruption.

For configuration and calibration data that should survive firmware updates, I place structures in a dedicated flash section with a CRC footer. This lets the bootloader validate them without duplicating code. When you need to evaluate whether these statically allocated resources should be owned by tasks or by bare-metal ISRs, the discussion in Bare Metal vs RTOS: When Each Approach Makes Sense provides a useful framework for deciding how much infrastructure you actually need.

Building a Deterministic Fixed-Block Memory Pool in C

Static buffers work when every object is the same lifetime and size. They fail when you need to handle a variable number of concurrent objects, such as active network packets, LoRaWAN downlinks, or sensor events queued for processing. A fixed-block memory pool gives you dynamic allocation with static guarantees: allocation is O(1), fragmentation is zero, and you can prove the maximum memory usage.

The idea is simple. You pre-allocate an array of N blocks of identical size and manage them with a free list. I implement pools without any heap calls, with an optional critical section for thread safety. In my current codebase, every pool is statically declared with a macro that creates both storage and metadata.

// mem_pool.h
#include <stdint.h>
#include <stdbool.h>
#include <stddef.h>

typedef struct mem_pool {
    void *free_list;
    uint8_t *storage;
    size_t block_size;
    size_t block_count;
    size_t free_count;
} mem_pool_t;

// Initialize pool over pre-allocated storage
void mem_pool_init(mem_pool_t *pool, void *storage, size_t block_size, size_t block_count);

// O(1) alloc / free - safe to call from thread context
void *mem_pool_alloc(mem_pool_t *pool);
void mem_pool_free(mem_pool_t *pool, void *block);

// Implementation
void mem_pool_init(mem_pool_t *pool, void *storage, size_t block_size, size_t block_count) {
    pool->storage = (uint8_t *)storage;
    pool->block_size = (block_size + 3) & ~3u; // force 4-byte alignment
    pool->block_count = block_count;
    pool->free_count = block_count;
    pool->free_list = NULL;

    // Build free list: each free block stores pointer to next
    for (size_t i = 0; i < block_count; i++) {
        void *block = pool->storage + (i * pool->block_size);
        *(void **)block = pool->free_list;
        pool->free_list = block;
    }
}

void *mem_pool_alloc(mem_pool_t *pool) {
    // In an RTOS, wrap this with taskENTER_CRITICAL() / taskEXIT_CRITICAL()
    // or use a mutex if blocking is acceptable. Never block inside ISR.
    if (pool->free_list == NULL) {
        return NULL; // explicit back-pressure, not a silent failure
    }
    void *block = pool->free_list;
    pool->free_list = *(void **)block;
    pool->free_count--;
    return block;
}

void mem_pool_free(mem_pool_t *pool, void *block) {
    if (block == NULL) return;
    // Optional debug: check that block belongs to this pool's storage range
    *(void **)block = pool->free_list;
    pool->free_list = block;
    pool->free_count++;
}

Usage then becomes explicit and bounded:

// app_buffers.c
#define PACKET_POOL_COUNT  16
#define PACKET_BLOCK_SIZE  256

static uint8_t packet_storage[PACKET_POOL_COUNT * PACKET_BLOCK_SIZE] __attribute__((aligned(4)));
static mem_pool_t packet_pool;

void app_init(void) {
    mem_pool_init(&packet_pool, packet_storage, PACKET_BLOCK_SIZE, PACKET_POOL_COUNT);
}

void handle_uplink(void) {
    uint8_t *buf = mem_pool_alloc(&packet_pool);
    if (!buf) {
        // Handle exhaustion: drop packet, increment metric, return
        // This is observable and testable, unlike heap fragmentation
        return;
    }
    // ... fill buf ...
    // Pass ownership to queue, free later after transmission
}

I've found that sizing pools correctly requires production telemetry. I add a high-water mark counter to each pool and expose it via debug shell. If a pool hits zero free blocks during soak testing, I either increase its count or add flow control. Never grow a pool dynamically, that defeats the purpose. For RTOS-based designs, Zephyr's k_mem_slab and FreeRTOS's heap_4.c with static allocation are production-tested versions of the same pattern. The Zephyr Project Documentation has excellent guidance on slab configuration and alignment.

One constraint to respect: do not call mem_pool_alloc from an ISR if it uses a mutex. For ISR-to-task handoff, I use a pool combined with a lock-free queue or I allocate in task context after the ISR signals with a semaphore. The principles in Interrupt Handling Best Practices: Priority, Latency and ISR Design apply directly here.

Arena Allocation for Message Parsing and Temporary Lifecycles

Pools are ideal when objects have independent lifetimes. Arenas, also called linear or bump allocators, solve the opposite problem: many small, short-lived allocations that all die together. Think of parsing a CBOR or JSON configuration message, decoding a BLE advertisement, or building a temporary response packet. Using a pool for each string or field is wasteful, and using the heap reintroduces fragmentation.

An arena is a contiguous buffer with a bump pointer. You allocate by advancing the offset, and you free everything at once by resetting the offset to zero. No per-block bookkeeping, no fragmentation, and extremely fast.

// arena.h
#include <stdint.h>
#include <stddef.h>
#include <assert.h>

typedef struct {
    uint8_t *buffer;
    size_t capacity;
    size_t offset;
    size_t high_watermark;
} arena_t;

void arena_init(arena_t *arena, uint8_t *buffer, size_t capacity);
void *arena_alloc(arena_t *arena, size_t size, size_t align);
void arena_reset(arena_t *arena);
size_t arena_remaining(const arena_t *arena);

void arena_init(arena_t *arena, uint8_t *buffer, size_t capacity) {
    arena->buffer = buffer;
    arena->capacity = capacity;
    arena->offset = 0;
    arena->high_watermark = 0;
}

void *arena_alloc(arena_t *arena, size_t size, size_t align) {
    // Align bump pointer (align must be power of two)
    size_t current = (size_t)(arena->buffer + arena->offset);
    size_t aligned = (current + (align - 1)) & ~(align - 1);
    size_t new_offset = (aligned - (size_t)arena->buffer) + size;

    if (new_offset > arena->capacity) {
        return NULL;
    }
    arena->offset = new_offset;
    if (arena->offset > arena->high_watermark) {
        arena->high_watermark = arena->offset;
    }
    return (void *)aligned;
}

void arena_reset(arena_t *arena) {
    arena->offset = 0;
}

// Example: per-message parsing
void process_command(const uint8_t *msg, size_t len) {
    static uint8_t arena_storage[1024] __attribute__((aligned(8)));
    arena_t arena;
    arena_init(&arena, arena_storage, sizeof(arena_storage));

    // All allocations for this message come from the arena
    char *topic = arena_alloc(&arena, 64, 4);
    uint8_t *payload_copy = arena_alloc(&arena, len, 4);
    // ... parse, validate, act ...

    // Single operation frees everything, no risk of leak
    arena_reset(&arena);
    // For RTOS tasks, you can keep arena_storage as task static or TLS
}

The key insight is lifecycle grouping. If you can define a clear scope where all temporary data is invalid after the scope exits, an arena is the cleanest tool. I use one arena per task for request processing and reset it at the top of the task loop. I also use stack-based arenas for deeply nested parsing where multiple helper functions need to allocate without returning ownership.

Be careful with alignment. On Cortex-M0/M33, unaligned access to certain peripherals or to 32-bit fields will fault. My arena_alloc always aligns to the requested boundary, and I default to 4 or 8 bytes for any structured data. For string data, 1-byte alignment is sufficient but I still pad to avoid subtle portability bugs if the code moves to a stricter core.

Arenas are not a replacement for pools. If you reset an arena while someone still holds a pointer into it, you have a use-after-free bug. I enforce a simple rule: arena pointers never escape the function or task iteration that created them. If data must outlive the message, copy it into a pool block or a static buffer.

Fragmentation, Alignment and Guarding Against Silent Corruption

Even with static allocation, pools, and arenas, memory bugs still happen, but their failure mode changes from non-deterministic heap failure to detectable violations. My goal is to make incorrect usage fail loudly during development.

First, I guard every pool and arena with canaries and bounds checks in debug builds. For pools, I fill freed blocks with a pattern like 0xDEADBEEF and check that pattern on allocation. For arenas, I place a 4-byte canary at the end of the buffer and verify it on reset. Any overflow overwrites the canary and triggers an assert.

Second, I track high-water marks and fragmentation metrics at runtime. A pool's free_count tells you instant pressure, while an arena's high_watermark tells you if you sized it correctly. I log these over UART or expose them via a shell command during long-duration tests. One project had an arena sized at 512 bytes that worked in unit tests but hit 780 bytes when the device received a real-world provisioning payload with longer certificate chains. The high-water mark caught it before release.

Third, I use the MPU where available. On Cortex-M4/M7, I configure the MPU to make the pool storage region read-write for privileged tasks only and to mark the arena buffer as non-executable. A stray pointer that corrupts a pool block will fault immediately with a MemManage exception rather than silently corrupting a neighboring variable. Pairing this with a fault handler that dumps registers to backup SRAM has reduced my debug time from days to hours. If you have not set up MPU and fault handling yet, RTOS Fundamentals: FreeRTOS vs Zephyr for Embedded Projects and the associated debugging workflows are worth reviewing, especially when you need to separate kernel and task memory domains.

Alignment deserves special attention. DMA, crypto accelerators, and even the FPU can require specific alignment. I standardize on 4-byte alignment for pools and 8-byte for arenas that might hold doubles or 64-bit timestamps. The linker script should also align section starts, not just the objects inside them.

Choosing Between Static, Pool and Arena Strategies Under RTOS Constraints

No single pattern fits every subsystem. In a typical firmware architecture with an RTOS, I partition memory by ownership and lifecycle rather than by module.

Static allocation owns hardware-tied resources: DMA buffers, peripheral descriptors, task stacks, and global state machines. These live for the lifetime of the device and should be visible in the map file. Pool allocation owns shared, countable resources that move between contexts: network packet buffers, sensor event objects, and command queue items. Arena allocation owns transient, per-operation data that is created and destroyed within a single task iteration or API call.

The choice also interacts with RTOS primitives. A pool that is accessed from multiple tasks needs protection, but adding a mutex changes its blocking behavior. In Zephyr, I prefer k_mem_slab which integrates with the kernel's timeout and polling. In FreeRTOS, I often wrap my pool with a statically allocated queue that holds pointers to free blocks, so allocation becomes a non-blocking queue receive. Arenas, on the other hand, are almost always task-private, which means they need no locking at all, a significant advantage for latency.

The table below summarizes how I decide. It reflects the trade-offs I have observed on devices ranging from 16 KB RAM nRF52 to 512 KB RAM STM32H7.

When I bootstrap a new project, I start with static allocation only, then introduce one pool for inter-task messages and one arena per task that parses external input. That minimal setup handles the majority of IoT workloads, from sensor sampling to MQTT communication, without ever touching the heap. For critical sections, I keep ISRs allocation-free: the ISR signals a task, and the task does the allocation. This keeps interrupt latency predictable and avoids the need for heap-safe ISR variants.

Finally, measure before you optimize. Enable linker map generation (-Wl,-Map=firmware.map), parse it for RAM usage, and add a post-build script that fails the build if .bss + .data exceeds 80% of RAM. That last 20% is your safety margin for stack growth and future features. Firmware that uses 95% of RAM at link time will overflow its stack at runtime, and no memory pattern will save it.

Frequently Asked Questions