1. Cortex-M3 Debugging System

2. Chapter 15, 16 in the reference book

3. Debugging Features Overview
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)

4. 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)

5. CoreSight 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

6. Processor Debugging Interface
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

7. JTAG vs. SW 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

8. Connection from Debug Host to the Cortex-M3
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
DP module
AP module

9. Trace Interface
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.

10. CoreSight Characteristics
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.

11. Design Concept of CoreSight Systems
In standard CoreSight systems, a separate bus (with a separate memory map) is used for different controlling debug components :

12. The Debug System in Cortex-M3
In the Cortex-M3, the debugging devices share the same system memory map :

13. Two Debug Modes
Halt mode: the processor stops program execution completely
Instruction 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.

14. 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

15. Breakpoint in Cortex-M3
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

16. The BKPT Instruction
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.