Hello, and welcome to this presentation of the STM32 debug

interface. It covers the debug capabilities offered by

STM32G4 devices.

1
The STM32G4 incorporates all the familiar debug
capabilities provided by the STM32 family of MCUs – flash
download, breakpoint debugging, register and memory view.
The debug infrastructure uses the ARM® CoreSight™
standard, well supported by most tool providers.

2
Slide 2

T1 Can you provide a picture of ST-Linkv3 ?

Trainer; 03/02/2019
All units involved in the debug process have memory-
mapped registers accessible through the Private Peripheral
Bus (PPB) by both the core and the SWJ-DP.
The debugger can access memory-mapped resources while
the processor is running. For example, a breakpoint can be
set by the debugger by accessing the FPB unit connected to
the Private Peripheral Bus while the processor is executing
instructions.

3
The SWJ-DP enables an external debug probe to access
any memory-mapped resources also accessible from the
Cortex®-M4 core.
Note that the Memory Protection Unit (MPU) does not
intercept the requests initiated by the SWJ-DP.
The SWJ-DP supports two protocols to exchange data with
the debug probe:
• Either the 2-wire Serial Wire Debug (SWD) protocol
• Or the 5-wire JTAG protocol.
The SWJ-DP automatically detects which protocol is used.
Regarding the trace output, the TPIU offers two possibilities:
• Either the asynchronous 1-wire trace port, called Serial
Wire Output (SWO)
• Or the synchronous 5-wire trace port, including a clock
signal and 1, 2 or 4 bits of data.
The SWO is multiplexed with the JTAG JTDO signal.
Consequently it cannot be used at the same time as JTAG
protocol. SWD must be chosen.

4
Five pins are used as outputs from the STM32G4 for the
SWJ-DP as alternate functions of general-purpose IOs.
These pins are available on all packages.
After RESET, all five pins used for the SWJ-DP are assigned
as dedicated pins immediately usable by the debugger host.
However, the STM32G4 MCUs offer the possibility of
disabling some or all of the SWJ-DP ports, and therefore the
possibility of releasing the associated pins for general-
purpose IO (GPIO) usage, except for NJTRST that can be
left disconnected but cannot be used as general purpose
GPIO without loosing debugger connection.
Note that the parallel trace port is not assigned except if
explicitly programmed by the debugger host.
JTAG pins have internal pull-ups and pull-downs which are
by default active:
• Pull-up on NJTRST, JTDI, JTMS/SWDIO
• Pull-down on TCK/SWCLK.

5
The ROM table contains pointers to the base addresses of
each debug component visible from the Core. They are used
by some debug tools to automatically detect the topology of
the CoreSight™ infrastructure in the target.
The SWJ-DP contains a read-only register pointing to the
ROM table.
The SCS (system control space) is a block of registers,
including the CPUID register that indicates the reference and
revision of the CPU, used by the debugger to control entry to
and exit from Halt mode.

6
Invasive debug halts the processor when a debug event
occurs.
Two units are involved in invasive debug:
• The Flash Patch and Breakpoint (FPB)
• The Data Watchpoint and Trace (DWT).

7
Non-invasive debug aims to track what happens in the
processor, without affecting its performance. It is based on
real time trace.
The ETM and ITM modules have the capability of
synthesizing trace packets and issuing them over the AMBA
Trace Bus (ATB).
The TPIU receives the trace packets and outputs them over
an external interface, so that the Trace Port Analyzer (TPA)
can capture them.
The Trace Port Analyzer is generally contained in the same
device as the debug probe.
Two interfaces are supported to transfer trace packets to the
TPA:
• Either the asynchronous Single Wire Output (SWO)
• Or the synchronous parallel trace port.
An overflow condition occurs when a contention is detected
in the TPIU. It means that the bandwidth of the trace port is
not large enough to export all trace packets.

8
Note that trace packets are timestamped in the ITM and ETM
modules.

8
The Flash Patch and Breakpoint unit (FPB) allows hardware
breakpoints to be set.
It contains six comparators to set breakpoint in non-volatile
memories. They monitor the instruction fetch address and
return a breakpoint instruction when a match is detected.
When the breakpoint instruction is executed, the processor
halts in Debug mode.
Two comparators monitor data accesses, used to halt the
processor when particular constants present in non-volatile
memory are accessed.
The FPB only supports address comparisons in the range 0-
0x1FFFFFFF, corresponding to the Flash memory in the
STM32G4.
Beyond address 0x20000000, software breakpoints can be
used when the code is executed from RAM and the DWT
can be used to halt on data accesses.
When a software breakpoint is used, the debugger replaces
the instruction on which the user wants to stop with a

9
dedicated instruction called BKPT.
Any of these eight comparators can be configured to provide
a replacement instruction or constant data instead of halting
the CPU, which is used to patch the contents of non-volatile
memory.

9
The DWT supports more features than just implementing
data watchpoints.
The four comparators on the left of the figure detect a match
condition on either a data address, or an instruction address.
The comparator number 1 can also be configured to detect a
match condition on a data value.
The following actions are supported when a match condition
occurs:
• Halting the core, this is the watchpoint feature
• Asserting a trigger signal to the ETM
• Generating a trace packet to report the data access and
passing it to the ITM so that it can be exported. The
current data and PC value can also be captured to
complement the trace information.
Complex conditions, mixing address and data comparisons
are programmable.
In addition to the comparison logic, the DWT contains 8-bit
statistics counters. When an overflow condition occurs on

