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
Top Related