33. Debug support (DBG)

33.1 Overview

The STM32L0x3 devices are built around a Cortex ^® -M0+ core which contains hardware extensions for advanced debugging features. The debug extensions allow the core to be stopped either on a given instruction fetch (breakpoint) or data access (watchpoint). When stopped, the core’s internal state and the system’s external state may be examined. Once examination is complete, the core and the system may be restored and program execution resumed.

The debug features are used by the debugger host when connecting to and debugging the STM32L0x3 MCUs.

One interface for debug is available:

• • Serial wire

Figure 315. Block diagram of STM32L0x3 MCU and Cortex ^® -M0+-level debug support

1. 1. The debug features embedded in the Cortex ^® -M0+ core are a subset of the Arm ^® CoreSight Design Kit.

The Arm ^® Cortex ^® -M0+ core provides integrated on-chip debug support. It is comprised of:

• • SW-DP: Serial wire
• • BPU: Break point unit
• • DWT: Data watchpoint trigger

It also includes debug features dedicated to the STM32L0x3 microcontrollers:

• • Flexible debug pinout assignment
• • MCU debug box (support for low-power modes, control over peripheral clocks, etc.)

Note: For further information on debug functionality supported by the Arm ^® Cortex ^® -M0+ core, refer to the Cortex ^® -M0+ Technical Reference Manual (see Section 33.2: Reference Arm ^® documentation ).

33.2 Reference Arm ^® documentation

• • Cortex ^® -M0+ Technical Reference Manual (TRM)
  It is available from www.infocenter.arm.com
• • Arm ^® Debug Interface V5
• • Arm ^® CoreSight Design Kit revision r1p1 Technical Reference Manual

33.3 Pinout and debug port pins

The STM32L0x3 MCUs are available in various packages with different numbers of available pins.

33.3.1 SWD port pins

Two pins are used as outputs for the SW-DP as alternate functions of general purpose I/Os. These pins are available on all packages.

Table 172. SW debug port pins

33.3.2 SW-DP pin assignment

After reset (SYSRESETn or PORESETn), the pins used for the SW-DP are assigned as dedicated pins which are immediately usable by the debugger host.

However, the MCU offers the possibility to disable the SWD port and can then release the associated pins for general-purpose I/O (GPIO) usage. For more details on how to disable SW-DP port pins, please refer to Section 9.3.2: I/O pin alternate function multiplexer and mapping on page 240 .

33.3.3 Internal pull-up & pull-down on SWD pins

Once the SW I/O is released by the user software, the GPIO controller takes control of these pins. The reset states of the GPIO control registers put the I/Os in the equivalent states:

• • SWDIO: input pull-up
• • SWCLK: input pull-down

Embedded pull-up and pull-down resistors remove the need to add external resistors.

33.4 ID codes and locking mechanism

There are several ID codes inside the MCU. ST strongly recommends the tool manufacturers to lock their debugger using the MCU device ID located at address 0x40015800.

33.4.1 MCU device ID code

The STM32L0x3 products integrate an MCU ID code. This ID identifies the ST MCU part number and the die revision.

This code is accessible by the software debug port (two pins) or by the user software.

Only the DEV_ID[15:0] should be used for identification by the debugger/programmer tools (the revision ID must not be taken into account).

For code example, refer to A.20.1: DBG read device Id code example .

DBG_IDCODE

Address: 0x4001 5800

Only 32-bit access supported. Read-only

Bits 31:16 REV_ID[15:0] : Revision identifier

This field indicates the revision of the device (see Table 173: REV_ID values ).

Bits 15:12 Reserved: read 0b0110.

Bits 11:0 DEV_ID[11:0] : Device identifier

This field indicates the device ID:

Category 3 devices: 0x417

Category 5 devices: 0x447

Table 173. REV_ID values

33.5 SWD port

33.5.1 SWD protocol introduction

This synchronous serial protocol uses two pins:

• • SWCLK: clock from host to target
• • SWDIO: bidirectional

The protocol allows two banks of registers (DPACC registers and APACC registers) to be read and written to.

Bits are transferred LSB-first on the wire.

For SWDIO bidirectional management, the line must be pulled-up on the board (100 k \( \Omega \) recommended by Arm ^® ). These pull-up resistors can be configured internally. No external pull-up resistors are required. .

Each time the direction of SWDIO changes in the protocol, a turnaround time is inserted where the line is not driven by the host nor the target. By default, this turnaround time is one bit time, however this can be adjusted by configuring the SWCLK frequency.

