MPU on Cortex-M

The MPU is the Cortex-M's lightweight memory protection mechanism — a small table of regions, each with an address range, size, and a set of access permissions. It is not a full MMU: there is no virtual-to-physical translation, no page tables, no TLB. Every region maps a contiguous slice of the 4 GB physical address space, and the MPU's only job is to check whether the current access is allowed and to raise a fault if it isn't.

This is plenty for what Cortex-M parts need: stack-overflow detection, RTOS task isolation, write-protecting flash from runaway pointer bugs, marking RAM as execute-never to defeat shellcode, and partitioning a single chip between privileged kernel and unprivileged application code. The MPU is also a hard requirement for security-certified profiles (IEC 61508, ISO 26262, Common Criteria) — without it, you can't make a credible argument that your bootloader and your application don't interfere.

What the MPU does — and doesn't

The MPU compares every load and store address (and instruction fetch) against its region table. If the access falls inside a region, the region's permissions decide whether it's allowed. If the access falls outside every region, the architectural default applies — and, importantly, on Cortex-M the default is "allowed only if executing privileged; deny if unprivileged."

The MPU does not translate addresses. A physical address stays a physical address. There is no per-process address space; every "process" (RTOS task) sees the same flat 32-bit memory map. What the MPU does provide is per-context permission masks: by reprogramming the region table at every context switch, an RTOS can give each task its own view of which memory it's allowed to touch.

The MPU is not the same as TrustZone. TrustZone-M partitions memory between secure and non-secure worlds via the SAU/IDAU. The MPU partitions memory between privileged and unprivileged execution within a single world. Both can be present on an ARMv8-M part; they enforce orthogonal policies.

Region descriptors — ARMv7-M

On ARMv7-M, each region is described by a triple of registers:

Setting up a region on v7-M typically uses ARM_MPU_SetRegion:

// 32 KB of RAM at 0x20000000, full access, no execute, normal memory
ARM_MPU_SetRegion(
    ARM_MPU_RBAR(0, 0x20000000),                       // region 0, base
    ARM_MPU_RASR(1, ARM_MPU_AP_FULL, 0, 0, 1, 0, 0,    // XN=1, AP=full, normal mem
                 ARM_MPU_REGION_SIZE_32KB));

Region descriptors — ARMv8-M

ARMv8-M reworked the region descriptors to be simpler and less restrictive:

The v8-M MPU replaces v7-M's per-region cacheability bits with a Memory Attribute Indirection Register (MAIR0/MAIR1). You define up to 8 memory-attribute types in MAIR, then each region picks one by index. This separation makes it cheaper to change attributes for several regions consistently.

Crucially, v8-M drops the power-of-two-and-aligned constraint. A region can start at any 32-byte boundary and extend to any 32-byte limit. This is the single biggest win for software: you can carve a 13 KB region (not a power of two) without burning an extra region descriptor for the awkward bit.

Memory attributes — cacheability and shareability

The MPU also tells the cache hierarchy how to treat each region. The most common combinations on a Cortex-M7 system:

The most common bug here is forgetting to mark DMA buffers as non-cacheable on Cortex-M7. The CPU writes data through the cache, but DMA writes go straight to SRAM — the cache holds stale copies. Either invalidate the cache after DMA completes, or mark the buffer region as non-cacheable from the start.

The two privilege levels

Cortex-M has exactly two privilege levels: privileged (handler mode + thread mode with CONTROL.nPRIV = 0) and unprivileged (thread mode with CONTROL.nPRIV = 1). Boot starts privileged. To drop privilege:

__set_CONTROL(__get_CONTROL() | CONTROL_nPRIV_Msk);
__ISB();  // ensure the change takes effect before the next instruction

Once unprivileged, the thread cannot:

• Access privileged-only MPU regions (per AP bits)
• Write to system registers like SCB->VTOR, NVIC_ISER, MPU registers
• Execute CPS instructions to change PRIMASK/FAULTMASK
• Access the SCB / NVIC / SysTick directly

The thread can come back to privileged only via an exception (SVCall or any IRQ — handler mode is always privileged). RTOSes use this to enforce that task code cannot diddle kernel data: tasks run unprivileged, syscalls escalate via SVC, IRQs are kernel-trusted.

Stack overflow detection

The headline MPU use-case in an RTOS is stack overflow detection. Each task's stack ends at a known address; place an MPU region just below the stack with "no access" attributes. If a function's stack frame grows beyond the boundary, the next push faults — MemManage — and the RTOS can pin the task or reset the system.

For a 4 KB stack starting at 0x20010000 and growing down:

// Region: 32 bytes at 0x2000FFE0 (just below the stack), no access
ARM_MPU_SetRegion(
    ARM_MPU_RBAR(0, 0x2000FFE0),
    ARM_MPU_RASR(1, ARM_MPU_AP_NONE, 0, 0, 0, 0, 0,
                 ARM_MPU_REGION_SIZE_32B));

When a task SP drops below 0x20010000, the next push hits the guard region and faults synchronously. The fault address is in MMFAR — log it, then vTaskDelete the offender. Without this, stack overflow corrupts the next region of RAM silently and you get bizarre, late-binding crashes that are nearly impossible to debug.

RTOS task isolation

Beyond stack overflow, the MPU lets you compartmentalize tasks. The typical pattern:

1. At boot, set up static regions: flash as RO-execute, peripheral region as RW-no-execute, kernel data as priv-only RW.
2. On context switch, swap in per-task regions that grant unprivileged R/W to the task's stack and any task-private data, plus shared regions for IPC.
3. The kernel itself runs privileged and is not constrained by the task regions.

FreeRTOS MPU support is gated on the MPU port. Tasks declared with xTaskCreateRestricted get a per-task region list; switching to that task reprograms the MPU. Zephyr's USERSPACE feature is the same idea, more fully baked. ThreadX has "modules" with MPU-enforced boundaries.

The cost is a handful of MMIO writes per context switch — a few microseconds on a 100 MHz part. The benefit is that one buggy task cannot scribble over another task's stack, the kernel, or peripheral registers.

Common bugs

XN forgotten on RAM. Without XN=1, RAM is executable. A buffer overflow that overwrites a function pointer can then jump into attacker-controlled bytes. Set XN on every RAM region; only flash should be executable.

Default-deny background. If MPU_CTRL.PRIVDEFENA = 1, privileged code uses the architectural default memory map for any address not covered by a region. If = 0, even privileged code faults on uncovered regions. Pick deliberately; 1 is more permissive and easier to start with.

Region order matters. Higher-numbered regions take priority. A "deny" region at index 1 overridden by an "allow" region at index 4 means the address is allowed. Counter-intuitive; sort guard regions to the high end of the table.

Forgot the DSB+ISB. After programming the MPU and before relying on the new permissions, you need a memory barrier:

MPU->CTRL = MPU_CTRL_ENABLE_Msk | MPU_CTRL_PRIVDEFENA_Msk;
__DSB();
__ISB();

Without these, the pipeline may have prefetched an instruction from a region whose permissions are about to change, and you'll get spurious faults.

Cross-references

• Exception model — MemManage fault details and stacking on fault
• TrustZone-M deep dive — orthogonal security partition (secure/non-secure)
• SCB — System Control Block — SHCSR.MEMFAULTENA enables MemManage as a distinct fault (instead of escalating to HardFault)
• Startup & vector table — when to set up the MPU during boot
• ARMv7-M ARM section B3.5 (MPU); ARMv8-M ARM section D1 (MPU)