Opens in a new tab
[gtranslate]

Memory Protection Unit (MPU): The Hidden Backbone of ASIL Compliance

How a small hardware block, and everything it depends on, decides whether an ECU passes ASIL-D. 

What Is an MPU and Why It Matters 

In a modern automotive ECU, OS tasks, AUTOSAR Basic Software (BSW) modules, application software, diagnostic stacks, and bootloader code all share the same physical address space. A single stray pointer write from a low-criticality task can, in principle, corrupt data belonging to a safety-critical function running on the same core. The Memory Protection Unit (MPU) exists to make that “in principle” impossible in practice. 

Unlike a full Memory Management Unit (MMU) with virtual addressing and page tables, an MPU works directly on physical addresses. It divides memory into a limited number of regions — typically 8 to 16 on automotive-grade microcontrollers such as Infineon AURIX, NXP S32K, or ARM Cortex-M/R cores — and enforces read, write, and execute permissions per region, per privilege level, and often per task or partition. When software attempts an access outside its permitted region, the MPU raises a hardware fault, which the operating system intercepts, logs, and handles safely — well before the fault can propagate into a hazardous system state. 

For ISO 26262 programs targeting ASIL-C or ASIL-D, the MPU is frequently the primary mechanism used to justify freedom from interference (FFI) between software elements of different safety integrity levels running on the same core. Without it, mixing ASIL-D and QM software on one microcontroller would require either full physical separation (extra silicon, extra cost) or an unmanageable safety argument. 

Six Dependencies Behind a Correct MPU Configuration 

Setting MPU registers is a five-minute exercise on a datasheet level. Making that configuration correct, maintainable, and safety-case-defensible over the life of a program is not — because the MPU does not operate in isolation. Its correctness depends on a chain of other artifacts staying in sync. 

1. Memory Map and Linker Configuration 

MPU regions are only as good as the memory map they’re built from. Every change to the linker script — a new section, a resized stack, a relocated calibration block — must be reflected in the MPU region table. A mismatch here is one of the most common root causes of “intermittent” hard faults found late in integration, precisely because the code compiles and links cleanly; the fault only appears once the specific memory layout at runtime diverges from what the MPU table assumes. 

2. RTOS / AUTOSAR OS Task and Partition Definitions 

On an AUTOSAR-compliant OS, MPU regions are bound to OS Applications and tasks (OsApplication, TrustedFunction, memory partitions). Every task addition, stack size change, or partition re-assignment in the ECU configuration tool has a direct, mandatory downstream effect on MPU region definitions. Configuration tools can generate the initial mapping, but they cannot verify semantic correctness — that responsibility sits with the integrator. 

3. RTE and Inter-Partition Communication 

The Runtime Environment (RTE) generates the glue code that lets Software Components (SWCs) in different partitions exchange data. Every RTE-generated buffer, queue, or shared data element that crosses a partition boundary needs an explicit, reviewed MPU exception — otherwise legitimate inter-partition communication will fault, or worse, an overly permissive region will silently defeat the isolation the safety case relies on. 

4. Context-Switch and Fault-Handling Code 

MPU regions must be reprogrammed (or region-set-switched) on every context switch between partitions of different criticality. This code sits in the most timing-sensitive part of the OS and has a direct dependency on interrupt latency budgets — a poorly optimized MPU switch routine can silently eat into the timing margin reserved for higher-priority safety tasks. 

5. Bootloader and Startup Sequence 

Before the OS scheduler starts, the bootloader owns memory protection. The initial MPU configuration during startup, and the handoff point where control passes to the OS’s own configuration, must be explicitly defined and tested — a gap here leaves a window where protection is either absent or based on stale settings. 

6. Compiler, Linker, and Debug Toolchain Versions 

MPU region alignment requirements (often power-of-two sized and aligned, depending on the core) are enforced at link time. Toolchain upgrades can silently change padding or alignment behaviour, which is why MPU configurations are typically re-validated on every toolchain version change as part of the qualification evidence, not just at initial release. 

AUTOSAR Scalability Classes: When Memory Protection Becomes Mandatory 

Whether the MPU is even relevant to an AUTOSAR OS build is decided long before anyone opens a configuration tool — it’s determined by the Scalability Class (SC) chosen for the project. 

Scalability Class Memory Protection Timing Protection Typical Use 
SC1 No No Single trusted application, no isolation needed 
SC2 No Yes Timing supervision only (e.g., watchdog-style deadline monitoring) 
SC3 Yes No Multiple OS Applications with memory isolation, no timing enforcement 
SC4 Yes Yes Full isolation — memory and timing protection, typical for mixed-ASIL ECUs 

For any ECU that mixes ASIL levels — for example, ASIL-D braking logic alongside QM infotainment gateway code — on one core, SC3 or SC4 is effectively mandatory, with SC4 being the norm when both spatial and temporal freedom from interference need to be argued in the safety case. 

Where This Gets Configured in Practice 