33.5.2 SWD protocol sequence

Each sequence consist of three phases:

1. 1. Packet request (8 bits) transmitted by the host
2. 2. Acknowledge response (3 bits) transmitted by the target
3. 3. Data transfer phase (33 bits) transmitted by the host or the target

Table 174. Packet request (8-bits)

Refer to the Cortex ^® -M0+ TRM for a detailed description of DPACC and APACC registers.

The packet request is always followed by the turnaround time (default 1 bit) where neither the host nor target drive the line.

The ACK Response must be followed by a turnaround time only if it is a READ transaction or if a WAIT or FAULT acknowledge has been received.

The DATA transfer must be followed by a turnaround time only if it is a READ transaction.

33.5.3 SW-DP state machine (reset, idle states, ID code)

The State Machine of the SW-DP has an internal ID code which identifies the SW-DP. It follows the JEP-106 standard. This ID code is the default Arm ^® one and is set to 0x0BC1 1477 (corresponding to Cortex ^® -M0+).

Note: Note that the SW-DP state machine is inactive until the target reads this ID code.

• • The SW-DP state machine is in RESET STATE either after power-on reset, or after the line is high for more than 50 cycles
• • The SW-DP state machine is in IDLE STATE if the line is low for at least two cycles after RESET state.
• • After RESET state, it is mandatory to first enter into an IDLE state AND to perform a READ access of the DP-SW ID CODE register. Otherwise, the target will issue a FAULT acknowledge response on another transactions.

Further details of the SW-DP state machine can be found in the Cortex ^® -M0+ TRM and the CoreSight Design Kit r1p0 TRM.

33.5.4 DP and AP read/write accesses

• • Read accesses to the DP are not posted: the target response can be immediate (if ACK=OK) or can be delayed (if ACK=WAIT).
• • Read accesses to the AP are posted. This means that the result of the access is returned on the next transfer. If the next access to be done is NOT an AP access, then the DP-RDBUFF register must be read to obtain the result.
  The READOK flag of the DP-CTRL/STAT register is updated on every AP read access or RDBUFF read request to know if the AP read access was successful.
• • The SW-DP implements a write buffer (for both DP or AP writes), that enables it to accept a write operation even when other transactions are still outstanding. If the write buffer is full, the target acknowledge response is “WAIT”. With the exception of IDCODE read or CTRL/STAT read or ABORT write which are accepted even if the write buffer is full.
• • Because of the asynchronous clock domains SWCLK and HCLK, two extra SWCLK cycles are needed after a write transaction (after the parity bit) to make the write effective internally. These cycles should be applied while driving the line low (IDLE state)
  This is particularly important when writing the CTRL/STAT for a power-up request. If the next transaction (requiring a power-up) occurs immediately, it will fail.

33.5.5 SW-DP registers

Access to these registers are initiated when APnDP=0

Table 177. SW-DP registers

Table 177. SW-DP registers (continued)

33.5.6 SW-AP registers

Access to these registers are initiated when APnDP=1

There are many AP Registers addressed as the combination of:

• • The shifted value A[3:2]
• • The current value of the DP SELECT register.

Table 178. 32-bit debug port registers addressed through the shifted value A[3:2]

33.6 Core debug

Core debug is accessed through the core debug registers. Debug access to these registers is by means of the debug access port. It consists of four registers:

Table 179. Core debug registers

These registers are not reset by a system reset. They are only reset by a power-on reset. Refer to the Cortex ^® -M0+ TRM for further details.

To Halt on reset, it is necessary to:

• • enable the bit0 (VC_CORRESET) of the Debug and Exception Monitor Control Register
• • enable the bit0 (C_DEBUGEN) of the Debug Halting Control and Status Register

33.7 BPU (Break Point Unit)

The Cortex ^® -M0+ BPU implementation provides four breakpoint registers. The BPU is a subset of the Flash Patch and Breakpoint (FPB) block available in Armv7-M (Cortex ^® -M3 and Cortex ^® -M4).

33.7.1 BPU functionality

The processor breakpoints implement PC based breakpoint functionality.

Refer the Armv6-M Arm ^® and the Arm ^® CoreSight Components Technical Reference Manual for more information about the BPU CoreSight identification registers, and their addresses and access types.

33.8 DWT (Data Watchpoint)

The Cortex ^® -M0+ DWT implementation provides two watchpoint register sets.

