When porting applications from these microcontrollers to the Cortex-M processors, the modifications of the software typically involve the following:

On the other hand, the stack size could decrease because of the following:

Overall, the total RAM size required could decrease significantly after porting because in some legacy processor architectures such as the 8051, local variables are defined statically in data memory space rather on the stack. For these architectures, the memory space is used even when the function or subroutine is not running. Whereas in ARM processors, local variables are typically allocated on stack memory and take up memory space only when the function or subroutine is executing. Also, with more registers available in the ARM processor's register bank compared to some other architectures, some of the local variables might only need to be stored in the register bank instead of taking up memory space.

Due to high code density, the program memory requirements in ARM Cortex-M processors are normally much lower than 8-bit microcontrollers, and often lower than most 16-bit microcontrollers. So when you port your applications from these 8-bit or 16-bit microcontrollers to ARM Cortex-M0 or Cortex-M0+ microcontrollers, you could possibly use a device with smaller flash memory size. The reduction of the program memory size is often caused by the following:

There can be exceptions—For applications that contain only small amount of code, the code size in ARM Cortex-M0/Cortex-M0+ microcontrollers could be larger compared to 8-bit or 16-bit microcontrollers because of the following:

unsigned char i; /∗ use 8-bit data to avoid 16-bit processing ∗/
char a[10], b[10];
for (i=0;i<10;i++) a[i] = b[i];

When compiling the same program on ARM processors, the compiler will have to insert a UXTB instruction to replicate the overflow behavior of the array index (“i”). To avoid this extra overhead we should declare “i” as integer “int”, “int32_t”, or “uint32_t” for best performance.

Another example is the unnecessary use of casting. For example, the following code uses casting to avoid the generation of 16 × 16 multiply operation in an 8-bit processor:

unsigned int x, y, z;
z = ((char) x) ∗ ((char) y); /∗ assumed both x and y must be less than 256 ∗/

Again, such casting operation will result in extra instructions in ARM architecture. Since Cortex-M processors can handle 32 × 32 multiply with 32-bit result in a single instruction, the program code can be simplified into:

unsigned int x, y, z;
z = x ∗ y;

While it is less common to find ARM920T, 922T, and 940T processors today, there are still ranges of ARM926EJ-S and even ARM11 series processors on the market. However, those designs are usually focussed on running embedded Linux systems and have quite different application areas compared to the Cortex-M0 and Cortex-M0+ processors. For these applications, it is more common to migrate to the newer Cortex-A processors.

Since there are still a number of ARM7TDMI-based microcontrollers on the market, we will cover the key differences between the ARM7TDMI and the Cortex-M0 and Cortex-M0+ processors, and then cover the software migration considerations.

Some of the exception models from the ARM7TDMI are combined in Handler mode in the Cortex-M0/Cortex-M0+ processors with different exception types. For example, see Table 22.9.

The reduction of operation modes simplifies the programs running on Cortex-M processors. For example, in ARM7TDMI you need to set up different SPs for different modes, whereas in the Cortex-M processor it is fine to run many applications with just one SP, and need a second SP when an Embedded OS is used.

There are some differences between the CPSR (Current Program Status Register) in the ARM7TDMI and the xPSR in the Cortex-M processors. For instance, the mode bits in CPSR are removed, replaced by IPSR, and interrupt masking bit I-bit is replaced by the PRIMASK register, which is separated from the xPSR.

Despite the differences between the register banks, the programmer's model or R0 to R15 remains the same. As a result, most Thumb^® instruction codes on ARM7TDMI can be reused on Cortex-M processors, simplifying software porting.

In ARM7TDMI, since the FIQ has more banked registers and its vector is located at the end of the vector table, it can work faster by reducing the register stacking required and the FIQ handler can be placed at the end of vector table to avoid branch penalty.

Unlike the ARM7TDMI, the Cortex-M0 and Cortex-M0+ processors have a built-in interrupt controller called NVIC with up to 32 interrupt inputs. Each interrupt can be programmed at one of the four available priority levels. There is no need to separate interrupts into IRQ and FIQ because stacking of registers is handled automatically by hardware. In addition, the vector table in Cortex-M processors stores the starting address of each interrupt service routine, while in ARM7TDMI the vector table holds instructions (usually branch instructions that branch to interrupt service routines).

When the ARM7TDMI processor receives an interrupt request, the interrupt service routine starts in ARM state (using ARM instruction set). Additional assembly wrapper code is also required to support nested interrupts. In Cortex-M processors there is no need to use assembly wrappers for normal interrupt processing.

