ARM Cortex Processor Family: Complete Reference

ARM Cortex Overview

ARM Cortex processors dominate embedded and mobile computing, with over 100 billion ARM-based chips shipped since the company’s founding in 1991 according to ARM Holdings. The Cortex family is divided into three distinct series, each optimized for different application requirements. The Cortex-M series targets microcontroller applications where deterministic interrupt response, low power consumption, and small code footprint are paramount. The Cortex-R series is designed for high-performance real-time systems requiring fault tolerance and deterministic behavior, such as automotive ADAS controllers and baseband processors. The Cortex-A series powers application processors running full operating systems — virtually every smartphone sold in the last decade uses a Cortex-A core. Understanding the differences between these series and the specific cores within each is essential for selecting the right processor for any embedded project.

Cortex-M Series

The Cortex-M series is the most widely used family of microcontroller cores in the industry. The Cortex-M0 is a 2-stage pipeline design focused on ultra-low power and minimal gate count, consuming as little as 12 μW/MHz on TSMC 40 nm process according to ARM white papers. It supports only the Thumb instruction subset but achieves remarkable efficiency for simple control applications. The Cortex-M3 features a 3-stage pipeline with hardware division, bit-banding for atomic bit operations, and single-cycle multiply for balanced performance across a wide range of applications. The Cortex-M4 adds a single-precision floating-point unit (FPU) and DSP instructions (SIMD, saturating arithmetic) for digital signal processing applications. The Cortex-M7 is a 6-stage dual-issue superscalar design with a branch predictor and optional L1 cache, achieving over 1000 CoreMark at 400 MHz — rivaling entry-level application processors in raw compute. The Cortex-M33 adds ARM TrustZone security extensions for creating trusted execution environments on low-cost microcontrollers. Each core shares the same programmer’s model with the NVIC interrupt controller and SysTick timer, enabling software portability across the series.

Cortex-R Series

The Cortex-R series fills the gap between Cortex-M and Cortex-A, targeting real-time applications that require high performance and fault tolerance. These cores feature hardware ECC (Error Correction Code) on memory interfaces, dual-core lockstep configurations where two cores execute the same instructions and compare results for fault detection, and deterministic interrupt response with very low latency. The Cortex-R52, widely used in automotive systems, supports hardware virtualization and complies with ISO 26262 ASIL D for the highest level of automotive safety. Typical applications include advanced driver-assistance systems (ADAS) that process camera and radar data, baseband processors in cellular base stations, and solid-state drive (SSD) controllers that manage NAND Flash memory.

Cortex-A Series

The Cortex-A series powers application processors in the most demanding embedded environments. The Cortex-A53 is a 64-bit in-order core that balances efficiency and performance, used in the Raspberry Pi 3 and countless set-top boxes. The Cortex-A72 is a high-performance out-of-order core found in the Raspberry Pi 4 and many mid-range smartphones. The Cortex-A78 achieves high instructions-per-clock on advanced 5 nm process nodes for flagship mobile devices. The architecture defines four exception levels: EL0 for user applications, EL1 for operating system kernels, EL2 for hypervisors supporting virtualization, and EL3 for secure monitor firmware implementing TrustZone. The Generic Interrupt Controller (GIC) manages interrupt routing across multiple cores and supports up to 16,384 interrupts in GICv3 and GICv4 implementations.

Cortex-M Programming Model

Vector Table and Exception Handling

The vector table is the first data structure in the Cortex-M memory map, starting at address 0x00000000 after reset. It contains the initial stack pointer value for the main stack (MSP) at offset 0x00 and entry points for all exception and interrupt handlers. The first 16 entries are system exceptions (Reset, NMI, HardFault, MemManage, BusFault, UsageFault, and others), followed by up to 240 device-specific interrupt handlers.

