A developer's insight into ARM Cortex M

debugging
Mark Kraeling - November 03, 2010

A software developer describes tips and tricks for using the built-in debugging options on
the ARM Cortex M microcontroller. (Paper from ARM TechCon 2010.)

This article is from class ATC-133 at ARM Technology Conference. Click here for more information about the conference.

This paper focuses on the various hardware debug options that are available on ARM Cortex M
microcontrollers. I explain the debug options from a software developer's point of view and
demonstrate them using a standard ARM family tool. I also show specific debugging cases such as
determining the cause of a reset and how you can find the cause using the different debug options.
The paper will provide information that's useful when choosing the right debugging hardware for a
project.

The paper provides an overview of the JTAG interface which ARM Cortex M is based, discusses the
various interfaces that are available, and provides some tips and tricks to make debugging for the
software developer easier.

A shift in understanding
As a software developer dealing with embedded systems, I needed to shift some of my understanding
when first working with ARM processors. I was used to the larger scale debugging platforms and
chip manufacturer's specific ways to access memory, set breakpoints, and manipulate registers.

After shifting to ARM Cortex M processors, I first used a Cortex M3-based device and then switched
to another project using Cortex M0. Both platforms were very different, with the M3 project being a
safety-critical multiprocessor design and the M0 project processor serving a more supervisory role
to the overall system. In the past I may have had to re-learn an entirely different set of tools, or use a
different compiler and debugger. Even with the wide scopes of project, I was able to keep the same
base language and understanding of debugging.

I put this paper together to outline many of the things that I had to learn early on before spinning a
board for our projects, and things that I wish I would have known as the project moved on. This
paper is being written from the standpoint of being a software developer on both safety-critical and
smaller scale projects. I hope that the information contained in the paper and presentation is useful
to developers.

For the paper, I will outline a brief history of JTAG which the Cortex M debugging is based, discuss
the various options and configurations for debugging, and finally provide some tips and tricks that I
have learned while developing.

A brief history of JTAG

In the 1980s, processors certainly had a lot less integration and were a lot slower than the
processors today--a huge understatement. My earliest debugging experiences involved debugging on
8086 and 68HC11, where in-circuit emulation was prominent. The chip was lifted off the target
board, and a variety of sockets and cables were added so a separate hardware device could
understand precisely what the processor was doing.

LQFP packaging made this more difficult, and I remember having to use "locator grids" and various
other means to be able to seat the emulator around the chip. Development occurred with items like
caches turned off, and compiler optimization minimized, so the emulators could keep up with what
was going on. As processors got faster and more integrated, something had to change for software
debugging. Page 2

The Joint Test Action Group (JTAG) was formed in the mid 1980s to figure out how to best test
printed circuit boards after they had been manufactured. It later turned into IEEE standard 1149.1.
Manufacturers needed something to determine whether solder joints on chips had all been done
correctly. Now JTAG is also used to access the various blocks that are onboard the microcontroller,
and is often available immediately after chip reset.

Software developers take advantage of JTAG by using to program flash onboard the chip, and setup
breakpoints where execution is halted when a specific address is encountered. Some
implementations of JTAG have also allowed watchpoints to be developed, where an event at a
particular address is highlighted without actually stopping the processor core. JTAG continues to
have features necessary for board manufacturing, including boundary scan testing and flash
programming. Figure 1 shows an example of how multiple devices can be connected to a single
JTAG port connector and used:

Figure 1:

Click on image to enlarge.

ARM Cortex M debugging builds on the foundation of JTAG, supports it, and even adds some more
mechanisms to make software debugging easier.
Debug mechanisms available
When first starting a project, the easiest step to take up front is purchasing a COTS development
board that has the particular processor that is being considered for your project. Often these
development boards have a variety of debug connectors available on them, with jumpers to select
which interface is used.

For one of our Cortex M3 projects, the processor was so new that a suitable development board
wasn’t available. Many manufacturers are upgrading their ARM7 core devices to Cortex M3, so we
determined that the pin layout for the new chip happened to be exactly the same as an older ARM7.
We purchased this particular board, lifted the old chip and then placed our new one in order to get
development started. Before laying out your own board, I highly recommend getting a development
board to determine the type of debug connectors and functionality that is needed.

Another point is the amount of confusion that can happen when determining what type of debugging
that you want to do. With terms like ITM, SWO, SWV, etc there can be a lot of debug functionality
that will be lost if your board is put together without taking advantage of it. Specific pins must be
brought out for each of the debug functions you want to deploy.

The following list shows the debug hardware interfaces that can be available for each of the Cortex
M processors, and an explanation of each follows:

Cortex M0: JTAG / SWD

Cortex M1: JTAG (JTAG-DP) / SWD (SW-DP)
Cortex M3: JTAG / SWD / SWO / ETM TraceData
Cortex M4: JTAG / SWD / SWO / ETM M4 (v3.5 std)

