Cortex-M Cores and Selection Criteria

A Cortex-M part is an Arm processor core wrapped in a vendor’s memory, peripherals, and package. The core sets the ceiling on what the part can do: the math it runs in hardware, the security it enforces, the speed it reaches. Picking the part starts with picking the core from a ladder that runs from the tiny Cortex-M0 up to the Cortex-M85. The rest of the selection reads a short list of criteria against the job: the compute it needs, the floating-point and signal math, the security level, the flash and RAM, the boot and test time on the line. Everything downstream settles around that one choice: the vendor, the package, the peripheral list, and the price.

The core comes before the part

Two parts from two vendors can share one Arm core. The flash, the peripherals, and the price around it are the vendor’s own. The core is the part of that pair a design fixes first, since it decides the instruction set, the math units, and the security model the product is going to live with. Everything the vendor adds sits around that fixed center. Peripherals can be swapped in a later revision. External memory can grow. The core is set in the silicon at tape-out, so a job that outgrows its core needs a new part, often a new board. That permanence is the reason the core earns the first and closest read in the whole selection.

Arm licenses the Cortex-M cores to the silicon makers, who build them into their own families. The license gives a maker the same core a competitor uses, so a Cortex-M4 from one vendor runs the same instructions as a Cortex-M4 from another. The differentiation moves to what surrounds the core: the analog, the connectivity, the memory, the ecosystem. The core number is a portability promise as much as a capability one. Code written to the Arm architecture and the CMSIS layer carries from one vendor’s Cortex-M4 to another’s with the peripheral layer rewritten underneath. That portability is what makes a second source possible at all, since the application sits on a core specification many vendors hold a license to. The licensing model also explains why the Cortex-M numbers mean the same thing everywhere. An M4 is an M4 by Arm’s definition, with the same registers, the same exception model, the same NVIC interrupt controller, whoever fabricates it. Datasheets from rival vendors line up on the core section for exactly this reason. The exception model, the systick timer, and the debug architecture come from Arm as well, so the low-level startup code and the debugger setup travel across vendors with little change. The differences a buyer hunts for live in the tables past the core block: the analog resolution, the timer count, the communication peripherals, the package options, the supply position. Knowing the core is the same across vendors turns a forty-part shortlist into a manageable read, since the core section can be skimmed once and the comparison spent on the wrapper. This is the quiet payoff of an Arm-based market: the learning, the tools, and the code amortize across every vendor that licenses the core, so the cost of evaluating one more candidate stays low.

This is why the core is a capability decision. The brand on the package follows it. The question is which Arm core the job needs, settled before whose name goes on the part. Choosing the vendor first can land a product on a core too small for the math or too large for the power budget. The cleaner order reads the work the product does, maps it to a core class, then looks for the vendor whose family on that class fits the peripherals, the supply, and the price. The core scopes the field. The vendor read happens inside that scope. This order also keeps the second-source question answerable. Two vendors that both build the chosen core class give a design a fallback, so a shortage at one supplier moves the board to the other with a recompile. Locking the vendor before the core throws that option away, since a niche part on an unusual core may have no equivalent anywhere.

The cores sort into a ladder of rising capability. Comparing the Cortex-M0, M3, and M4 on performance and cost covers the three rungs a general design chooses between, where each step up adds compute and price together. The rungs above and below those three extend the same ladder in both directions.

The capability ladder

The ladder climbs by adding capability at each rung. The software of a lower rung runs on a higher one after a recompile. Reading the ladder top to bottom shows what each step buys.

The Cortex-M0 and the Cortex-M0+ hold the bottom. Arm documents the Cortex-M0+ as having the smallest footprint and lowest power of all the Cortex-M processors. These cores run integer code through a short pipeline at a small gate count, the rung a sensor or a simple control loop sits on. Single-cycle I/O and a tiny interrupt latency make the M0+ quick to react despite its low clock, the reason it suits a job that mostly waits and occasionally acts. The same low gate count keeps the leakage current down, the property a coin-cell or energy-harvested product reads first. Sleep current on these cores drops into the low microamps, the number that sets how long a battery lasts in a design that spends most of its life asleep. The Cortex-M3 takes the next step, with a richer instruction set, a hardware divide, and bit-field operations that make it the workhorse for general control firmware. The M3 holds more peripherals busy at once and runs a small operating system without strain, the rung a connected sensor hub or a handheld instrument settles on. The gap between the M0+ and the M3 is the first real fork a catalogue offers, since the two cover the bulk of plain control and sensing work between them. Picking between them turns on how much the firmware has to juggle, from a single control loop at the low end up to a stack of tasks and protocols higher up. Adding the M4 to that read brings the math units into the same decision. Clock speed reads differently across the ladder too, since a higher number on a deeper pipeline does not scale one-for-one into work done. Two cores at the same megahertz can finish a benchmark seconds apart once the pipeline depth, the cache, and the math units enter the count. The honest measure of a core is the work it finishes per second on the actual code, taken from a benchmark close to the product.