33.8.1 DWT functionality

The processor watchpoints implement both data address and PC based watchpoint functionality, a PC sampling register, and support comparator address masking, as described in the Armv6-M Arm ^® .

33.8.2 DWT Program Counter Sample Register

A processor that implements the data watchpoint unit also implements the Armv6-M optional DWT Program Counter Sample Register (DWT_PCSR). This register permits a debugger to periodically sample the PC without halting the processor. This provides coarse grained profiling. See the Armv6-M Arm ^® for more information.

The Cortex ^® -M0+ DWT_PCSR records both instructions that pass their condition codes and those that fail.

33.9 MCU debug component (DBG)

The MCU debug component helps the debugger provide support for:

• • Low-power modes
• • Clock control for timers, watchdog and I2C during a breakpoint

33.9.1 Debug support for low-power modes

To enter low-power mode, the instruction WFI or WFE must be executed.

The MCU implements several low-power modes which can either deactivate the CPU clock or reduce the power of the CPU.

The core does not allow FCLK or HCLK to be turned off during a debug session. As these are required for the debugger connection, during a debug, they must remain active. The MCU integrates special means to allow the user to debug software in low-power modes.

For this, the debugger host must first set some debug configuration registers to change the low-power mode behavior:

• • In Sleep mode: FCLK and HCLK are still active. Consequently, this mode does not impose any restrictions on the standard debug features.
• • In Stop/Standby mode, the DBG_STOP bit must be previously set by the debugger.

This enables the internal RC oscillator clock to feed FCLK and HCLK in Stop mode.

When one of the DBG_STANDBY, DBG_STOP and DBG_SLEEP bit is set and the internal reference voltage is stopped in low-power mode (ULP bit set in PWR_CR register), then the Fast wakeup must be enabled (FWU bit set in PWR_CR).

For code example, refer to A.20.2: DBG debug in LPM code example .

33.9.2 Debug support for timers, watchdog and I ² C

During a breakpoint, it is necessary to choose how the counter of timers and watchdog should behave:

• • They can continue to count inside a breakpoint. This is usually required when a PWM is controlling a motor, for example.
• • They can stop to count inside a breakpoint. This is required for watchdog purposes.

For the I ² C, the user can choose to block the SMBUS timeout during a breakpoint.

33.9.3 Debug MCU configuration register (DBG_CR)

The DBG_CR register allows to configure the low-power modes when the MCU is under debug. When one of DBG_CR bits is set, if ULP bit is set in PWR_CR, then FWU bit of PWR_CR must be set.

It is mapped at address 0x4001 5804.

This register is asynchronously reset by the PORESET (and not the system reset). It can be written by the debugger under system reset.

If the debugger host does not support these features, it is still possible for the user software to write to these registers.

Address: 0x04

Only 32-bit access supported

POR Reset: 0x0000 0000 (not reset by system reset)

Bits 31:3 Reserved, must be kept at reset value.

Bit 2 DBG_STANDBY : Debug Standby mode

0: (FCLK=Off, HCLK=Off) The whole digital part is unpowered.

From software point of view, exiting from Standby is identical than fetching reset vector (except a few status bit indicated that the MCU is resuming from Standby)

1: (FCLK=On, HCLK=On) In this case, the digital part is not unpowered and FCLK and HCLK are provided by the internal RC oscillator which remains active. In addition, the MCU generate a system reset during Standby mode so that exiting from Standby is identical than fetching from reset

Bit 1 DBG_STOP : Debug Stop mode

0: (FCLK=Off, HCLK=Off) In Stop mode, the clock controller disables all clocks (including HCLK and FCLK). When exiting from Stop mode, the clock configuration is identical to the one after RESET. Consequently, the software must reprogram the clock controller to enable the PLL, the Xtal, etc.

1: (FCLK=On, HCLK=On) In this case, when entering Stop mode, FCLK and HCLK are provided by the internal RC oscillator which remains active in Stop mode. When exiting Stop mode, the software must reprogram the clock controller to enable the PLL, the Xtal, etc. (in the same way it would do in case of DBG_STOP=0)

Bit 0 DBG_SLEEP : Debug Sleep mode

0: In Sleep mode, FCLK is clocked by the system clock previously configured by the software while HCLK is disabled. The clock controller configuration is not reset and remains in its previously programmed state. As a consequence, when exiting from Sleep mode, the software does not need to reconfigure the clock controller.