__attribute__((section(".isr_vector")))
void (*const g_pfnVectors[])(void) = {
    &_estack, Reset_Handler, NMI_Handler, HardFault_Handler,
---;

The Nested Vectored Interrupt Controller (NVIC) manages interrupt prioritization and nesting. It supports up to 240 interrupt sources with 8 to 256 priority levels depending on the core implementation (Cortex-M0/M0+ have fixed 4 levels, M3/M4 have 16–256 levels). The NVIC provides deterministic interrupt latency — 12 CPU cycles from assertion to the first instruction of the handler on Cortex-M3 and 6 cycles on Cortex-M4 when coming from sleep mode, as specified in the ARM Architecture Reference Manual for Cortex-M3 (DDI 0403). Tail-chaining allows back-to-back interrupts to be serviced without saving and restoring context between them, reducing the overhead of sequential interrupt handling.

Thumb-2 Instruction Set

Cortex-M processors implement the Thumb-2 instruction set architecture, which combines 16-bit Thumb instructions with 32-bit Thumb instructions in a single variable-length ISA. This design achieves 26% better code density compared to the original ARM instruction set while delivering 25% better performance compared to pure 16-bit Thumb, according to ARM benchmarks. The instruction set includes hardware multiply and divide, saturating arithmetic for signal processing, bit-field manipulation, and exclusive-access instructions (LDREX/STREX) for lock-free synchronization between interrupts and main code.

Debug Features

Cortex-M processors include comprehensive debug and trace hardware that enables non-intrusive real-time debugging. The Data Watchpoint and Trace (DWT) module provides up to four watchpoints for address or data matching, a PC sampling counter for statistical profiling, event counters for cache misses and instruction cycles, and a 32-bit cycle counter accessible via DWT->CYCCNT. The Instrumentation Trace Macrocell (ITM) enables application-driven trace output over the Single Wire Output (SWO) pin, providing printf-style debugging with only one additional pin and zero cycles of overhead when not in use. The Embedded Trace Macrocell (ETM) captures a complete instruction trace for reconstructing program execution — essential for debugging difficult timing-dependent bugs. The Flash Patch and Breakpoint (FPB) unit provides up to 8 hardware breakpoints and 2 literal comparators that can patch Flash memory accesses to RAM, enabling hot-patching of firmware without reprogramming.

System Timer

SysTick is a 24-bit down-counter present on every Cortex-M processor. It generates a periodic interrupt used universally as the system tick for RTOS scheduling and software timing. The counter decrements from a reload value at the processor clock frequency, generating an interrupt when it reaches zero. For a 1 ms tick on a 100 MHz processor, the reload value is 99,999. FreeRTOS, Zephyr, Keil RTX, and other RTOS implementations all use SysTick as their primary time source, and the CMSIS-Core API provides standardized access functions.

CMSIS Ecosystem

The Cortex Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer defined by ARM to simplify software reuse across Cortex-M devices from different manufacturers. CMSIS-Core defines standardized register access structures, interrupt control functions, and system initialization routines that work uniformly across STM32, NXP LPC, Microchip SAM, and all other Cortex-M devices. CMSIS-DSP provides optimized signal processing functions including FIR and IIR filters, FFT transforms, matrix operations, and statistical functions that leverage the Cortex-M4 and M7 SIMD instructions. CMSIS-RTOS defines a standard RTOS API that allows application code to run on FreeRTOS, RTX5, or any CMSIS-RTOS compliant kernel without modification.

Exception Model Details

Cortex-M processors implement a unified exception model that handles both system exceptions and peripheral interrupts through the NVIC. The exception types include Reset (highest priority, cannot be masked), NMI (Non-Maskable Interrupt for critical events like watchdog expiration), HardFault (catch-all for unrecoverable errors), MemManage (MPU violation), BusFault (memory access error on the system bus), UsageFault (undefined instruction, invalid state, division by zero), and Debug Monitor (for debugger access). The configurable fault handlers allow developers to implement custom error recovery strategies. When multiple faults cascade, the processor determines the highest priority fault and invokes the corresponding handler.

Memory Protection Unit

The Memory Protection Unit (MPU) available on Cortex-M3, M4, M7, and M33 processors provides hardware-enforced access control for memory regions. The MPU can define up to 8 or 16 regions with configurable size, base address, access permissions (read/write/execute), and sub-region granularity. When enabled, the MPU generates a MemManage fault on any access that violates the configured permissions. This is essential for safety-critical systems to prevent errant tasks from corrupting kernel data or other tasks’ memory. RTOS implementations like FreeRTOS with MPU support use the MPU to create isolated task contexts, catching stack overflow and wild pointer dereferences before they cause system crashes.

Power Management Features

Cortex-M processors support multiple power modes through the System Control Block (SCB). The SLEEPDEEP bit selects between normal sleep (CPU clock gated, peripherals active) and deep sleep (core voltage reduced, most peripherals stopped). The WFI (Wait For Interrupt) instruction enters sleep immediately, while WFE (Wait For Event) enters sleep conditionally based on an event register. The Sleep-on-Exit feature automatically puts the processor to sleep after servicing an interrupt, eliminating the overhead of returning to the interrupted thread only to immediately sleep again. These features are critical for battery-powered applications where every microamp of current consumption matters.

CoreSight Debug and Trace Architecture

ARM CoreSight provides a standardized debug and trace infrastructure across all Cortex processors. The trace sources (ITM, DWT, ETM) connect to a trace funnel that combines multiple streams into a single output via the Trace Port Interface Unit (TPIU) or the Serial Wire Output (SWO). The Embedded Cross Trigger (ECT) allows one debug component to trigger another — for example, a watchpoint match can trigger a trace capture. This architecture enables sophisticated debugging scenarios like tracing only the code path leading up to a specific data access, without modifying the application code or requiring instrumented builds.

Frequently Asked Questions

What is the difference between Cortex-M and Cortex-A? Cortex-M is designed for real-time microcontroller applications with deterministic interrupt response, no memory management unit (MMU), and power consumption in the microwatt range. Cortex-A targets application processors running complex OSes with virtual memory, multi-level cache hierarchies, and GHz-class performance.

Why is Thumb-2 important for embedded systems? Thumb-2 combines the code density advantages of 16-bit Thumb instructions with the performance of 32-bit ARM instructions, reducing Flash memory requirements by approximately 25% compared to pure ARM code while maintaining performance.

How do I choose between Cortex-M3 and Cortex-M4? Choose the Cortex-M4 if your application requires digital signal processing, floating-point arithmetic, or FFT operations. The Cortex-M3 is more cost-effective for general-purpose control applications without math-intensive computation.

What is TrustZone and when should I use it? TrustZone creates a hardware-enforced secure execution environment for cryptography, secure boot, digital rights management, and other security-sensitive operations. Use it when the application requires isolation between security-critical and non-critical code.

Can I run Linux on a Cortex-M processor? No. Cortex-M processors lack a memory management unit (MMU), which is required for standard Linux. Only Cortex-A series processors can run Linux. For Cortex-M, use an RTOS or bare-metal firmware.

Related: Embedded C Programming | RTOS Concepts