The Cortex-M4 takes the M3 and adds the DSP instruction set plus an optional single-precision floating-point unit. That rung is the step into signal processing and real-number math on a microcontroller. Motor control, an audio path, or a sensor-fusion filter sits here, where the hardware math units turn a slow software routine into a few cycles. The Cortex-M7 climbs higher again, with a six-stage superscalar pipeline, instruction and data caches, and tightly-coupled memory for the compute-heavy end of the line. The cache lets the M7 run from slow external memory at speed. Graphics stacks and heavy control laws reach this far. The tightly-coupled memory gives the M7 a deterministic path for the code that has to answer on a fixed deadline.

Security has its own rungs. The Cortex-M23 and the Cortex-M33 add TrustZone, the hardware partition between secure and non-secure code. The M33 also carries an M4-class DSP and floating-point unit, so a secure design keeps its signal math. The M23 holds the low-power corner of that pair, for a secure design on a tight current budget. TrustZone matters at the core level because the boundary it draws cannot be added later in software. The partition lives in the bus fabric and the memory protection, so a product that skips a security core and later faces a certification has no upgrade path short of a new part.

The Cortex-M55 and the Cortex-M85 sit at the top, with Helium, the Arm vector extension that runs machine-learning and heavy signal work on a microcontroller core. Few designs reach for these until a model or a filter outgrows what an M4 or an M7 can do in time. Helium processes many data elements per instruction, the throughput a neural-network layer or a dense filter bank asks for, inside a microcontroller’s power envelope. The ladder gives a team one architecture from the sensor at the bottom to the edge-AI part at the top, with the toolchain and the code carrying across the rungs. One product line can start on an M0+ and move a later, heavier model onto an M55, carrying the Arm tools, the debug flow, and the bulk of the codebase across.

The lowest rung that clears the job

The discipline runs against instinct. The job names the lowest rung that clears it, sized with margin for the firmware to grow. Reaching for the biggest core in the catalogue quietly costs the product in unit price, in board power, and sometimes in a package that no longer fits. A sensor that wakes, reads, and sleeps asks for an M0+. A current loop that runs every fifty microseconds asks for the M4 and its math. Compute headroom left unused is silicon and current paid for and never spent, so the read is the smallest core that does the work, then a step of margin on top. The exception is a platform meant to host several products over years, where a deliberate over-spec buys a single core a whole line can share. That call is a roadmap decision, made open-eyed, set apart from the single-product habit of reaching high out of caution. The margin matters because firmware grows. A product ships, then gains features over its life, so the core picked at the floor of today’s need runs out of room a year in. The balance is a core matched to the work, plus a sensible reserve on top.

The criteria that pick among them

The first criterion past raw speed is math in hardware. A floating-point unit does decimal math directly, a single instruction for an operation a software library runs in many. Without the unit, the same math runs as a software routine many instructions deep. Audio, motor control, and sensor fusion lean on the hardware unit. The cost of the unit is a little silicon and a little static power, paid whether the code uses it or sits idle. The gain is measured in cycles: a single-precision multiply that costs dozens of instructions in software resolves in one on the hardware path, the difference between a loop that closes on time and one that slips. Whether a design lands among the designs that need an FPU comes down to whether the software path holds the loop time. A control loop that has to close in microseconds, with trigonometry or a filter in the path, runs out of cycles in software long before the hardware unit does. Single precision covers the bulk of embedded math at full speed on the M4 and M7, with a double-precision option on the M7 and the high cores for the few designs whose accuracy demands it.

The same M4-class core carries a DSP instruction set alongside the floating-point unit. These instructions handle fixed-point and integer signal math: a multiply-accumulate in one cycle, saturating arithmetic, and SIMD operations that pack several small values into one register. Digital filters and FFTs run several times faster on them. The DSP and SIMD instructions on the Cortex-M4 handle the fixed-point side of the signal work a design throws at the core. Fixed-point math holds a wide dynamic range in integers, so a design that avoids floating-point can still run real signal processing on the DSP set alone. The CMSIS-DSP library ships ready-built filters, transforms, and matrix routines tuned to these instructions, so a team reaches the speed without hand-writing assembly. The choice between the DSP path and the floating-point path is itself a design call, and many M4-class designs carry both math units on one core. The split between them, and which job each one wins, turns on the kind of math the inner loop runs. The presence of these units also raises the static power a little, paid on every part whether the code touches the math or leaves it idle, one more reason the core read weighs the job’s real math against the cost of carrying the hardware for it.