1: In this case, when entering in Sleep mode, HCLK is fed by the same clock that is provided to FCLK (system clock previously configured by the software).

33.9.4 Debug MCU APB1 freeze register (DBG_APB1_FZ)

The DBG_APB1_FZ register is used to configure the following APB peripherals, when the MCU under debug:

• • Timer clock counter freeze
• • I2C SMBUS timeout freeze
• • System window watchdog and independent watchdog counter freeze support.

This register is mapped at address 0x4001 5808.

The register is asynchronously reset by the POR (and not the system reset). It can be written by the debugger under system reset.

Address offset: 0X08

Only 32-bit access are supported.

Power on reset (POR): 0x0000 0000 (not reset by system reset)

Bit 31 DBG_LPTIMER_STOP : LPTIM1 counter stopped when core is halted

• 0: LPTIM1 counter clock is fed even if the core is halted
• 1: LPTIM1 counter clock is stopped when the core is halted

Bit 30 DBG_I2C3_STOP : I2C3 SMBUS timeout mode stopped when core is halted

• 0: Same behavior as in normal mode
• 1: I2C3 SMBUS timeout is frozen

Bits 29:22 Reserved, must be kept at reset value.

Bit 21 DBG_I2C1_STOP : I2C1 SMBUS timeout mode stopped when core is halted

• 0: Same behavior as in normal mode
• 1: I2C1 SMBUS timeout is frozen

Bits 20:13 Reserved, must be kept at reset value.

Bit 12 DBG_IWDG_STOP : Debug independent watchdog stopped when core is halted

• 0: The independent watchdog counter clock continues even if the core is halted
• 1: The independent watchdog counter clock is stopped when the core is halted

1. Bit 11 DBG_WWDG_STOP : Debug window watchdog stopped when core is halted
2. • 0: The window watchdog counter clock continues even if the core is halted
   • 1: The window watchdog counter clock is stopped when the core is halted
3. Bit 10 DBG_RTC_STOP : Debug RTC stopped when core is halted
4. • 0: The clock of the RTC counter is fed even if the core is halted
   • 1: The clock of the RTC counter is stopped when the core is halted
5. Bits 9:6 Reserved, must be kept at reset value.
6. Bit 5 DBG_TIM7_STOP : TIM7 counter stopped when core is halted
7. • 0: The counter clock of TIM7 is fed even if the core is halted
   • 1: The counter clock of TIM7 is stopped when the core is halted
8. Bit 4 DBG_TIM6_STOP : TIM6 counter stopped when core is halted
9. • 0: The counter clock of TIM6 is fed even if the core is halted
   • 1: The counter clock of TIM6 is stopped when the core is halted
10. Bits 3:2 Reserved, must be kept at reset value.
11. Bit 1 DBG_TIM3_STOP : TIM3 counter stopped when core is halted
12. • 0: The counter clock of TIM3 is fed even if the core is halted
    • 1: The counter clock of TIM3 is stopped when the core is halted
13. Bit 0 DBG_TIM2_STOP : TIM2 counter stopped when core is halted
14. • 0: The counter clock of TIM2 is fed even if the core is halted
    • 1: The counter clock of TIM2 is stopped when the core is halted

33.9.5 Debug MCU APB2 freeze register (DBG_APB2_FZ)

The DBG_APB2_FZ register is used to configure some APB peripheral features when the MCU is under DEBUG:

• • Timer clock counter freeze.

This register is mapped at address 0x4001580C.

It is asynchronously reset by the POR (and not the system reset). It can be written by the debugger under system reset.

Address: 0x0C

Only 32-bit access is supported.

POR: 0x0000 0000 (not reset by system reset)

Bits 31:6 Reserved, must be kept at reset value.

Bit 5 DBG_TIM22_STOP : TIM22 counter stopped when core is halted

0: The counter clock of TIM22 is fed even if the core is halted

1: The counter clock of TIM22 is stopped when the core is halted

Bits 4:3 Reserved, must be kept at reset value.

Bit 2 DBG_TIM21_STOP : TIM21 counter stopped when core is halted

0: The counter clock of TIM21 is fed even if the core is halted

1: The counter clock of TIM21 is stopped when the core is halted

Bits 1:0 Reserved, must be kept at reset value.

33.10 DBG register map

The following table summarizes the Debug registers.

Table 180. DBG register map and reset values

1. The reset value is product dependent. For more information, refer to Section 33.4.1: MCU device ID code .