Getting Started With Cortex M3 Development

Published Date: 02 Nov 2017

In This Chapter:

● Choosing a Cortex-M3 Product

● Differences Between Cortex-M3 Revision 0 and Revision 1

● Development Tools

Choosing a Cortex-M3 Product

Aside from memory, peripheral options, and operation speed, a number of other factors make

one Cortex-M3 products different from another. The Cortex-M3 design supplied by ARM

contains a number of features that are confi gurable, such as:

• Number of external interrupts

• Number of interrupt priority levels (width of priority-level registers)

• With MPU or without MPU

• With ETM or without ETM

• Choice of debug interface (Serial-Wire, JTAG, or both)

In most projects, the features and specifi cation of the microcontroller will certainly affect your

choice of Cortex-M3 product. For example:

• Peripherals: For many applications, peripheral support is the main criterion.

More peripherals might be good, but this also affects the microcontroller’s power

consumption and price.

• Memory: Cortex-M3 microcontrollers can have Flash memory from several kilobytes

to several megabytes. In addition, the size of the internal memory might also be important. Usually these factors will have a direct impact on the price.

• Clock speed: The Cortex-M3 design from ARM can easily reach more than 100 MHz,

even in 0.18 um processes. However, manufacturers might specify a lower operation

speed due to limitations of memory access speed.

• Footprint: The Cortex-M3 can be available in many different packages, depending on

the chip manufacturer’s decision. Many Cortex-M3 devices are available in low pin

count packages, making them ideal for low-cost manufacturing environments.

Differences Between Cortex-M3 Revision 0 and Revision 1

Early versions of Cortex-M3 products were based on revision 0 of the Cortex-M3 processor.

Products based on Cortex-M3 revision 1 were available since the third quarter of 2006. When

this book is published, all new Cortex-M3 based products should be based on revision 1. It

could be important to know whether the chip you are using is revision 0 or revision 1, because

there are a number of changes and improvements in the second release.

Changes visible in the programmer’s model and development features include these:

• From revision 1, the stacking of registers when an exception occurs can be confi gured

such that it is forced to begin from a double word aligned memory address. This is

done by setting the STKALIGN bit in the NVIC Confi guration Control register.

• For that reason, the NVIC Confi guration Control register has the STKALIGN bit.

• Revision 2 includes the new AUXFAULT (Auxiliary Fault) status register (optional).

• Additional features include data value matching added to the DWT.

• ID register value changes due to the revision fi elds update.

Changes invisible to end users include:

• The memory attribute for Code memory space is hardwired to cacheable, allocated,

nonbufferable, and nonshareable. This affects the I-Code AHB and the D-Code AHB

interface but not the system bus interface.

• Supports bus multiplexing operation mode between I-Code AHB and D-Code AHB.

Under this operation mode, the I-Code and D-Code bus can be merged using a simple

bus multiplexer (previous solution is using an ADK Bus Matrix component). This can

lower the total gate count.

• Added new output port for connection to the AHB Trace Macrocell (HTM, a

CoreSight debug component from ARM) for complex data trace operations.

Debug components or debug control registers can be accessed even during system

reset; only during power-on reset are those registers inaccessible.

• The TPIU has SWV operation mode support. This allows trace information to be

captured with low-cost hardware.

• In revision 1, the VECTPENDING fi eld in the NVIC Interrupt Control and Status

register can be affected by the C_MASKINTS bit in the NVIC Debug Halting Control

and Status register. If C_MASKINTS is set, the VECTPENDING value could be zero

if the mask is masking a pending interrupt.

• The JTAG-DP debug interface module has been changed to the SWJ-DP module (see

the next section, "Revision 1 Change: Moving from JTAG-DP to SWJ-DP"). Chip

manufacturers can continue to use JTAG-DP, which is still a product in the CoreSight

product family.

Since revision 0 of the Cortex-M3 does not have a double word stack alignment feature in

its exception sequence, some compiler tools, such as ARM RealView Development Suite

(RVDS) and the KEIL RealView Microcontroller Development Kit, have special options to

allow software adjustment of stacking, which allows the developed application to be EABI

compliant. This could be important if it has to work with other EABI-compliant development

tools.

To determine which revision of the Cortex-M3 processor is used inside the microcontroller

or SoC, you can use the CPU ID Base Register in the NVIC. The last 4 bits of this register

contain the revision number, as shown in Table 17.1.

Table 17.1 CPU ID Base Register (0xE000ED00)

Implementer Variant Constant PartNo Revision

Individual debug components inside the Cortex-M3 processor also carry their own ID

registers, and the revision fi eld might also be different between revision 0 and revision 1.