10
any of them, the DWT informs the ITM to issue a trace packet
to report this overflow to the debugger.
The DWT is also in charge of triggering the periodic
generation of synchronization packets, which are mandatory
to maintain the synchronization with the trace port analyzer.
This is achieved by a 32-bit timer, which can also be used to
trigger the periodic sampling of the PC value, which is passed
to the ITM, in order to be stored in a trace packet.

10
The DWT is used to trigger watchpoint events caused by a
match between the current data or instruction address and
the contents of comparators programmed by the debugger.
For address matching, the comparator can use a mask, so it
can match a range of addresses.
On a successful match, the comparator generates a
watchpoint debug event, on either the PC value or the
accessed data address.
A match on a data value can be combined with an address
match.
The FPB is more appropriate for implementing instruction
breakpoints, because the breakpoint event occurs when the
instruction is about to enter the execute unit. So if the
instruction which has been fetched is discarded due to a
taken branch, the breakpoint event does not occur while the
watchpoint event occurs.
To read or write a core register, such as R0, the debugger
has to halt the core.

11
The DWT contains statistics counters that facilitate the
system profiling for the processor.
For instance, a counter accumulates the number of clocks
during which the microcode in charge of exception taking and
exiting is active.

11
Two types of trace information are handled by the ITM:
• The hardware trace, which has been described in the DWT
module
• The software trace, which enables software to send data
that will be displayed in the debugger window.
The data written by software in one of the 32 ITM 32-bit
ports is transported in the payload of a trace packet to the
host debugger.
The printf function can be redirected to the ITM ports to
facilitate the code instrumentation.
Two types of timestamps are supported by the ITM unit: the
local time stamping, which indicates the relative time
between two consecutive local timestamp packets and the
global time stamping.
The global time stamping comes from a dedicated 48-bit
also used by the ETM unit.

12
The ETM requires the 4-bit data trace port, because the
SWO does not offer enough bandwidth.
Unlike the ITM, no code instrumentation is needed.
Taken branches and exception events are signaled by the
Cortex®-M4 core to the ETM units, which converts them into
trace packets, which are output onto the ATB port.
When the trace has been captured, the debugger
decompresses it to provide a full disassembly, with symbols,
of the code that was executed. The debugger also link this
back to the original high-level source code, providing you
with a visualization of how the code was executed on the
target.
The ETM is useful to profile the code executed by the
Cortex®-M4 and to investigate complex software bugs.

13
The MCU debug component provides support for:
• MCU identification
• Low-power modes
• Clock control for timers, watchdog, I2C and bxCAN during
a breakpoint
• Control of the trace pins assignment.
The DBG_IDCODE register provides the device ID and
revision codes in STM32 standard format. This code is
accessible by the SWJ-DP or by the user software.
Low-power mode emulation means that the debugger
connection is not lost when entering a low-power mode. It
eliminates the need to replace the low-power entry
command (for example, WFI/WFE) by a while() loop. On
exit, the device is in the same state as if the emulation was
not active (apart from any changes made by the debugger
during the low-power mode emulation).
Peripheral clock freeze is particularly useful to prevent a
watchdog timeout from resetting the device while debugging,

14
without having to re-arm the watchdog with the debugger. It
also allows timer values to be inspected and corresponding
interrupts to be suspended until “normal” operation is
resumed.
The DBGMCU_CR register contains a control field to set
configure the trace port: either asynchronous SWO mode or
synchronous mode with TRACEDATA size of 1, 2 or 4.

14
The ST-Link is a probe developed by ST, that supports SW
and JTAG debug protocol and the SWO trace port.
The third generation of ST-Link is available, supporting
higher bit-rates for SWD and JTAG.
The ST-Link version 3 can be used to transmit/receive data
on the target using UART, I2C, SPI, CAN or GPIO. Only one
of these interfaces can be active at the same time.
For instance, a UART of the STM32G4 can be tested by
connecting it to the host PC via the ST-Linkv3. Character
streams will be transparently transferred over USB.
Furthermore, the ST-Link version 3 supports the download of
a user image by using UART or CAN link from a host PC,
when the boostrap mode is selected upon STM32G4’s reset
deassertion.

15
STM32CubeProgrammer is an all-in-one multi-OS software
tool for programming STM32 microcontrollers.
STM32CubeProgrammer is delivered in GUI (graphical user
interface) and CLI (command-line interface) versions.
It provides an easy-to-use and efficient environment for
reading, writing and verifying device memory, including
option bytes, through both the debug interface (JTAG and
SWD) and the bootloader interface (UART and USB).
Its additional features are:
• Multi-OS support: Windows®, Linux®, macOS®
• Debug and bootloader interfaces support
• ST-Link V3 bridges.
STM32CubeProgrammer supports the Device Firmware
Upgrade (DFU) USB class designed to download a firmware
image to a USB device.

16