Cortex-M3 Debugging System

Chapter 15, 16 in the reference book

The Cortex-M3 processor provides a comprehensive debugging environment, which can be classified into two groups:

Invasive debugging:

• Program halt and stepping

• Hardware breakpoints

• Breakpoint instruction

• Data watchpoint on access to data address, address range, or data value

• Register value accesses (both read or write)

• Debug monitor exception

• ROM-based debugging (Flash patch)

Debugging Features Overview

Noninvasive debugging:

• Memory accesses (memory contents can be accessed even when the core is running)

• Instruction trace (via the optional Embedded Trace Module)

• Data trace

• Software trace (via the Instrumentation Trace Module)

• Profiling (via the Data Watchpoint and Trace Module)

Debugging Features Overview

The debugging system is based on the CoreSight debug architecture, which covers a wide area:

The processor debugging interface protocol

Debugging bus protocol

Control of debugging components

Security features

Trace data interface

These components are normally used only by debugger, not by application code but it is still useful to have a better understanding of how the debugging system works

CoreSight Overview

Traditionally, ARM processors provide a JTAG interface, allowing registers to be accessed and memory interface to be controlled.

In the Cortex-M3, the control to the debug logic on the processor is carried out via a bus interface, i.e., the Debug Access Port (DAP):

Similar to APB and easy to connect multiple debugging components

JTAG or Serial-Wire (SW) interfaces can be converted into the DAP bus interface protocol

The actual interface type used on the chip can be transparent

The actual debugging functions in the Cortex-M3 processor core are controlled by the NVIC and a number of other debugging components, such as the FPB, the DWT, and the ITM.

NVIC contains a number of registers to control the core debugging actions

the other blocks support features such as watchpoints, breakpoints, and debug message outputs

Processor Debugging Interface

Two debug interfaces to debug host:

JTAG is very popular but with four pins

SW only needs two pins which is an attractive solution for low-end microcontrollers since they have very low pin counts

JTAG vs. SW

DP Module, AP Module, and DAP:DP interface module: converts the external signals into a generic 32-bit debug bus

AP module: acts as a bus bridge to convert commands into AHB transfers, which allows to access debug control registers in NVIC via memory mapping.

AP devices: AHB-AP, APB-AP, JTAG-AP

Connection from Debug Host to the Cortex-M3

DP module AP module

In the CoreSight architecture, there can be three types of trace sources: Instruction trace: generated by the Embedded Trace Macrocell (ETM)

Data trace: generated by DWT

Debug message: generated by ITM (provides message output such as printf in the debugger GUI)

The trace results from the trace sources like ETM can be exported to external trace hardware via a Trace Port Interface Unit (TPIU) for analysis.

Trace Interface

The CoreSight-based design has a number advantages: The memory content and peripheral registers can be examined even when

the processor is running;

Multiple processor debug interfaces can be controlled with a single piece of debugger hardware;

Internal debugging interfaces are based on simple bus design, making it scalable and easy to develop additional test logic for other parts of the chip;

It allows multiple trace data streams to be collected in one trace capture device and separated back into multiple streams on the debug host

The trace results from the trace sources like ETM can be exported to external trace hardware via a Trace Port Interface Unit (TPIU) for analysis.

CoreSight Characteristics

In standard CoreSight systems, a separate bus (with a separate memory map) is used for different controlling debug components :

Design Concept of CoreSight Systems

In the Cortex-M3, the debugging devices share the same system memory map :

The Debug System in Cortex-M3

Halt mode: the processor stops program execution completelyInstruction execution is stopped

SYSTICK counter is stopped

Supports single-step operations

Interrupts can be pended and can be invoked during single stepping or be masked so that external interrupts are ignored during stepping

To enter halt mode, the C_DEBUGEN bit in the NVIC Debug Halting Control and Status Register (DHCSR) must be set.

Two Debug Modes

Debug monitor mode: the processor executes an exception handler to carry out the debugging tasks while still allowing the processor to operate normally.Processor executes exception handler type 12 (debug monitor)

SYSTICK counter continues to run

New arrive interrupts may or may not preempt, depending on the priority of the debug monitor and the priority of the new interrupt

If the debug event takes place when a higher-priority interrupt is running, the debug event will be missed

Supports single-step operations

Memory contents (for example, stack memory) could be changed by the debug monitor handler during stacking and handler execution

Two Debug Modes

One of the most commonly used debug features in most microcontrollers is the breakpoint feature.

In the Cortex-M3, two types of breakpoint mechanisms are supported:

Breakpoint instruction BKPT immediate#

Breakpoint using address comparators in the FPB

Breakpoint in Cortex-M3

The BKPT instruction is a 16-bit Thumb instruction.

It can be used to generate a debug event:If halt debug mode is enabled (C_DBGEN is set), BKPT can halt the processor

If debug monitor mode is enabled, it can be used to trigger the debug monitor exception

Since the debug monitor is one type of exception, it can only be used in Thread or exception handlers with priority lower than itself.

The BKPT Instruction