 Hello, and welcome to this presentation of the STM32 Debug Interface. It covers the debug capabilities offered by STM32L5 devices. The STM32L5 incorporates all of 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. All units involved in the debug process have memory mapped registers accessible through the private peripherals bus, or PPB, by both the core and the SWJDP. 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 BPU 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 M33 Core. The AHBAP is an AHB master that communicates with the processor core through the debug AHB slave port present in the Cortex M33. Thus the processor core and therefore the security attribution unit 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 and 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 inputs or outputs from the STM32L5 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 STM32L5 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 tables 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. There are two ROM tables in the CPU subsystem. The MCU ROM table is pointed to by the base register in the AHBAP. It contains the base address pointer for the processor ROM table and for the TPIU registers. The processor ROM table contains the base address pointer for the system control space or SCS registers that allow the debugger to identify the CPU core as well as for the BPU, DWT, ITM, ETM, and CTI. The SCS, a short for system control space, is a block of registers including the CPU ID 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 breakpoint unit or BPU, 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 DWT and CTI can be used to define trigger conditions to start and stop the ETM trace. The breakpoint unit, or BPU, allows hardware breakpoints to be set. It contains eight 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. When code resides in volatile memory, software breakpoints can be used. When a software breakpoint is used, the debugger replaces the instruction on which the user wants to stop with dedicated instruction called BKPT. 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 CTI. 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 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 BPU 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 GPR0, 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 the 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 print function can be redirected to the ITM ports to facilitate the code instrumentation. The ITM unit also issues packets containing timestamps. The ETM requires the 4-bit data trace port because the SWO does not offer enough bandwidth. In the STM32L5, the ETM is configured for instruction trace only. Unlike the ITM, no code instrumentation is needed. Taken branches and exception events are signaled by the Cortex M33 core to the ETM, which converts them into trace packets, which are output on 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 profile the code executed by the Cortex M33 and to investigate complex software bugs. The MCU debug component provides support for MCU identification, low power modes, clock control for timers, watchdog, and I-square C during a breakpoint. Control of the trace pins assignment. The DBGID code register provides the device ID and revision codes in STM32 standard format. This code is accessible by the SWJDP 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. It also allows timer values to be inspected and corresponding interrupts to be suspended until normal operation is resumed. The DBG-MCUCR register contains a control field to configure the trace port, either a synchronous SWO mode or synchronous mode, with trace data size of 1, 2, or 4. The trace and debug components allow a high degree of access to the processor and system during product development. In order to protect user code and ensure that the debug features cannot be used to alter or compromise the normal operation of the finished product, these features can be disabled or limited in scope. There are four authentication signals used by the system to determine which debug features are enabled or disabled. They are set according to the read data protection or RDP defined by an option byte. When security features are enabled and RDP level is 0.5 or 1, debug of non-secure software is supported, but debug features are not functional when the core runs in secure state. 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 and receive data on the target using UART, I2C, SPI, CAN, or GPIO. Only one of these interfaces can be active at any time. For instance, a UART of the STM32L5 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 boost strap mode is selected upon STM32L5'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 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, Mac OS, debug and bootloader interfaces support, ST-Link V3 bridges. STM32Cube Programmer supports the device firmware upgrade or DFU USB class designed to download a firmware image to a USB device.