ARM Cortex Architecture for Embedded: M vs A vs R, NVIC, MPU Interview Prep
ARM Cortex architecture for embedded interviews — Cortex-M vs A vs R profiles, the Cortex-M exception model and NVIC, MPU vs MMU, Thumb-2, privilege modes (MSP/PSP), and TrustZone.
Quick answer
ARM Cortex is the family of processor cores that dominates embedded systems, and for an embedded engineer the architecture that matters is how those cores handle interrupts, memory protection, privilege, and determinism — not a general survey of CPU design.
Embedded interviewers use Cortex architecture to check that a candidate understands the machine their firmware actually runs on.
Editorial review
Written by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Reviewed by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Last reviewed
Built from curated topic maps, editorial validation, and subject-matter review so the page stays aligned with the interview intent and the current content pipeline.
Key points
- Three ARM profiles: Cortex-M (microcontroller — deterministic control, no MMU, RTOS/bare-metal), Cortex-A (application — MMU, runs Linux/Android), Cortex-R (hard-real-time/safety, often lockstep). Match profile to requirement.
- Cortex-M has an MPU (access permissions on a few regions), not an MMU (address translation) — protection without the cost/non-determinism of virtual memory.
- The NVIC gives Cortex-M low, deterministic interrupt latency: hardware auto-stacks registers, fetches the handler from the vector table (so an ISR can be plain C), supports nested priorities, tail-chaining, and late-arrival.
- Cortex-M is Thumb/Thumb-2 only (code-density-optimized, 32-bit); Cortex-A spans AArch32 and AArch64 (64-bit, performance/OS-oriented).
- Cortex-M modes: Thread vs Handler, privileged vs unprivileged, with MSP/PSP stacks an RTOS uses to isolate kernel from tasks — simpler than Cortex-A exception levels (EL0-EL3).
- TrustZone partitions Secure/Non-secure worlds; on Cortex-M it arrives with ARMv8-M (e.g. Cortex-M33), isolating secure assets without a separate chip.
- The interview differentiator is reasoning about determinism, interrupts, and memory protection — not memorizing core part numbers.
What it is
ARM Cortex is the family of processor cores that dominates embedded systems, and for an embedded engineer the architecture that matters is how those cores handle interrupts, memory protection, privilege, and determinism — not a general survey of CPU design. ARM splits Cortex into three profiles. Cortex-M is the microcontroller profile: small, low-power, deterministic cores with a tightly integrated interrupt controller and no MMU, designed to run bare-metal or under an RTOS (see /topics/rtos). Cortex-A is the application profile: higher-performance cores with an MMU, caches, and the features required to run a rich operating system like Linux (see /topics/embedded-linux-and-device-drivers). Cortex-R is the real-time profile for hard, bounded-latency, safety-critical control, frequently in dual-core lockstep. For the deeply embedded work most firmware engineers do, Cortex-M is the center of gravity. Its defining features are the Nested Vectored Interrupt Controller, which auto-stacks registers and vectors directly to handlers for low, predictable latency; the Thumb-2 instruction set, chosen for code density on small program memories; an optional MPU that enforces access permissions without address translation; and a simple privilege model (Thread/Handler modes, privileged/unprivileged, MSP/PSP stacks) that an RTOS uses to protect itself from tasks. Newer ARMv8-M cores add TrustZone for on-chip secure/non-secure isolation. Understanding these — and how they contrast with the MMU, AArch64, and exception-level model of Cortex-A — is what connects the processor to the firmware and the rest of the system (see /topics/computer-architecture, /topics/embedded-engineer-interview-signals).
Why interviewers ask
Embedded interviewers use Cortex architecture to check that a candidate understands the machine their firmware actually runs on. A firmware engineer who cannot explain what happens on an interrupt, why Cortex-M latency is deterministic, or the difference between an MPU and an MMU will struggle with the bring-up, real-time, and debugging problems the job is made of. The questions are concrete and hard to fake: walk the exception flow, explain NVIC priorities and preemption, say why an ISR can be written in C, distinguish protection from translation, and pick the right profile for a stated requirement. The topic is also a systems-reasoning probe (see /topics/embedded-engineer-interview-signals). Strong candidates connect the core to the software: how an RTOS uses MSP/PSP and the MPU to isolate tasks, why a Cortex-A with an MMU is what runs Linux, when a Cortex-R lockstep core is required for safety. They reason about determinism and interrupt latency rather than reciting part numbers, and they know where features live — that AArch64 is a Cortex-A thing, that TrustZone on microcontrollers means ARMv8-M. Interviewers want that fluency because it is exactly what separates an engineer who can debug a missed deadline or a faulting access from one who only knows the vendor SDK calls.
Common mistakes
The most common mistake is conflating the MPU and the MMU — assuming Cortex-M has virtual memory, or not knowing that the MPU enforces permissions without translating addresses. A second is misunderstanding the interrupt model: not knowing the hardware auto-stacks registers (so an ISR is plain C), or being unaware of NVIC priorities, preemption, tail-chaining, and late-arrival, which are exactly what make latency deterministic. A third is getting the instruction sets wrong — expecting AArch64 or legacy 32-bit ARM on a Cortex-M, when Cortex-M is Thumb-only, or not realizing Cortex-A spans AArch32 and AArch64. A fourth is ignoring the privilege model: not knowing Thread vs Handler mode, privileged vs unprivileged, or the MSP/PSP split that an RTOS relies on, and conflating it with Cortex-A exception levels. A fifth is treating the three profiles as interchangeable — proposing a Cortex-M for a Linux workload that needs an MMU, or a plain Cortex-A where hard-real-time safety calls for a Cortex-R in lockstep. Finally, candidates often memorize core names and clock speeds while being unable to reason about the properties that actually drive a design decision: determinism, interrupt latency, memory protection, and power.
Frequently asked questions
- What is the difference between Cortex-M, Cortex-A, and Cortex-R?
- They are three ARM architecture profiles for different jobs. Cortex-M (microcontroller profile) targets deeply embedded, deterministic control: small, low-power cores with an integrated interrupt controller, no MMU (an optional MPU instead), and predictable interrupt latency — the cores you run bare-metal or with an RTOS (see /topics/rtos). Cortex-A (application profile) targets rich operating systems: an MMU for virtual memory, caches, higher performance, and the features needed to run Linux or Android (see /topics/embedded-linux-and-device-drivers). Cortex-R (real-time profile) targets hard-real-time, safety-critical control (storage controllers, automotive, modems) with low, bounded latency and often dual-core lockstep for fault detection. The interview judgment is matching the profile to the requirement: deterministic control on kilobytes of RAM is Cortex-M, a rich OS is Cortex-A, hard-real-time with safety is Cortex-R.
- Why does Cortex-M have an MPU but not an MMU?
- An MMU (memory management unit) provides virtual-to-physical address translation and per-process address spaces, which a rich OS like Linux needs — but it adds area, power, and non-deterministic translation-lookaside-buffer behavior that conflict with the microcontroller goals of small size and predictable timing. Cortex-M instead offers an optional MPU (memory protection unit), which does not translate addresses but enforces access permissions and attributes on a handful of regions. That gives you protection (catching a stray write, isolating a task or a stack) and the memory-attribute control an RTOS or a safety standard wants, without the cost and unpredictability of full virtual memory. Knowing that protection (MPU) and translation (MMU) are different, and which profile has which, is a common Cortex interview discriminator.
- How does the Cortex-M exception and interrupt model work?
- Cortex-M integrates the Nested Vectored Interrupt Controller (NVIC) tightly with the core for low, deterministic interrupt latency. On an interrupt the hardware automatically stacks a set of registers (xPSR, return address, LR, R12, and R0–R3), fetches the handler address from the vector table, and enters Handler mode — so a C function can serve as an ISR with no assembly prologue. The NVIC supports many prioritized, nestable interrupts: a higher-priority interrupt can preempt a lower one. Two optimizations matter in interviews: tail-chaining, where the core skips an unstack/restack between back-to-back interrupts, and late-arrival, where a higher-priority interrupt that appears during stacking is serviced first. The result is predictable, short latency — the property that makes Cortex-M suitable for real-time control.
- What instruction set does Cortex-M use, and how does it differ from Cortex-A?
- Cortex-M executes the Thumb / Thumb-2 instruction set — a compact mostly-16-bit encoding (with 32-bit instructions where needed) chosen for high code density, which matters when program memory is small. Cortex-M cores do not run the legacy 32-bit ARM (A32) instruction set; they are Thumb-only. Cortex-A cores support the full picture: AArch32 (A32/Thumb) and, on modern cores, AArch64 — the 64-bit instruction set with more registers and a larger address space for application workloads. So a key practical difference is that Cortex-M is a 32-bit, Thumb-only, code-density-optimized core, while Cortex-A spans 32- and 64-bit and is performance- and OS-oriented. Mixing these up (for example expecting AArch64 on a microcontroller) signals unfamiliarity with the actual targets.
- What are the privilege and operating modes in Cortex-M?
- Cortex-M has two modes — Thread mode (normal code) and Handler mode (exception/interrupt handlers) — and two privilege levels, privileged and unprivileged. Handler mode always runs privileged; Thread mode can run privileged or unprivileged. There are also two stack pointers, Main (MSP) and Process (PSP), which an RTOS uses to separate kernel and task stacks. This two-level scheme is deliberately simpler than Cortex-A, which has a full hierarchy of exception levels (EL0 for applications, EL1 for the OS kernel, EL2 for a hypervisor, EL3 for secure firmware). Understanding that Cortex-M's privileged/unprivileged plus MSP/PSP split is how an RTOS protects itself from tasks — and how it contrasts with Cortex-A exception levels — is a frequent interview thread.
- What is TrustZone and how does it appear on Cortex-M versus Cortex-A?
- TrustZone is ARM's hardware security partitioning, splitting execution into a Secure and a Non-secure world so sensitive code and data (keys, secure boot, crypto) are isolated from the main application. On Cortex-A it has long provided a secure monitor and a trusted execution environment alongside the rich OS. On Cortex-M it appears in the ARMv8-M architecture (for example Cortex-M33, M23): the core adds secure and non-secure states with hardware-checked transitions, so a microcontroller can isolate a security subsystem without a separate chip. For embedded interviews the signal is knowing that TrustZone exists on both profiles, that the Cortex-M flavor arrived with ARMv8-M, and what problem it solves — isolation of secure assets — rather than the register-level mechanics.
- How should an embedded engineer prepare Cortex topics for interviews?
- Anchor on the microcontroller reality you will actually face. Be able to walk the boot and exception flow: reset vector, vector table, what the hardware stacks on an interrupt, and why an ISR can be plain C. Explain NVIC priorities, preemption, and why latency is deterministic. Distinguish MPU from MMU and say when each matters. Know the M/A/R profiles and pick the right one for a given requirement, and connect the core to the software that runs on it — an RTOS using MSP/PSP and the MPU (see /topics/rtos), or Linux on a Cortex-A with an MMU (see /topics/embedded-linux-and-device-drivers). Tie it back to the broader role and the rest of the system (see /topics/embedded-engineer-interview-signals, /topics/computer-architecture). The differentiator is reasoning about determinism, interrupts, and memory protection, not reciting core part numbers.
Related topics
Essential AI-Native Skills for ARM Cortex Architecture for Embedded: M vs A vs R, NVIC, MPU
Modern engineering work increasingly uses AI tools for design and code review, debugging, documentation, test and testbench generation, and workflow automation. The goal is not to let AI replace engineering judgment — it is to move faster while keeping verification discipline.
- Use AI to explain unfamiliar code, logs, waveforms, datasheets, or test failures.
- Break large problems into small, reviewable steps you can verify independently.
- Ask AI for hypotheses, then validate them against tests, measurements, simulations, or lab data.
- Version-control your analysis scripts, testbenches, and configs — keep changes small and reviewable.
- Document your assumptions, design tradeoffs, and debugging decisions.
- Verify AI output before trusting it: run the checks that fit the domain — unit tests, linters, simulations, or bench/lab measurements.
- Review AI output for correctness, edge cases, and real-world consequences.
ARM Cortex Architecture for Embedded: M vs A vs R, NVIC, MPU — coming to the question bank
The adaptive practice engine is already live for core wireless, RF, and ML systems. ARM Cortex Architecture for Embedded: M vs A vs R, NVIC, MPU isn't covered in the question bank yet — get notified when it's added.