Revision 1 Change: Moving from JTAG-DP to SWJ-DP

The JTAG-DP provided in some earlier Cortex-M3 products is replaced with the SWJ-DP. The

Serial-Wire JTAG Debug Port (SWJ-DP) combines the function of the SW-DP and the JTAGDP,

and with automatic protocol detection. Using this component, a Cortex-M3 device can

support debugging with both SW and JTAG interfaces.

Figure 17.1 SWJ-DP: Combining JTAG-DP and SW-DP Functionalities

Development Tools

To start using the Cortex-M3, you’ll need a number of tools. Typically they will include:

• A compiler and/or assembler: Software to compile your C or assembler application

codes. Almost all C compiler suites come with an assembler.

• Instruction set simulator: Software to simulate the instruction execution for debugging

in early stages of software development.

• In-circuit emulator (ICE) or debug probe: A hardware device to connect your debug

host (usually a PC) to the target circuit. The interface can be either JTAG or SW.

• A development board: A circuit board that contains the microcontroller.

• Trace capture: An optional hardware and software package for capturing instruction

traces or output from DWT and ITM modules and outputs them to human-readable

format.

• An embedded operating system: An operating system running on the microcontroller.

This is optional; many applications do not require an OS.

C Compiler

A number of C compiler suites and development tools are already available for the Cortex-M3

(see Table 17.2).

The GNU C Compiler from CodeSourcery provides a free solution. At this writing, the main

GNU C Compiler (GCC) does not have Cortex-M3 support; however, this support will be

merged into the main GCC in the near future. You can also get evaluation versions of some

commercial tools such as RealView-MDK.

Table 17.2 Examples of Development Tools Supporting Cortex-M3

-ARM (www.arm.com) :

The Cortex-M3 is supported from RealView Development Suite 3.0 (RVDS).

RealView-ICE (RVI) version 1.5 is available for connecting debug target to debug

environment. Note that older products such as ADS and SDT do not support the

Cortex-M3.

- KEIL:

The Cortex-M3 is supported in RealView Microcontroller Development Kit

(RealView-MDK). The ULINK(TM) USB-JTAG adapter is available for connecting

debug target to debug IDE.

- CodeSourcery :

GNU Tool Chain for ARM Processors is now available at www.codesourcery.com/

gnu_toolchains/arm/. It is based on GNU C Compiler 4.1.0 and supports the

Cortex-M3.

- Rowley Associates:

CrossWorks for ARM is a GNU C Compiler-based development suite supporting

the Cortex-M3 (www.rowley.co.uk/arm/index.htm).

- IAR Systems :

IAR Embedded Workbench for ARM and Cortex provides a C/C++ compiler

and debug environment. (v4.40 or above). A KickStart kit is also available, based

on the Luminary Micro LM3S102 microcontroller, including debugger and a

J-Link Debug Probe for connecting the target board to debug IDE.

- Lauterbach :

JTAG debugger and trace utilities are available from Lauterbach.

Embedded Operating System Support

Many applications require an OS. Many OSs are developed for the embedded market.

Currently, a number of these OSs are supported on the Cortex-M3 (see Table 17.3).

Table 17.3 Examples of Embedded Operating Systems Supporting Cortex-M3

1 Product names are registered trademarks of the companies listed on the left-hand side of the table.

2 Product names are registered trademarks of the companies listed on the left-hand side of the table.

Porting Applications from the ARM7

to the Cortex-M3

In This Chapter:

● Overview

● System Characteristics

● Assembly Language Files

● C Program Files

● Precompiled Object Files

● Optimization

Overview

For many engineers, porting existing program code to new architecture is a typical task.

With the Cortex-M3 products starting to emerge on the market, many of us have to face the

challenge of porting ARM7TDMI (referred to as ARM7 in the following text) code to the

Cortex-M3. This chapter evaluates a number of aspects involved in porting applications from

the ARM7 to the Cortex-M3.

There are several areas to consider when you’re porting from the ARM7 to the Cortex-M3:

• System characteristics

• Assembly language fi les

• C language fi les

• Optimization

Overall, low-level code such as hardware control, task management, and exception handlers

requires the most changes, whereas application codes normally can be ported with minor

modifi cation and recompiling.

System Characteristics

There are a number of system characteristic differences between ARM7-based systems and

Cortex-M3 based systems (for example, memory map, interrupts, MPU, system control, and

operation modes.)

Memory Map

The most obvious target of modifi cation in porting programs between different microcontrollers

is their memory map differences. In the ARM7, memory and peripherals can be located in

almost any address, whereas the Cortex-M3 processor has a predefi ned memory map. Memory