Examples of start-up code for Cortex-M0/Cortex-M0+ based microcontrollers can be found in various examples in this book, which is available on the companion Web site.

The interrupt wrapper functions for nested interrupt support for the ARM7TDMI processor must be removed. If the interrupt service routine was written in assembly, the handler code will probably require rewriting because many ARM^® instructions cannot be directly mapped to Thumb^® instructions. For example, the exception handler in ARM7TDMI can be terminated by “MOVS PC, LR” (ARM instruction). This is not valid for Cortex-M0/M0+ processors and must be replaced by a “BX LR” instruction or a POP instruction.

FIQ handlers for the ARM7TDMI processor might rely on the behavior that R8 to R14 are banked in ARM7TDMI to save execution time. For example, constants used by the FIQ handler might be preloaded into these banked registers before the FIQ is enabled. When porting such handlers to the Cortex-M processors, the constants must be loaded into the registers within the handler.

In some cases you might find assembly code being used to enable or disable interrupts by modifying the I-bit in CPSR. In Cortex-M processor, this is replaced by the PRIMASK interrupt masking register. Note that in ARM7TDMI, you can carry out the exception return and change I-bit in a single exception return instruction. In the Cortex-M processors, this method cannot be used because the PRIMASK and xPSR are separate registers. As a result, if the PRIMASK register is set during an exception handler, it must be cleared before the exception exit. Otherwise the PRIMASK register will remain set and no other interrupts (apart from NMI) can be accepted.

The C code should be recompiled to ensure that only Thumb instructions are used and no attempt to switch to ARM state should be contained in the compiled code. Similarly, library files must also be updated to ensure that it will work with Cortex-M processors.

Be careful with legacy Thumb programs that use the CODE16 directive. When the CODE16 directive is used, the instructions are interpreted as traditional Thumb syntax. For example, data processing op-codes without S suffixes are converted to instructions that update APSR when CODE16 directive is used. However, you can reuse assembly files with CODE16 directive because it is still supported by existing ARM development tools. For new assembly code, the Thumb directive is recommended, which indicates to the assembly that the UAL (Unified Assembly Language) is used. With UAL syntax, data processing instructions updating the APSR require the S suffix.

Fault handlers and system exception handlers like SWI must also be updated to work with Cortex-M processors.

For assembly code migrated from the ARM7TDMI, the data type conversion is one of the potential areas for improvement due to new instructions available in the ARMv6-M architecture.

If the interrupt handlers were written in assembly, there might be chance that the stacking operations can be reduced since R0–R3, R12 are automatically stacked by the exception sequence.

More sleep mode features are available in the Cortex-M processors which can be used to reduce power consumption. To take the full advantages of the low power features on a Cortex-M0 or Cortex-M0+ based microcontroller, you will need to modify your application codes to make use of the power management features in the microcontroller. These features are dependent on the microcontroller products and the information in this area can usually be found in user manuals or application notes provided by the microcontroller vendors. Chapter 19 covers some of the examples of using low power features in microcontrollers.

With the nested interrupts being automatically handled by processor hardware and availability of programmable priority levels in the NVIC, priority level of the exceptions can be rearranged for best system performance.

In terms of system level aspects, the main differences among the Cortex-M processors are shown in Figure 22.2.

The Cortex-M3, Cortex-M4, and Cortex-M7 processors have higher performance than the Cortex-M0 and Cortex-M0+ processors due to extra instructions, various differences in the bus level architecture and processor's pipeline (e.g., superscalar support in the Cortex-M7 processor). However, the additional capabilities also increase power consumption. So it is important to understand the requirements of the targeted applications (e.g., battery life vs performance) and the characteristics of the microcontroller products when selecting the processor for your projects.

For the programmer's model, unprivileged mode (Unprivileged Thread—when not executing exception handlers) is optional in ARMv6-M and is not available in the Cortex-M0 processor at all. This is always available in ARMv7-M architecture. The unprivileged thread mode has limited access to the processor configuration registers (e.g., NVIC, SysTick), and an optional memory Protection Unit (MPU) can be used to block programs running in user threads from accessing certain memory regions (Figure 22.3).

Apart from the operation modes being different, the ARMv7-M architecture also has additional interrupt masking registers. The BASEPRI register allows interrupts of certain priority level or lower to be blocked, and the FAULTMASK provides additional fault management features.

