By Uwe Knipping
Field Applications Engineer, Future Electronics (Germany)
There are many factors underlying the rise of the ARM® Cortex®-M series of processor cores to domination of the 32-bit microcontroller market.
Across the many varieties of ARM Cortex-M cores, design engineers can choose from such an array of features, performance, power consumption and communications capabilities that they can find an MCU with an ARM core suitable for almost any application requirement. And by standardising on the ARM Cortex-M family of cores, OEMs benefit from a common instruction set and a complete ecosystem of libraries, tools and firmware with which thousands of embedded engineers are already familiar, as shown in Figure 1.
One other commonly cited reason for using MCUs based on an ARM Cortex-M core is the potential for code portability: the common Cortex-M instruction set and ARM’s Cortex Microcontroller Software Interface Standard (CMSIS) are important parts of ARM’s effort to persuade the embedded world that code developed for one ARM-based MCU can readily be ported to another without requiring substantial modification.
In a typical scenario, an OEM might want to upgrade an existing product by adding additional features, but these additional features require new peripherals, for instance a touch-sensing controller or an LCD controller, that the existing product’s MCU does not offer. This might require a change from one ARM Cortex-M3-based controller to a different MCU, also based on an ARM Cortex-M3 core. Designers might therefore assume that the firmware and application code running on the first device will run easily on the second.
After all, both cores are called ARM Cortex-M3, so they must surely be the same?
Likewise, a designer who has developed a system on an ARM Cortex-M0+ core knows the capabilities, performance and features of that core. This designer, then, could assume that they can use any vendor’s MCU with an ARM Cortex-M0+ core in a new project, confident that the CPU will offer exactly the same capabilities, performance and features.
Unfortunately, these assumptions are not always completely valid. The label ‘ARM Cortex-M3’ is not attached to a piece of hardware that is unique and reproducible. It is in fact just a naming convention. ARM attaches the label ‘ARM Cortex-M3’ to a bundle of elements of intellectual property (IP) which each licencee then configures individually for use in each variant of each MCU that it produces.
Clearly, there are strict limits to the number and extent of the flavours of the core that the licencee can make, the structure of the core is very largely fixed by ARM. Nevertheless, it is better not to think of an ARM Cortex-M3, for instance, as being a single core, but rather as an IP platform on which each MCU manufacturer builds its own, unique hardware.
This means that it is important to understand at the outset of a design how the differences in core configuration can affect the performance of the application. In effect, the designer is choosing not from a selection of ARM Cortex-M cores, but from hundreds of permutations of core configurations, like assembling a structure from a LEGO kit. In making this choice, advice from the ARM Certified Engineers at Future Electronics can be extremely helpful.
So what are some of the most surprising differences in core implementations in today’s ARM Cortex-M-based MCUs?
AXI bus: the ARM Cortex-M7 core provides the AXI bus for 64-bit point- to-point communications between memory blocks and the processor. Some instances of the ARM Cortex-M7 core, however, do not connect memory resources and the processor via the AXI bus, but via an external bus instead.
Floating-point unit: the ARM Cortex-M4 and ARM Cortex-M7 cores may include a Floating Point Unit (FPU), or they may not, it is up to the MCU licencee. In an ARM Cortex-M7 core, the FPU might be either the single- or dual-precision type – again, this is a choice made by the MCU manufacturer. Figure 2 shows an example FPU application.
Wakeup Interrupt Controller (WIC): this is a remarkable power-saving feature provided by ARM for all ARM Cortex-M series cores. It provides for the core to be woken up from deep sleep when a signal on a dedicated external pin toggles it from Low to High. The WIC needs no clock, and it typically saves 99% of the power consumed by the core in normal operation. It’s a great feature, but some ARM Cortex-M-based MCUs do not include it. The MCU manufacturer can choose not to implement the WIC, and thus make a small saving in die size and cost, and in power consumption in normal mode. So while it is a standard feature of ARM Cortex-M cores, users should spend time reading the datasheet carefully to ensure that their chosen device has implemented this feature.
Memory Protection Unit (MPU): this protects areas of memory from being overwritten by unprivileged tasks. An MPU may be implemented in any ARM Cortex-M series core except the Cortex-M0. But at the discretion of the MCU manufacturer it might be eliminated in favour of other features.
Micro Trace Buffer (MTB): this feature of the Cortex-M0+ core helps the developer to debug the application in the event of a hard fault during runtime. But the MCU manufacturer has the option to leave it out. The Embedded Trace Macrocell (ETM), which provides a full view of data and addresses during runtime and provides a high-speed interface to an external debugger, may also not be implemented. Standard debug interface, Serial Wire Debug (SWD) or JTAG, may be implemented instead.
Interrupt priorities: in the Cortex-M3, -M4 and -M7 cores, there may be between 8 and 256 levels of interrupts; the number of interrupt priorities supported is chosen each time an MCU manufacturer develops a new product or product variant. An extremely complex application running on an ARM Cortex-M7 core with 256 levels of interrupt priorities might run into problems when ported to a different Cortex-M7-based MCU that only supports 16 levels.
These are examples of some of the most important configuration options that MCU manufacturers have to decide on for each MCU product that they develop. They show how important it is to make the right selection of ARM Cortex-M series core, no matter which manufacturer’s MCU family the designer is considering.
At the beginning of a new design project, designers will save themselves a lot of time and trouble in the later stages of the development if they carefully study the datasheet of the MCU that they are intending to use, and especially the sections which describe the features and functions of the core. Past experience with an ARM Cortex-M core is some guide to future uses of the same type of ARM Cortex-M core, but there might be differences. Designers might run into problems unless they take account of these differences at the very start of a design project.