address differences are usually resolved in compile and linking stages. Peripheral code porting

could be more time consuming because the programmer model for the peripheral could be

completely different. In that case, device driver codes might need to be completely rewritten.

Many ARM7 products provide a memory remap feature so that the vector table can be

remapped to the SRAM after boot-up. In the Cortex-M3, the vector table can be relocated

using the NVIC register so that memory remapping is no longer needed. Therefore, the

memory remap feature might be unavailable in many Cortex-M3 products.

Big endian support in the ARM7 is different from such support in the Cortex-M3. Program

fi les can be recompiled to the new big endian system, but hardcoded lookup tables might need

to be converted during the porting process.

In ARM720T, and some later ARM processors like ARM9, a feature called high vector is

available, which allows the vector table to be located to 0xFFFF0000. This feature is for

supporting Windows CE and is not available in the Cortex-M3.

Interrupts

The second target is the difference in the interrupt controller being used. Program code

to control the interrupt controller, such as enabling or disabling interrupts, will need to be

changed. In addition, new code is required for setting up interrupt priority levels and vector

addresses for various interrupts.

The interrupt return method is also changed. This requires modifi cation of interrupt return

in assembler code or, if C language is used, it might be necessary to make adjustments on

compile directives.

Enable and disable of interrupts, previously done by modifying CPSR, must be replaced by

setting up the interrupt mask register.

In the Cortex-M3, some registers are automatically saved by the stacking and unstacking

mechanism. Therefore, some of the software stacking operations could be reduced or removed.

However, in the case of the FIQ handler, traditional ARM cores have separate registers for

FIQ (R8-R11). Those registers can be used by the FIQ without the need to push them into the stack. However, in the Cortex-M3, these registers are not stacked automatically, so when an

FIQ handler is ported to the Cortex-M3, either the registers being used by the handler must be

changed or a stacking step will be needed.

Code for nest interrupt handling can be removed. In the Cortex-M3, the NVIC has built-in

nested interrupt handling.

There are also differences in error handling. The Cortex-M3 provides various fault status

registers so that the cause of faults can be located. In addition, new fault types are defi ned in

the Cortex-M3 (for example, stacking and unstacking faults, memory management faults, and

hard faults). Therefore, fault handlers will need to be rewritten.

MPU

The MPU programming model is another system block that needs new program code set up.

Microcontroller products based on the ARM7TDMI/ARM7TDMI-S do not have MPUs, so

moving the application code to the Cortex-M3 should not be a problem. However, products

based on the ARM720T have a Memory Management Unit (MMU), which has different

functionalities to the MPU in Cortex-M3. If the application needs to use the MMU (as in a

virtual memory system), it cannot be ported to the Cortex-M3.

System Control

System control is another key area to look into when you’re porting applications. The Cortex-

M3 has built-in instructions for entering sleep mode. In addition, the system controller inside

Cortex-M3 products is likely to be completely different from that of the ARM7 products, so

function code that involves system management features will need to be rewritten.

Operation Modes

In the ARM7 there are seven operation modes; in the Cortex-M3 these have been changed to

difference exceptions (see Table 18.1).

Table 18.1 Mapping of ARM7TDMI Exceptions and Modes to Cortex-M3

The FIQ in the ARM7 can be ported as a normal IRQ in the Cortex-M3 because in the Cortex-

M3, we can set up the priority for a particular interrupt to be highest; thus it will be able to

preempt other exceptions, just like the FIQ in the ARM7. However, due to the difference

between banked FIQ registers in the ARM7 and the stacked registers in the Cortex-M3, the

registers being used in the FIQ handler must be changed, or the registers used by the handler

must be saved to the stack manually.

FIQ and NMI

Many engineers might expect the FIQ in the ARM7 to be directly mapped to the NMI in

the Cortex-M3. In some applications it is possible, but a number of differences between

the FIQ and the NMI need special attention when you’re porting applications using the

NMI as an FIQ.

First, the NMI cannot be disabled, whereas on the ARM7, the FIQ can be disabled by

setting the F-bit in the CPSR. So it is possible in the Cortex-M3 for an NMI handler to

start right at boot-up time, whereas in the ARM7, the FIQ is disabled at reset.

Second, you cannot use SVC in an NMI handler on the Cortex-M3, whereas you can

use SWI in an FIQ handler on the ARM7. During execution of an FIQ handler on the

ARM7, it is possible for other exceptions to take place (except IRQ, because the I-bit is

set automatically when the FIQ is served). However, on the Cortex-M3, a fault exception

inside the NMI handler can cause the processor to lock up.