One reason commonly put forward for using Cortex-M based MCUs is their potential for code portability: the common Cortex-M instruction set and ARM’s Cortex Microcontroller Software Interface Standard – or CMSIS –are important parts of the company’s efforts to highlight to the embedded world that code developed for one ARM based MCU can be ported readily to another without the need for substantial modification.
In a typical scenario, an OEM might want to upgrade an existing product by adding additional features, but these features often require new peripherals – for instance a touch sensing controller or an LCD controller – and these are not available from the existing MCU. This might require a move to a different Cortex-M3-based controller and it’s not unreasonable for designers to 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 might assume they can use any vendor’s MCU which features a 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 valid. The label ‘ARM Cortex-M3’ is not attached to a unique and reproducible piece of hardware; it is, in fact, simply a naming convention. ARM attaches the label ‘ARM Cortex-M3’ to a bundle of elements of intellectual property and licensees can then configure this IP for use in each MCU which they produce.
Clearly, there are strict limits to the number and extent of the flavours of the core that the licensee can make – the structure of the core, for example, is largely fixed by ARM. Nevertheless, it is better not to think of an ARM Cortex-M3, for instance, as being a single core; rather, consider it as an IP platform on which each MCU manufacturer builds its own 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 handful of ARM Cortex-M cores, but from hundreds of permutations of core configurations – in some ways, it can be like assembling a structure from a kit. In making this choice, advice from ARM Certified Engineers at distributors or other service suppliers can be extremely helpful.
Surprising differences
So what are some of the most surprising differences in core implementations in the latest MCUs based on the Cortex-M?
- AXI bus. The Cortex-M7 core provides the AXI bus for 64bit point to point communications between memory blocks and the processor. However, some instances of the Cortex-M7 connect memory resources and the processor via an external bus and not via the AXI bus.
- Floating point unit. The Cortex-M4 and Cortex-M7 cores may or may not include a floating point unit (FPU) – that is a decision made by the MCU licensee. In a Cortex-M7 core, the FPU might be a single- or dual precision type – again, this is a choice made by the MCU manufacturer.
- Wakeup interrupt controller. This is a remarkable power saving feature provided by ARM for all Cortex-M series cores. It enables the core to be woken from deep sleep when a signal on a dedicated external pin toggles it from Low to High. The controller needs no clock and typically saves 99% of the power consumed by the core in normal operation. It’s a great feature – but it’s not found in all MCUs based on the Cortex-M core. The MCU manufacturer can choose to not implement the controller and thus make a small saving in die size and cost and in power consumption in normal mode. So, while it’s a standard feature of Cortex-M cores, users should spend time reading the datasheet carefully to ensure it’s available from their chosen device.
- Memory protection unit. This function protects areas of memory from being overwritten by unprivileged tasks. An MPU may be implemented in any Cortex-M series core, with the exception of the Cortex-M0. But the MCU manufacturer might have been eliminated this in favour of other features.
- Micro Trace Buffer. This feature of the Cortex-M0+ core helps the developer to debug the application in the event of a hard fault during runtime. But MCU manufacturers have the option of omitting it. Likewise the Embedded Trace Macrocell, which provides a full view of data and addresses during runtime and which provides a high speed interface to an external debugger. A standard debug interface – Serial Wire Debug or JTAG – may be implemented instead.
- Interrupt priorities. The Cortex-M3, M4 and M7 cores may have anywhere from eight to 256 levels of interrupts; the number of interrupt priorities supported is chosen every time an MCU manufacturer develops a new product or product variant. So an extremely complex application with 256 levels of interrupt priorities running on a Cortex-M7 core might run into problems when ported to a different Cortex-M7 based MCU that only supports 16 levels.
Make the right choice
These are examples of some of the most important configuration options that MCU manufacturers have to decide on for each product they develop. They show how important it is to make the right selection of Cortex-M series core, no matter from which manufacturer’s MCU family the designer is choosing.
At the beginning of every new design project, designers will save themselves a lot of time and trouble in the later stages of the development if they study carefully the datasheet of the MCU they are intending to use – and especially the sections which describe the features and functions of the core.
While past experience with a Cortex-M core is some guide to future uses of the same type of Cortex-M core, there might be differences. Designers might well run into problems unless they take these differences into account at the very start of their project.
Author profile:
Uwe Knipping is a field applications engineer with Future Electronics Germany.