In tools such as Vector’s DaVinci Configurator Pro (working against the MICROSAR OS module), the MPU-relevant configuration is spread across several interlocking places, and the diagram below shows how a configuration entry becomes an enforced hardware region: 

  • OsScalabilityClass — the top-level switch. Selecting SC3/SC4 unlocks the memory-protection-related ECUC containers in the Os module; selecting SC1/SC2 hides them entirely, which is a common source of confusion when a project is later upgraded and the MPU containers “don’t appear.” 
  • OsApplication containers — each OS Application (OsApp) represents an isolated partition. Key parameters include OsAppTrusted (marks the application as privileged, able to call protected OS services and bypass some MPU restrictions, versus non-trusted) and OsAppTaskRef / OsAppIsrRef / OsAppCounterRef (bind tasks, ISRs, and counters to the application). This binding determines which MPU region set gets loaded on a context switch into that application. 
  • OsAppMemoryAreaRef — grants an application explicit access to memory areas outside its own default region, such as a shared communication buffer, which the configurator translates into additional MPU region entries. 
  • OsMemoryProtection / OsApplicationMemory containers — define the actual regions: start address, size, and access attributes (read/write/execute) per application. These must reference the same symbols exported by the linker map that the BSW/RTE memory mapping uses. The configurator does not independently verify linker-side addresses; a mismatch here compiles cleanly but faults at runtime. 
  • OsProtectionHook — the callback invoked when the MPU raises a violation. For SC3/SC4 projects, this hook is where the safety concept is enforced in code — deciding whether a violation triggers a task termination, an OS Application shutdown, or a full safe-state transition. The tool’s default hook typically returns generic action codes that must be explicitly mapped to your project’s fault-reaction strategy; leaving this at defaults is a frequent audit finding. 
  • RTE-to-OS Application mapping — the RTE mapping editor lets you assign each Software Component to an OS Application. This mapping must stay consistent with the task assignments above; if a SWC is remapped to a different OS Application without updating the corresponding RTE communication buffers’ MPU exceptions, inter-SWC signals silently start faulting or, worse, silently succeed through an overly broad region. 
  • Consistency checks — built-in consistency checkers flag some mismatches (unassigned tasks, missing memory area references), but typically do not validate against the actual linker output or verify that region sizes meet the core’s alignment constraints. That verification has to happen as a separate build-time or post-link check, scripted into CI alongside the .map file. 

Practical Implication for SC3/SC4 Projects 

Because SC selection cascades into every one of these containers, changing SC level mid-project — for example, moving from an SC1 prototype to SC4 production intent — is not a configuration toggle. It’s effectively a re-partitioning exercise: every task needs an OsApplication assignment, every cross-partition data exchange needs an explicit memory area grant, and the protection hook needs a real fault-reaction strategy instead of the tool’s default stub. Planning for the target SC level from the start of the OS configuration avoids a late, safety-case-relevant rework. 

Common Pitfalls That Undermine MPU Protection 

  • Region count exhaustion — adding “just one more” partition without checking that the core still has spare MPU regions available, forcing an unplanned redesign of the partitioning scheme. 
  • Overlapping regions with conflicting permissions — behavior here is core-specific and sometimes undocumented for edge cases, leading to hard-to-reproduce faults. 
  • Stack probing gaps — MPU protection catches out-of-bounds accesses, not silent stack growth that stays within an oversized region; a complementary stack-monitoring mechanism is usually still required. 
  • Configuration drift between the safety case and the actual build — the MPU table used in the FFI argumentation must be generated from, or automatically cross-checked against, the same configuration that ships in the production binary. 
  • Protection hook left as a default stub instead of a defined, reviewed fault-reaction strategy tied to the project’s safety concept. 

Best Practices for Managing MPU Dependencies 

  1. Single source of truth — generate the MPU region table from the same configuration database that drives the linker script and OS configuration, rather than maintaining them by hand in parallel. 
  1. Automated cross-checks in CI — fail the build if the memory map, OS partition definitions, and MPU table diverge. 
  1. Traceability to the safety case — every MPU region and its permissions should trace back to a specific FFI requirement, so a reviewer — internal or from an assessor — can follow the argument end to end. 
  1. Regression testing on every toolchain or OS update — treat MPU configuration as a qualified artifact, not a one-time setup step. 
  1. Independent verification — because MPU faults are a primary safety mechanism, their configuration benefits from review or testing independent of the team that implemented the partitioning. 

Conclusion 

The MPU is a small piece of silicon with an outsized role in automotive functional safety. Its effectiveness, however, is never a property of the MPU registers alone — it is a property of the entire chain: memory map, OS configuration, Scalability Class selection, RTE-generated code, bootloader handoff, and toolchain behaviour staying consistent over the life of the project. Treating MPU configuration as a standalone task rather than a cross-cutting dependency is one of the more common — and more expensive — mistakes in ASIL-C/D ECU programs. 

For more deatils contact:

Name: Mohankumar ChandraMohan

Email: Mohankumar.Chandramohan@requisimus.com