JTAG: Discussed in more detail above, but this is more of a legacy interface for software
development and debugging and is also used for manufacturing test. In most instances, it is better to
turn this off and choose serial wire debug (SWD) instead for debugging software. In ARM-based
debuggers, there is typically a menu where you choose between this and SWD, exclusive to each
other.

SWD: serial wire debug. An enhancement to JTAG, where commands are transferred at a high rate
of speed between the debugger and the interface to the core. Data from watchpoint and breakpoint
registers is transferred.

SWO: serial wire output: This is a special pin that allows additional data transfer off the
microcontroller while it is running. Typically, data is sent over this port without having to stop or
burden the processor core. Facilities for a printf() type of output and being able to look at memory
regions while running are used.

ETM: Up to four additional "tracedata" pins are used to reflect every instruction that is executing to
the debugger. This trace data can be used to capture the events leading up to a defined event, or
also used to provide code coverage statistics (important for vital software development) or execution
information. For Cortex M4, this interface is expanded to include FIFO queues for information,
counters, differing trigger definitions, and other upgraded features over Cortex M3.

These just define the hardware interfaces that exist between the Cortex M microcontroller and the
debug hardware. The next section of the paper discusses the actual hardware on-chip for the various
configurations.
Page 3
On-chip peripherals
The previous section discussed the hardware outputs that are available on Cortex M series
processors. These hardware pins connect to a variety of onboard blocks that are connected or
serviced by the Cortex core. This section of the paper will discuss these in detail, and the importance
of having them during software development.

Cortex M0: This is the simplest set of hardware functionality that could be available on the
microcontroller. It contains a basic set of ARM CoreSight functionality. The following diagram from
the ARM website shows the block diagram in Figure 2.

Figure 2:

Click on image to enlarge.

The standard CoreSight module on the M0 includes processor halt, single-step, processor core
register access, memory access, and software breakpoints. There are derivatives of the core that
actually have no debug access, and are typically used for high-volume applications where reset is the
only item that is needed.

As shown in the diagram above, the watchpoint and breakpoint units are optional components on the
M0. The breakpoint unit can support one to four hardware breakpoints. The watchpoint unit
supports one or two watchpoints. These items are very useful in software debugging, so before
selecting an M0 chip look to see what is supported on that particular device.

Cortex M1: The Cortex M1 is similar in many respects to the Cortex M0. It includes a debug unit
that is capable of single stepping, reset capture, core register access, and read/write access to many
of the memory mapped memory and peripherals.

It also includes breakpoints and watchpoints as standard to the core. These facilities are not optional
as part of the core architecture, but the number of them has different configurations. The Cortex M1
also makes use of a BPU unit for additional debug facilities.

The BPU provides either two or four comparators, based on whether the chip has the reduced or full
debug configuration. The comparators can be setup to provide hardware breakpoints as well.

The DWU provides either two comparators in the full debug configuration, and one comparator in
the reduced debug configuration. These comparators can be setup to monitor for either a hardware
instruction address watchpoint or a data address watchpoint.

Cortex M3: The Cortex M3 builds upon the debug units that are available in the M1, but adds a lot
of additional functionality as well. The Cortex M3 easily contains twice the amount of information for
software development and debugging as the M1. Instead of rehashing the same common
functionality that exists in M1, a super brief description will be given instead.

The Cortex M3 includes a basic debug unit with single-step, register viewing, and breakpoint
control. It also includes a similar BPU, and a DWT that is also similar to the M1 DWU. The number of
breakpoint and watchpoint registers is variable based on the core.

The FPB is a new module for the Cortex M3. It includes either four or eight comparators depending
on the options, and includes a flash patcher to remap code space to system space when needed to do
so. It also includes the option to break when the remap occurs. Page 4

Another optional module is the ITM, or instruction trace macrocell. The software can write items
directly to the ITM, and they are output in a printf() type of format. Hardware components like the
DWT can also send information directly to the ITM. Information is sent out the SWV pin, serially,
with relative timestamps of the event. Because of the bandwidth of this pin, typically only a small
number of actual trace datapoints can be written to this port.

The higher end module is called ETM, or embedded trace macrocell. The amount of silicon that the
ETM takes up actually is nearly the size of the Cortex M3 chip proper. The ETM has a lot more
functionality, and also requires the use of a more advanced debug unit above the standard 10-pin to
get all of the ETM information. The chip can be put onto the board to take advantage of 1, 2, or 4
ETM trace pins. The ETM can be configured to use any of these options, with 4 being able to provide
more data.

The TPIU, or trace port interface unit, provides the glue between the ITM and ETM and the outside
world. It includes an interface to the SWO pin, which allows printf() type information to be sent to
the debugger for viewing. Software information can be sent out this port as well, for any developers
that wish to have a simple interface to understand code execution. There is no throttle – if the
developer tries to send too much information the data can get garbled and unreadable.