The control register in the Cortex-M4 and Cortex-M7 processors also has an additional bit (bit[2]—Floating Point Context Active, FPCA) to indicate if current executing context has been using floating point operations.

The xPSR in the ARMv7-M architecture also has a number of additional bits to allow an interrupted multiple load/store instruction to be resumed from the interrupted transfer, and to allow an instruction sequence (up to four instructions) to be conditionally executed. And when DSP extension is present (i.e., Cortex-M4 and Cortex-M7 processors), there are also additional bit field (GE[3:0]—Great Than or Equal flags) for some of the SIMD (Single Instruction Multiple Data) operations.

Finally, the ARMv7-M architecture supports unaligned data transfers for a limited range of load and store instructions, while ARMv6-M architecture does not.

The differences of the NVIC features in the Cortex-M processors are shown in Table 22.12.

There are a number of differences, but in terms of software porting across different Cortex-M processors it is often quite straightforward, as shown in Table 22.13. One of the major differences is that some of the NVIC registers in ARMv7-M can be accessed using byte or half-word accesses, whereas in ARMv6-M it is limited to 32-bit accesses. For example, if an interrupt priority register needs to be updated, you need to read the whole word (which consists of priority level settings for four interrupts), modify 1 byte, and then write it back. In ARMv7-M architecture, this can be carried out using just a single-byte size write to the priority level register. For users of the CMSIS device driver library, this difference in the programmer's model does not cause any software porting issue because NVIC access functions in CMSIS-CORE have the same name and the function implementations for each processor use the correct access method for ARMv6-M or ARMv7-M accordingly.

Cortex-M processors with ARMv7-M architecture have additional fault handlers with programmable priority level. It allows the embedded systems to be protected by two levels of fault exception handlers (Figure 22.4).

These additional fault handlers are programmable. By default they are disabled (and the fault exception would trigger HardFault exception instead). If enabled, these additional fault handlers can be used to handle specific range of fault events as shown in Table 22.14.

There is also a Debug Monitor exception in ARMv7-M architecture. This is for software-based debug solution and is not needed for application code.

These additional instructions allow faster processing of complex data like floating point values. They also allow the Cortex-M3, Cortex-M4, and Cortex-M7 processors to be used in audio signal processing applications, real-time control systems.

The Cortex-M4 and Cortex-M7 processors support a superset of the instructions in the Cortex-M3. The additional instructions include the following:

When porting applications from ARMv7-M to ARMv6-M:

There are a number of features available on the ARMv7-M architecture that are not available on ARMv6-M architecture.

Unaligned memory accesses—In the ARMv6-M architecture, all the data transfer operations must be aligned. This means a word-size data transfer must have address a value divisible by 4, and half-word data transfer must occur at even addresses. The ARMv7-M architecture allows many memory access instructions to generate unaligned transfers. On the ARMv6-M (e.g., Cortex-M0 and Cortex-M0+ processors), access of an unaligned data has to be carried out by multiple instructions.

Exclusive accesses—The ARMv7-M architecture supports instructions for exclusive accesses, which is used for handling of shared data in multiprocessor systems such as semaphore operations. The processor bus interface supports additional signals for connecting to a system level exclusive access monitor unit on the bus system.

The Cortex-M3 and the Cortex-M4 processors have an optional system feature call bit band. This feature creates 2-bit addressable memory regions called the bit-band regions. The first bit-band region is in the first 1 MB of the SRAM region (from 0x20000000), and the second one is the first 1 MB of the peripheral region (0x40000000). Using two other memory address range called bit-band alias regions, each data bit in the bit-band region can be individually accessed and modified. With the Cortex-M0 and Cortex-M0+ processors, although the processors themselves do not have the bit-band feature, equivalent functionality can be added to the system using bus level mapping components. So it is possible for a Cortex-M0 or Cortex-M0+ microcontroller to provide bit-band feature as in Cortex-M3 and Cortex-M4-based designs.

A comparison of the debug and trace features is show in Table 22.16.

The Cortex-M3, Cortex-M4, and Cortex-M7 processors support trace connection, which allows a range of addition information to be sent to the debugger in real time to provide more information about the program execution:

The trace data can be captured using a trace capturing device such as the Keil^® ULINKPro™.

In addition to debug and trace, the breakpoint unit in the Cortex-M3 and Cortex-M4 processors can also be used for patching code in ROM (e.g., mask ROM). This feature is called flash patch. For microcontroller devices based on flash memories this feature is not required as the program code can be updated by reprogramming the flash.