 Hello and welcome to this presentation of the STM32 Debug Interface. It covers the debug capabilities offered by STM32 G4 devices. The STM32 G4 incorporates all the familiar debug capabilities provided by the STM32 family of MCUs. Flash download, break point debugging, register and memory view. The debug infrastructure uses the ARM CoreSight standard, well supported by most tool providers. All units involved in the debug process have memory mapped registers accessible through the Private Peripheral Bus, or PPB, by both the Core and SWJDP. The debugger can access memory mapped resources while the processor is running. For example, a break point can be set by the debugger by accessing the FPV unit connected to the Private Peripheral Bus while the processor is executing instructions. The SWJDP enables an external debug probe to access any memory mapped resources also accessible from the Cortex-M4 core. Note that the memory protection unit, or MPU, does not intercept the requests initiated by the SWJDP. The SWJDP supports two protocols to exchange data with the debug probe. Either the two-wire serial wire debug, or SWD protocol, or the five-wire JTAG protocol. The SWJDP automatically detects which protocol is used. Regarding the trace output, the TPIU offers two possibilities. Either the asynchronous one-wire trace port, called Serial Wire Output, or SWO, or the synchronous five-wire trace port, including a clock signal, or one, two, or four 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. Five pins are used as outputs from the STM32G4 for the SWJDP as alternate functions of general-purpose IOs. These pins are available on all packages. After reset, all five pins used for the SWJDP 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 SWJDP ports, and therefore the possibility of releasing the associated pins for general-purpose IO or GPIO usage except for NJTRST that can be left disconnected but cannot be used as general-purpose GPIO without losing 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. 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 core site infrastructure in the target. The SWJDP port contains a read-only register pointing to the ROM table. The system control space, or SCS, 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. Invasive debug halts the processor when a debug event occurs. Two units are involved in invasive debug. The flash patch and breakpoint, or FPB. The data watch point and trace, or DWT. 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, or ATB. The TPIU receives the trace packets and outputs them over an external interface so that the trace port analyzer, or 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, or 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. Note that trace packets are time-stamped in the ITM and ETM modules. The flash patch and breakpoint unit 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 to 0x1FFFFFF corresponding to the flash memory in the STM32G4. Beyond address 0x20 million, 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 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. 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 one 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 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. 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 links 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 provide the code executed by the Cortex-M4 and to investigate complex software bugs. 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 access 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. 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. 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 ITM unit. The MCU debug component provides support for MCU identification, low power modes, clock control for timers, watchdog, I2C and FD CAN during a breakpoint, control of the trace pins assignment. The DBG ID code 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 or 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 without having to rearm the watchdog with the debugger. This 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 a synchronous SWO mode or synchronous mode with trace data size of 1, 2 or 4. The ST-Link is a probe developed by ST that supports SWD 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 and 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-Link V3. 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 bootstrap mode is selected upon STM32G4's reset de-assertion. STM32Cube Programmer is an all-in-one multi-OS software tool for programming STM32 microcontrollers. STM32Cube Programmer is delivered in graphical user interface and command line interface version. 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, Mac OS, debug and bootloader interfaces support, ST-Link, V3 bridges. STM32Cube Programmer supports the Device Firmware Upgrade or DFU USB class design to download a firmware image to a USB device.