Cortex M4: The Cortex M4 has a very similar debug mechanism as the Cortex M3. All of the
components that the M3 has are present on the M4. The information that was reviewed for the paper
was preliminary, so there are likely other modules that will be shown during the paper presentation.

Of note, a newer version of the ETM called "ETM-M4" shows up on the block diagram. A review of
the architecture layout is shown in Figure 3.

Figure 3:
Click on image to enlarge.

Software tips and tricks for debugging

There are numerous ways to take advantage of the debugging options for the various Cortex M cores
that are included on microcontrollers. These tips are based on my experience of doing both Cortex
M0 and M3 debugging. I have not had the opportunity to use M1 or M4, though both are similar to
their counterparts.

SWD vs JTAG: Debuggers have the option to use either JTAG or SWD for debugging as long as the
hardware has brought out all of the lines. SWD has more capability, and can run much faster than
the JTAG interface. The debuggers that I have used default to JTAG, so look for this option early in
the project setup and make sure it works.

SWO/SWV: This port is worth its weight in gold! Make sure that this pin is brought out for Cortex
M3/M4 so you have very easy output capability without having to devote an entire serial port for it.
Debuggers have the capability built in to display this data.

Clock rate for SWD: Consult the microcontroller datasheet to determine how fast you can run the
SWD interface. Set as high as possible!

Efficient use of breakpoints: The number of breakpoints is limited, and typically code is run out of
the onboard flash so there is no "insert a breakpoint into RAM" capability. Try to structure software
code to take this into consideration. For instance, with the abnormal conditions that happen with our
system we call a basic "assert" function that outputs the error with the serial wire output. However,
since all of the abnormal conditions call this function we can set a single breakpoint to trap the
condition, and trace back to where the error occurred.

Power of ETM: The ETM interface adds the capability to do full tracing of software execution. This
is an optional unit that is not present on some of the Cortex M3 offerings. When considering a
Cortex M3-based microcontroller, evaluate whether the ETM interface is available and whether you
can support it. Many times these pins are multiplexed with others, so make sure if you are paying a
premium that you can actually use it. Remember that different debugger hardware is required, that
supports either the newer 0.05" 20-pin connector or the 38-pin Mictor connector interface.

ETM connector board placement: With the addition of the ETM trace pins, it is highly
recommended that the connector be placed as close to the processor as possible. With board designs
that we have done, we use the 0.05" 20-pin connector close to the processor, and then extend only
the necessary lines from this connector out to the standard 0.05" 9-pin connector that supports JTAG
and SWD that does not need to be near the processor. Page 5

What's next?
I hope this paper was insightful and provided some information on Cortex M debugging options, and
things to look for.

The first section outlined the various hardware involved on the chip across the various Cortex M
configurations. As you move from M0 to M4, the capabilities increase substantially. Understanding
what they are could be important in the chip selection that you perform. All M0s and other chips are
not treated the same. They may have varying numbers of registers for breakpoints, watchpoints, and
other functionality.

The second section was devoted to the actual modules that perform the debug functionality that are
present on chips. Again, keep in mind that many of the modules are optional, such as ETM, but may
bring great value in being able to debug software.

The last section was devoted to tips and tricks. All of these are important to keep in mind, and more
will be given in the paper presentation. As newer chips with the M4 core are announced, even more
functionality will be present.

As the Cortex M line becomes more advanced, I am hopeful that the debug functionality will
increase to be similar to the in circuit emulation that I had in the early 1990s. With the ability to
monitor the AHB and APB buses directly, these debug modules are becoming smarter to "look into"
what is being done as opposed to being intrusive.

Mark Kraeling is a product manager working in product development at GE Transportation in

Melbourne, Florida. His expertise is working in the automotive and transportation industries
developing real-time embedded software. Software projects have included radio remote controlled
locomotives, vital wayside signaling systems, and common rail fuel systems. Mark holds a BSEE
from Rose-Hulman, an MBA from Johns Hopkins, and is working on an MSE from Arizona State.

Bibliography

● CoreSight ETM-M4, Technical Reference Manual. Revision r0p1. 2010 Arm Limited, DDI 0440C –
ID070610. From ARM developers website.
● Cortex-M0 Devices, Generic Users Guide. 2009 ARM Limited, DUI 0497A – ID112109. From ARM
developers website.
● Cortex-M1, Technical Reference Manual. Revision r1p0. 2008 ARM Limited, DD¬10413D. From
ARM developers website.
● Cortex-M3. Technical Reference Manual. Revision r2p1. 2010 ARM Limited, DDI 03371 –
ID072410. From ARM developers website.
● "JTAG IEEE 1149 Tutorial". 1997 TI Test Symposium. Published 10-Sep-97. Accessed from website:
http://www.ee.imperial.ac.uk/pcheung/teaching/ee3_DSD/ti_jtag_seminar.pdf

** Note: The figures posted in the paper for Cortex M0 and M4 are taken from respective ARM
documents listed above