 Hello, and welcome to this presentation of the STM32 Debug Interface. It covers the debug capabilities offered by STM32G0 devices. The STM32G0 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 core site standard, well supported by most tool providers. The debug access port, or DAP, enables an external debug probe to access any memory mapped resources, also accessible from the Cortex M0 plus core. Note that the memory protection unit, or MPU, does not intercept the requests initiated by the DAP. The Serial Wire Debug Protocol, or SWD protocol used to connect the debug probe to the Cortex M0 plus, relies on two wires, and is appropriate for the STM32G0 due to its low PIN count packages like 64, 48, 32, or even 28 PINs. The configuration for debug requires that PINs PA13 and PA14 be allocated to Serial Wire Debugging named SWDIO and SWCLOCK. STLink and most third-party debug adapters, like ULink, support Serial Wire Debug. All units involved in the debug process have memory mapped registers accessible through the private peripheral bus by both the core and the DAP. 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 breakpoint unit connected to the private peripheral bus while the processor is executing instructions. 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 DAP contains a read-only register pointing to the ROM table. This is used by some debug tools to automatically detect the topology of the core site infrastructure in the target. The SCS, short for 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. The other units are described in the following slides. 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. 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 R0, the debugger has to halt the core. However, the current value of R15, which is the program counter, is readable in a memory mapped register contained in the DWT called the PCSR. The debugger can read the PC value without halting the cortex M0 plus core. The STM32G0 supports four hardware breakpoints used by the debugger to set breakpoint in non-volatile memories. The breakpoint unit only supports address comparisons in the range of 0 to 0x1ffffff corresponding to the STM32G0's flash memory. Beyond address 0x20 million, software breakpoints can be used when the code is executed from RAM. When a software breakpoint is used, the debugger replaces the instruction on which the user wants to stop with a dedicated instruction called BKPT. The DBGMCU is located on the debug APB bus and can be accessed by the debugger via the APB access port AP2. It is also accessible by the processor in the debug APB address space. The DBGID code register provides the device ID and revision codes in STM32 standard format. This code is accessible by the software debug port 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 many 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.