Security has become a core-level criterion of its own. TrustZone splits the chip into a secure side and a normal side in hardware. Secret keys and certified code sit behind that boundary. The application runs on the normal side, with no path across to the secrets. A connected product facing a security certification reads Cortex-M33 TrustZone for security certification as the line that decides which cores qualify. A scheme like PSA Certified leans on this hardware boundary for its root of trust, so a product chasing that mark starts on a core that carries TrustZone. A core without the partition encrypts and authenticates in software, with the keys reachable by any code that runs on the part. Secure boot, a measured update chain, and an isolated key store all build on the hardware boundary the M23 and M33 draw. Regulation has started to name these properties, so a product shipping into some markets after a cutoff date carries the security core as a requirement of sale, settled at core-selection time and never bolted on late.

Memory and the production line

Memory sizing is its own criterion, locked early. The flash holds the program and any over-the-air update images. Sizing it starts from the code size, the constants, and the room a safe two-image update needs, with margin for the firmware to grow across the product’s life. The RAM has to hold the working set the program touches at once. Speccing flash size on a 32-bit MCU works through that count before the part is committed. A 32-bit core also spends flash faster than an 8-bit one, since its instructions are wider and its libraries heavier, so a port up from an 8-bit part starts the flash budget higher than the old code suggests. Picking one flash tier above the first estimate buys the room a field update and a few late features take. RAM carries its own trap on a 32-bit part, since a graphics frame buffer, a network stack’s buffers, or a sensor-fusion state can dwarf the program itself. A design that sizes flash alone and leaves the RAM unchecked stalls when the working set overflows the on-chip SRAM and forces a slow external memory onto the board.

Boot time turns into money on the production line. Every unit powers up, runs a self-test, and takes its firmware load during final test, so a core that boots in milliseconds clears the tester faster than a slow-starting one. MCU boot time and production test throughput follows that path from a datasheet figure to the seconds a factory spends on each board, where high volume turns a few seconds into real cost. A run of a million units feels every second of boot and flash-load time as line hours and tester capacity. The startup clock source, the flash-load method, and the self-test depth all feed that number, so a part read only on its run-time speed can still cost a fortune in test time. An internal oscillator that is ready in microseconds saves the wait an external crystal takes to stabilize at every power-up. The programming interface sets the rest: a fast SWD or a parallel load moves the firmware image onto the part in seconds, multiplied across every unit on the line.

Reading the core against the job

Four jobs show the ladder in use. A battery sensor that samples and sleeps takes an M0+ for its power floor. A motor controller running a current loop takes an M4 for the DSP and the FPU. A door lock holding a credential takes an M33 for TrustZone. A graphics panel pushing pixels takes an M7 for the cache and the clock. The job picks the rung; the brand on the package comes after. The four sit on four different cores. All four draw on the same Arm toolchain and debug flow, so a team that builds one can build the next without relearning the platform. The pattern repeats across a catalogue: the work defines the rung, the rung defines the core class, the core class defines the short list of parts that earn a datasheet read.

The order holds across products. Name the compute and the math first, since they pick the core class. Add the security level next. It narrows the field to the TrustZone cores when a certification calls for one. Size the memory against the code and the update image, with the working set checked against the on-chip RAM. Read the boot and test time last, where production volume makes it count. The same order works for a port from an existing design, with one extra step at the front: measure what the current firmware uses on its present core, then map that onto the new ladder before committing. A measured baseline beats a guess every time the flash or the loop time turns out tighter than memory suggested. Each step trims the list of candidate cores, so by the time the vendor read begins the field is two or three parts down from forty. The criteria run in that order because the early ones are the hardest to change later: a core swap is a respin, a flash bump is a part number, a tester tweak is a script.

The core is the decision the rest of the part hangs on. Get it right and the vendor choice, the package, and the peripheral list fall into place around a known capability. A core too small for the math, or one without the boundary the product needs, is the one mistake no peripheral list rescues. Reading the core first also future-proofs the line, since the Arm ladder gives a clear next step when a product gains weight: a recompile onto a higher rung carries the work forward. Each axis of that decision, from the compute to the boot time, rewards a deliberate read of its own.