31. Debug support (DBG)

This section applies to the whole STM32F37xxx family, unless otherwise specified.

31.1 Overview

The STM32F37xxx built around a Cortex ^® -M4 with FPU 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 STM32F37xxx MCUs.

Two interfaces for debug are available:

• • Serial wire
• • JTAG debug port

Figure 293. Block diagram of STM32F37xxx MCU and Cortex ^® -M4 with FPU-level debug support

1. 1. The debug features embedded in the Cortex ^® -M4 with FPU core are a subset of the Arm ^® CoreSight ^™

Design Kit.

The Arm Cortex ^® -M4 with FPU core provides integrated on-chip debug support. It is comprised of:

• • SWJ-DP: Serial wire / JTAG debug port
• • AHP-AP: AHB access port
• • ITM: Instrumentation trace macrocell
• • FPB: Flash patch breakpoint
• • DWT: Data watchpoint trigger
• • TPIU: Trace port unit interface (available on larger packages, where the corresponding pins are mapped)
• • ETM: Embedded Trace Macrocell (available on larger packages, where the corresponding pins are mapped)

It also includes debug features dedicated to the STM32F37xxx:

• • 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 ^® -M4 with FPU core, refer to the Cortex ^® -M4 with FPU Technical Reference Manual and to the CoreSight ^™ Design Kit-r1p0 TRM (see Section 31.2: Reference Arm documentation ).

31.2 Reference Arm documentation

• • Cortex ^® -M4 with FPU Technical Reference Manual (TRM)
  It is available from http://infocenter.arm.com/
• • Arm Debug Interface V5
• • Arm ^® CoreSight ^™ Design Kit revision r1p1 Technical Reference Manual

31.3 SWJ debug port (serial wire and JTAG)

The STM32F37xxx core integrates the Serial Wire / JTAG Debug Port (SWJ-DP). It is an Arm standard CoreSight ^™ debug port that combines a JTAG-DP (5-pin) interface and a SW-DP (2-pin) interface.

• • The JTAG Debug Port (JTAG-DP) provides a 5-pin standard JTAG interface to the AHP-AP port.
• • The Serial Wire Debug Port (SW-DP) provides a 2-pin (clock + data) interface to the AHP-AP port.

In the SWJ-DP, the two JTAG pins of the SW-DP are multiplexed with some of the five JTAG pins of the JTAG-DP.

Figure 294. SWJ debug port

Figure 294 shows that the asynchronous TRACE output (TRACESWO) is multiplexed with TDO. This means that the asynchronous trace can only be used with SW-DP, not JTAG-DP.

31.3.1 Mechanism to select the JTAG-DP or the SW-DP

By default, the JTAG-Debug Port is active.

If the debugger host wants to switch to the SW-DP, it must provide a dedicated JTAG sequence on TMS/TCK (respectively mapped to SWDIO and SWCLK) which disables the JTAG-DP and enables the SW-DP. This way it is possible to activate the SWDP using only the SWCLK and SWDIO pins.

This sequence is:

1. 1. Send more than 50 TCK cycles with TMS (SWDIO) = 1
2. 2. Send the 16-bit sequence on TMS (SWDIO) = 0111100111100111 (MSB transmitted first)
3. 3. Send more than 50 TCK cycles with TMS (SWDIO) = 1

31.4 Pinout and debug port pins

The STM32F37xxx MCUs are available in various packages with different numbers of available pins. As a result, some functionality (ETM) related to pin availability may differ between packages.

31.4.1 SWJ debug port pins

Five pins are used as outputs from the STM32F37xxx for the SWJ-DP as alternate functions of general-purpose I/Os. These pins are available on all packages.

Table 124. SWJ debug port pins

31.4.2 Flexible SWJ-DP pin assignment

After RESET (SYSRESETn or PORESETn), all five pins used for the SWJ-DP are assigned as dedicated pins immediately usable by the debugger host (note that the trace outputs are not assigned except if explicitly programmed by the debugger host).

However, the STM32F37xxx MCU offers the possibility of disabling some or all of the SWJ-DP ports and so, of releasing (in gray in the table below) the associated pins for general-purpose I/O (GPIO) usage. For more details on how to disable SWJ-DP port pins, please refer to Section 8.3.2: I/O pin alternate function multiplexer and mapping .

Table 125. Flexible SWJ-DP pin assignment

31.4.3 Internal pull-up and pull-down on JTAG pins

It is necessary to ensure that the JTAG input pins are not floating since they are directly connected to flip-flops to control the debug mode features. Special care must be taken with the SWCLK/TCK pin, which is directly connected to the clock of some of these flip-flops.

To avoid any uncontrolled I/O levels, the device embeds internal pull-ups and pull-downs on the JTAG input pins:

• • NJTRST: Internal pull-up
• • JTDI: Internal pull-up
• • JTMS/SWDIO: Internal pull-up
• • TCK/SWCLK: Internal pull-down

Once a JTAG I/O is released by the user software, the GPIO controller takes control again. The reset states of the GPIO control registers put the I/Os in the equivalent state:

• • NJTRST: Input pull-up
• • JTDI: Input pull-up
• • JTMS/SWDIO: Input pull-up
• • JTCK/SWCLK: Input pull-down
• • JTDO: Input floating

The software can then use these I/Os as standard GPIOs.

Note: The JTAG IEEE standard recommends adding pull-ups on TDI, TMS, and nTRST but there is no special recommendation for TCK. However, for JTCK, the device needs an integrated pull-down.

Having embedded pull-ups and pull-downs removes the need to add external resistors.

31.4.4 Using serial wire and releasing the unused debug pins as GPIOs

To use the serial wire DP to release some GPIOs, the user software must change the GPIO (PA15, PB3 and PB4) configuration mode in the GPIO_MODER register. This releases PA15, PB3, and PB4 which now become available as GPIOs.

When debugging, the host performs the following actions:

• • Under system reset, all SWJ pins are assigned (JTAG-DP + SW-DP).
• • Under system reset, the debugger host sends the JTAG sequence to switch from the JTAG-DP to the SW-DP.
• • Still under system reset, the debugger sets a breakpoint on vector reset.
• • The system reset is released and the Core halts.
• • All the debug communications from this point are done using the SW-DP. The other JTAG pins can then be reassigned as GPIOs by the user software.

Note: For user software designs, note that:

To release the debug pins, remember that they will be first configured either in input-pull-up (nTRST, TMS, TDI) or pull-down (TCK) or output tri-state (TDO) for a certain duration after reset until the instant when the user software releases the pins.

When debug pins (JTAG or SW or TRACE) are mapped, changing the corresponding I/O pin configuration in the IOPORT controller has no effect.

31.5 STM32F37xxx JTAG TAP connection

The STM32F37xxx MCUs integrate two serially connected JTAG TAPs, the boundary scan TAP (IR is 5-bit wide) and the Cortex®-M4 with FPU TAP (IR is 4-bit wide).

To access the TAP of the Cortex®-M4 with FPU for debug purposes:

1. 1. First, it is necessary to shift the BYPASS instruction of the boundary scan TAP.
2. 2. Then, for each IR shift, the scan chain contains 9 bits (=5+4) and the unused TAP instruction must be shifted in using the BYPASS instruction.
3. 3. For each data shift, the unused TAP, which is in BYPASS mode, adds 1 extra data bit in the data scan chain.

Note: Important: Once Serial-Wire is selected using the dedicated Arm JTAG sequence, the boundary scan TAP is automatically disabled (JTMS forced high).

Figure 295. JTAG TAP connections

31.6 ID codes and locking mechanism

There are several ID codes inside the STM32F37xxx MCUs. STMicroelectronics strongly recommends tool designers to lock their debuggers using the MCU DEVICE ID code located in the external PPB memory map at address 0xE0042000.

31.6.1 MCU device ID code

The STM32F37xxx MCUs integrate an MCU ID code. This ID identifies the STMicroelectronics MCU part-number and the die revision. It is part of the DBG_MCU component and is mapped on the external PPB bus (see Section 31.16 on page 880 ). This code is accessible using the JTAG debug port (4 to 5 pins) or the SW debug port (two pins) or by the user software. It is even accessible while the MCU is under system reset.

Only the DEV_ID(11:0) should be used for identification by the debugger/programmer tools.

DBGMCU_IDCODE

Address: 0xE004 2000

Only 32-bits access is supported. Read-only

This code is read as 0xE004 2000 for Revision 1.0

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

This field indicates the revision of the device.

0x1000: Revision A

0x2000 for revision B

...

Bits 15:12 Reserved, must be kept at reset value.

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

This field indicates the device and its revision.

The device ID is 0x432.

31.6.2 Boundary scan TAP

JTAG ID code

The TAP of the STM32F37xxx BSC (boundary scan) integrates a JTAG ID code equal to 0x06432041 0x4BA00477.

31.6.3 Cortex ^® -M4 with FPU TAP

The TAP of the Arm Cortex ^® -M4 with FPU integrates a JTAG ID code. This ID code is the Arm default one and has not been modified. This code is only accessible by the JTAG Debug Port.

This code is 0x4BA00477 (corresponds to Cortex ^® -M4 with FPU, see Section 31.2: Reference Arm documentation ).

31.6.4 Cortex ^® -M4 with FPU JEDEC-106 ID code

The Arm Cortex ^® -M4 with FPU integrates a JEDEC-106 ID code. It is located in the 4KB ROM table mapped on the internal PPB bus at address 0xE00FF000_0xE00FFFFF.

This code is accessible by the JTAG Debug Port (4 to 5 pins) or by the SW Debug Port (two pins) or by the user software.

31.7 JTAG debug port

A standard JTAG state machine is implemented with a 4-bit instruction register (IR) and five data registers (for full details, refer to the Cortex ^® -M4 with FPU Technical Reference Manual (TRM) , for references, please see Section 31.2: Reference Arm documentation ).

Table 126. JTAG debug port data registers

31.8 SW debug port

31.8.1 SW 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).

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.

31.8.2 SW protocol sequence

Each sequence consists of three phases:

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

Table 128. Packet request (8-bits)

Refer to the Cortex ^® -M4 with FPU 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.

Table 129. ACK response (3 bits)

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.

Table 130. DATA transfer (33 bits)

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

31.8.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 0x1BA01477 (corresponding to Cortex®-M4 with FPU).

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 DP has switched from JTAG to SWD 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®-M4 with FPU TRM and the CoreSight™ Design Kit r1p0 TRM.

31.8.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”. Except for 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.

31.8.5 SW-DP registers

Access to these registers are initiated when APnDP=0

Table 131. SW-DP registers

31.8.6 SW-AP registers

Access to these registers are initiated when APnDP=1

There are many AP Registers (see AHB-AP) addressed as the combination of:

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

31.9 AHB-AP (AHB access port) - valid for both JTAG-DP and SW-DP

Features:

• • System access is independent of the processor status.
• • Either SW-DP or JTAG-DP accesses AHB-AP.
• • The AHB-AP is an AHB master into the Bus Matrix. Consequently, it can access all the data buses (Dcode Bus, System Bus, internal and external PPB bus) but the ICode bus.
• • Bitband transactions are supported.
• • AHB-AP transactions bypass the FPB.

The address of the 32-bits AHP-AP registers are 6-bits wide (up to 64 words or 256 bytes) and consists of:

• d) Bits [7:4] = the bits [7:4] APBANKSEL of the DP SELECT register
• e) Bits [3:2] = the 2 address bits of A(3:2) of the 35-bit packet request for SW-DP.

The AHB-AP of the Cortex ^® -M4 with FPU includes 9 x 32-bits registers:

Table 132. Cortex ^® -M4 with FPU AHB-AP registers

Refer to the Cortex ^® -M4 with FPU TRM for further details.

31.10 Core debug

Core debug is accessed through the core debug registers. Debug access to these registers is by means of the Advanced High-performance Bus (AHB-AP) port. The processor can access these registers directly over the internal Private Peripheral Bus (PPB). It consists of 4 registers:

Table 133. 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 ^® -M4 with FPU 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.

31.11 Capability of the debugger host to connect under system reset

The STM32F37xxx MCUs' reset system comprises the following reset sources:

• • POR (power-on reset) which asserts a RESET at each power-up.
• • Internal watchdog reset
• • Software reset
• • External reset

The Cortex ^® -M4 with FPU differentiates the reset of the debug part (generally PORRESETn) and the other one (SYSRESETn).

This way, it is possible for the debugger to connect under System Reset, programming the Core Debug Registers to halt the core when fetching the reset vector. Then the host can release the system reset and the core will immediately halt without having executed any instructions. In addition, it is possible to program any debug features under System Reset.

Note: It is highly recommended for the debugger host to connect (set a breakpoint in the reset vector) under system reset.

31.12 FPB (Flash patch breakpoint)

The FPB unit:

• • implements hardware breakpoints
• • patches code and data from code space to system space. This feature gives the possibility to correct software bugs located in the Code Memory Space.

The use of a Software Patch or a Hardware Breakpoint is exclusive.

The FPB consists of:

• • 2 literal comparators for matching against literal loads from Code Space and remapping to a corresponding area in the System Space.
• • 6 instruction comparators for matching against instruction fetches from Code Space. They can be used either to remap to a corresponding area in the System Space or to generate a Breakpoint Instruction to the core.

31.13 DWT (data watchpoint trigger)

The DWT unit consists of four comparators. They are configurable as:

• • a hardware watchpoint or
• • a trigger to an ETM or
• • a PC sampler or
• • a data address sampler

The DWT also provides some means to give some profiling information. For this, some counters are accessible to give the number of:

• • Clock cycle
• • Folded instructions
• • Load store unit (LSU) operations
• • Sleep cycles
• • CPI (clock per instructions)
• • Interrupt overhead

31.14 ITM (instrumentation trace macrocell)

31.14.1 General description

The ITM is an application-driven trace source that supports printf style debugging to trace Operating System (OS) and application events, and emits diagnostic system information. The ITM emits trace information as packets, which can be generated as:

• • Software trace. Software can write directly to the ITM stimulus registers to emit packets.
• • Hardware trace. The DWT generates these packets, and the ITM emits them.
• • Time stamping. Timestamps are emitted relative to packets. The ITM contains a 21-bit counter to generate the timestamp. The Cortex ^® -M4 with FPU clock or the bit clock rate of the Serial Wire Viewer (SWV) output clocks the counter.

The packets emitted by the ITM are output to the TPIU (Trace Port Interface Unit). The formatter of the TPIU adds some extra packets (refer to TPIU) and then output the complete packets sequence to the debugger host.

The bit TRCEN of the Debug Exception and Monitor Control Register must be enabled before you program or use the ITM.

31.14.2 Time stamp packets, synchronization, and overflow packets

Time stamp packets encode time stamp information, generic control, and synchronization. It uses a 21-bit timestamp counter (with possible prescalers) which is reset at each time stamp packet emission. This counter can be either clocked by the CPU clock or the SWV clock.

A synchronization packet consists of 6 bytes equal to 0x80_00_00_00_00_00 which is emitted to the TPIU as 00 00 00 00 00 80 (LSB emitted first).

A synchronization packet is a timestamp packet control. It is emitted at each DWT trigger.

For this, the DWT must be configured to trigger the ITM: the bit CYCCNTENA (bit0) of the DWT Control Register must be set. In addition, the bit2 (SYNCENA) of the ITM Trace Control Register must be set.

Note: If the SYNENA bit is not set, the DWT generates Synchronization triggers to the TPIU, which will send only TPIU synchronization packets and not ITM synchronization packets.

An overflow packet consists is a special timestamp packet which indicates that data has been written but the FIFO was full.

Table 134. Main ITM registers

Table 134. Main ITM registers (continued)

Example of configuration

To output a simple value to the TPIU:

• Configure the TPIU and assign TRACE I/Os by configuring the DBGMCU_CR (refer to Section 31.17.2: TRACE pin assignment and Section 31.16.3: Debug MCU configuration register )
• Write 0xC5ACCE55 to the ITM Lock Access Register to unlock the write access to the ITM registers
• Write 0x00010005 to the ITM Trace Control Register to enable the ITM with Sync enabled and an ATB ID different from 0x00
• Write 0x1 to the ITM Trace Enable Register to enable the Stimulus Port 0
• Write 0x1 to the ITM Trace Privilege Register to unmask stimulus ports 7:0
• Write the value to the output in the Stimulus Port Register 0: this can be done by software (using a printf function)

31.15 ETM (Embedded trace macrocell)

31.15.1 General description

The ETM enables the reconstruction of program execution. Data are traced using the Data Watchpoint and Trace (DWT) component or the Instruction Trace Macrocell (ITM) whereas instructions are traced using the Embedded Trace Macrocell (ETM).

The ETM transmits information as packets and is triggered by embedded resources. These resources must be programmed independently and the trigger source is selected using the Trigger Event Register (0xE0041008). An event could be a simple event (address match from an address comparator) or a logic equation between 2 events. The trigger source is one of the fourth comparators of the DWT module. The following events can be monitored:

• Clock cycle matching
• Data address matching

For more information on the trigger resources, refer to Section 31.13: DWT (data watchpoint trigger) .

The packets transmitted by the ETM are output to the TPIU (Trace Port Interface Unit). The formatter of the TPIU adds some extra packets (refer to Section 31.17: TPIU (trace port interface unit) ) and then outputs the complete packet sequence to the debugger host.

31.15.2 Signal protocol, packet types

This part is described in the chapter 7 ETMv3 Signal Protocol of the Arm IHI 0014N document.

31.15.3 Main ETM registers

For more information on registers, refer to the chapter 3 of the Arm IHI 0014N specification.

Table 135. Main ETM registers

31.15.4 Configuration example

To output a simple value to the TPIU:

• • Configure the TPIU and enable the I/IO_TRACEN to assign TRACE I/Os in the STM32F37xxx debug configuration register.
• • Write 0xC5ACCE55 to the ETM Lock Access Register to unlock the write access to the ITM registers
• • Write 0x00001D1E to the control register (configure the trace)
• • Write 0000406F to the Trigger Event register (define the trigger event)
• • Write 0000006F to the Trace Enable Event register (define an event to start/stop)
• • Write 00000001 to the Trace Start/stop register (enable the trace)
• • Write 0000191E to the ETM Control Register (end of configuration)

31.16 MCU debug component (DBGMCU)

The MCU debug component helps the debugger provide support for:

• • Low-power modes.
• • Clock control for timers, watchdog, I2C, and bxCAN during a breakpoint.
• • Control of the trace pins assignment.

31.16.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, the DBG_SLEEP bit of DBGMCU_CR register must be previously set by the debugger. This will feed HCLK with the same clock that is provided to FCLK (system clock previously configured by the software).
• • In Stop mode, the bit DBG_STOP must be previously set by the debugger. This will enable the internal RC oscillator clock to feed FCLK and HCLK in STOP mode.

Note: When the device is in Debug Stop or Debug Sleep mode (configured through DBG_STOP or DBG_SLEEP bits in the DBGMCU_CR registers), the Systick timer is always running and cannot be frozen. As a consequence, different Systick timer values are observed if the application code is running with and without debugger.

31.16.2 Debug support for timers, watchdog, bxCAN 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 bxCAN, the user can choose to block the update of the receive register during a breakpoint.

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

31.16.3 Debug MCU configuration register

This register allows the configuration of the MCU under DEBUG. This concerns:

• • Low-power mode support
• • Timer and watchdog counter support
• • bxCAN communication support
• • Trace pin assignment

This DBGMCU_CR is mapped on the External PPB bus at address 0xE0042004.

It 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.

DBGMCU_CR

Address: 0xE004 2004

Only 32-bit access supported

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

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

Bits 7:5 TRACE_MODE[1:0] and TRACE_IOEN : Trace pin assignment control

– With TRACE_IOEN=0:

TRACE_MODE=xx: TRACE pins not assigned (default state)

– With TRACE_IOEN=1:

• – TRACE_MODE=00: TRACE pin assignment for Asynchronous Mode
• – TRACE_MODE=01: TRACE pin assignment for Synchronous Mode with a TRACEDATA size of 1
• – TRACE_MODE=10: TRACE pin assignment for Synchronous Mode with a TRACEDATA size of 2
• – TRACE_MODE=11: TRACE pin assignment for Synchronous Mode with a TRACEDATA size of 4

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

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

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 (CPU clocked by the 8 MHz internal RC oscillator (HSI)). 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)

0: (FCLK=On, HCLK=Off) In Sleep mode, FCLK is clocked by the system clock as previously configured by the software while HCLK is disabled.

In Sleep mode, the clock controller configuration is not reset and remains in the previously programmed state. Consequently, when exiting from Sleep mode, the software does not need to reconfigure the clock controller.

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

31.16.4 Debug MCU APB1 freeze register (DBGMCU_APB1_FZ)

The DBGMCU_APB1_FZ register is used to configure the MCU under DEBUG. It concerns the APB1 peripherals:

• • Timer clock counter freeze
• • I2C SMBUS timeout freeze
• • Window watchdog and independent watchdog counter freeze support

This DBGMCU_APB1_FZ is mapped on the external PPB bus at address 0xE0042008.

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

Address: 0xE004 2008

Only 32-bit access are supported.

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

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

Bit 25 DBG_CAN_STOP : CAN stopped when core is halted

• 0: Same behavior as in normal mode
• 1: The CAN receive registers are frozen

Bits 24:23 Reserved, must be kept at reset value.

Bit 22 DBG_I2C2_SMBUS_TIMEOUT : SMBUS timeout mode stopped when core is halted

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

Bit 21 DBG_I2C1_SMBUS_TIMEOUT : SMBUS timeout mode stopped when core is halted

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

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

Bit 12 DBG_IWDG_STOP : 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

Bit 11 DBG_WWDG_STOP : Window watchdog stopped when core is halted

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

Bit 10 DBG_RTC_STOP : RTC stopped when core is halted

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

Note: This bit is available only in high density devices.

Bit 9 DBG_TIM18_STOP : TIM18 counter stopped when core is halted

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

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

Bit 8 DBG_TIM14_STOP : TIM14 counter stopped when core is halted

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

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

Bit 7 DBG_TIM13_STOP : TIM13 counter stopped when core is halted

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

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

Bit 6 DBG_TIM12_STOP : TIM12 counter stopped when core is halted

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

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

Bit 5 DBG_TIM7_STOP : TIM7 counter stopped when core is halted

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

Bit 4 DBG_TIM6_STOP : TIM6 counter stopped when core is halted

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

Bit 3 DBG_TIM5_STOP : TIM5 counter stopped when core is halted

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

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

Bit 2 DBG_TIM4_STOP : TIM4 counter stopped when core is halted

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

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

Bit 1 DBG_TIM3_STOP : TIM3 counter stopped when core is halted

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

Bit 0 DBG_TIM2_STOP : TIM2 counter stopped when core is halted

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

31.16.5 Debug MCU APB2 freeze register (DBGMCU_APB2_FZ)

The DBGMCU_APB2_FZ register is used to configure the MCU under DEBUG. It concerns APB2 peripherals:

• • Timer clock counter freeze

This register is mapped on the external PPB bus at address 0xE004 200C

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

Address: 0xE004 200C

Only 32-bit access is supported.

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

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

Bits 5:2 DBG_TIMx_STOP : TIMx counter stopped when core is halted (x=15..19)

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

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

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

31.17 TPIU (trace port interface unit)

31.17.1 Introduction

The TPIU acts as a bridge between the on-chip trace data from the ITM and the ETM.

The output data stream encapsulates the trace source ID, that is then captured by a trace port analyzer (TPA).

The core embeds a simple TPIU, especially designed for low-cost debug (consisting of a special version of the CoreSight™ TPIU).

Figure 296. TPIU block diagram

31.17.2 TRACE pin assignment

• Asynchronous mode
  The asynchronous mode requires 1 extra pin and is available on all packages. It is only available if using Serial Wire mode (not in JTAG mode).

Table 136. Asynchronous TRACE pin assignment

• Synchronous mode
  The synchronous mode requires from 2 to 6 extra pins depending on the data trace size and is only available in the larger packages. In addition it is available in JTAG mode and in Serial Wire mode and provides better bandwidth output capabilities than asynchronous trace.

Table 137. Synchronous TRACE pin assignment

TPUI TRACE pin assignment

By default, these pins are NOT assigned. They can be assigned by setting the TRACE_IOEN and TRACE_MODE bits in the MCU Debug component configuration register . This configuration has to be done by the debugger host.

In addition, the number of pins to assign depends on the trace configuration (asynchronous or synchronous).

• • Asynchronous mode: 1 extra pin is needed
• • Synchronous mode: from 2 to 5 extra pins are needed depending on the size of the data trace port register (1, 2 or 4):
  • – TRACECK
  • – TRACED(0) if port size is configured to 1, 2 or 4
  • – TRACED(1) if port size is configured to 2 or 4
  • – TRACED(2) if port size is configured to 4
  • – TRACED(3) if port size is configured to 4

To assign the TRACE pin, the debugger host must program the bits TRACE_IOEN and TRACE_MODE[1:0] of the Debug MCU configuration Register (DBGMCU_CR). By default the TRACE pins are not assigned.

This register is mapped on the external PPB and is reset by the PORESET (and not by the SYSTEM reset). It can be written by the debugger under SYSTEM reset.

Table 138. Flexible TRACE pin assignment

1. When Serial Wire mode is used, it is released. But when JTAG is used, it is assigned to JTDO.

Note: By default, the TRACECLKIN input clock of the TPIU is tied to GND. It is assigned to HCLK two clock cycles after the bit TRACE_IOEN has been set.

The debugger must then program the Trace Mode by writing the PROTOCOL[1:0] bits in the SPP_R (Selected Pin Protocol) register of the TPIU.

• • PROTOCOL=00: Trace Port Mode (synchronous)
• • PROTOCOL=01 or 10: Serial Wire (Manchester or NRZ) Mode (asynchronous mode). Default state is 01

It then also configures the TRACE port size by writing the bits [3:0] in the CPSPS_R (Current Sync Port Size Register) of the TPIU:

• • 0x1 for 1 pin (default state)
• • 0x2 for 2 pins
• • 0x8 for 4 pins

31.17.3 TPU formatter

The formatter protocol outputs data in 16-byte frames:

• • seven bytes of data
• • eight bytes of mixed-use bytes consisting of:
  • – 1 bit (LSB) to indicate it is a DATA byte ('0) or an ID byte ('1).
  • – 7 bits (MSB) which can be data or change of source ID trace.
• • one byte of auxiliary bits where each bit corresponds to one of the eight mixed-use bytes:
  • – if the corresponding byte was a data, this bit gives bit0 of the data.
  • – if the corresponding byte was an ID change, this bit indicates when that ID change takes effect.

Note: Refer to the Arm® CoreSight™ Architecture Specification v1.0 (Arm IHI 0029B) for further information.

31.17.4 TPU frame synchronization packets

The TPU can generate two types of synchronization packets:

• • The Frame Synchronization packet (or Full Word Synchronization packet)
  It consists of the word: 0x7F_FF_FF_FF (LSB emitted first). This sequence cannot occur at any other time provided that the ID source code 0x7F has not been used.
  It is output periodically between frames.
  In continuous mode, the TPA must discard all these frames once a synchronization frame has been found.
• • The Half-Word Synchronization packet
  It consists of the half word: 0x7F_FF (LSB emitted first).
  It is output periodically between or within frames.
  These packets are only generated in continuous mode and enable the TPA to detect that the TRACE port is in IDLE mode (no TRACE to be captured). When detected by the TPA, it must be discarded.

31.17.5 Transmission of the synchronization frame packet

There is no Synchronization Counter register implemented in the TPIU of the core. Consequently, the synchronization trigger can only be generated by the DWT . Refer to the

registers DWT Control Register (bits SYNTAP[11:10]) and the DWT Current PC Sampler Cycle Count Register.

The TPUI Frame synchronization packet (0x7F_FF_FF_FF) is emitted:

• • after each TPIU reset release. This reset is synchronously released with the rising edge of the TRACECLKIN clock. This means that this packet is transmitted when the TRACE_IOEN bit in the DBGMCU_CFG register is set. In this case, the word 0x7F_FF_FF_FF is not followed by any formatted packet.
• • at each DWT trigger (assuming DWT has been previously configured). Two cases occur:
  • – If the bit SYNENA of the ITM is reset, only the word 0x7F_FF_FF_FF is emitted without any formatted stream, which follows.
  • – If the bit SYNENA of the ITM is set, then the ITM synchronization packets will follow (0x80_00_00_00_00_00), formatted by the TPUI (trace source ID added).

31.17.6 Synchronous mode

The trace data output size can be configured to 4, 2 or 1 pin: TRACED(3:0)

The output clock is output to the debugger (TRACECK)

Here, TRACECLKIN is driven internally and is connected to HCLK only when TRACE is used.

Note: In this synchronous mode, it is not required to provide a stable clock frequency.

The TRACE I/Os (including TRACECK) are driven by the rising edge of TRACECLKIN (equal to HCLK). Consequently, the output frequency of TRACECK is equal to HCLK/2.

31.17.7 Asynchronous mode

This is a low cost alternative to output the trace using only 1 pin: this is the asynchronous output pin TRACESWO. Obviously there is a limited bandwidth.

TRACESWO is multiplexed with JTDO when using the SW-DP pin. This way, this functionality is available in all STM32F37xxx packages.

This asynchronous mode requires a constant frequency for TRACECLKIN. For the standard UART (NRZ) capture mechanism, 5% accuracy is needed. The Manchester encoded version is tolerant up to 10%.

31.17.8 TRACECLKIN connection inside the STM32F37xxx

In the STM32F37xxx, this TRACECLKIN input is internally connected to HCLK. This means that when in asynchronous trace mode, the application is restricted to use to time frames where the CPU frequency is stable.

Note: Important: when using asynchronous trace: it is important to be aware that:

The default clock of the STM32F37xxx MCUs is the internal RC oscillator. Its frequency under reset is different from the one after reset release. This is because the RC calibration is the default one under system reset and is updated at each system reset release.

Consequently, the trace port analyzer (TPA) should not enable the trace (with the TRACE_IOEN bit) under system reset, because a Synchronization Frame Packet will be issued with a different bit time than trace packets, which will be transmitted after reset release.

31.17.9 TPIU registers

The TPIU APB registers can be read and written only if the bit TRCENA of the Debug Exception and Monitor Control Register (DEMCR) is set. Otherwise, the registers are read as zero (the output of this bit enables the PCLK of the TPIU).

Table 139. Important TPIU registers

31.17.10 Example of configuration

• • Set the bit TRCENA in the Debug Exception and Monitor Control Register (DEMCR)
• • Write the TPIU Current Port Size Register to the desired value (default is 0x1 for a 1-bit port size)
• • Write TPIU Formatter and Flush Control Register to 0x102 (default value)
• • Write the TPIU Select Pin Protocol to select the sync or async mode. Example: 0x2 for async NRZ mode (UART like)
• • Write the DBGMCU control register to 0x20 (bit IO_TRACEN) to assign TRACE I/Os for async mode. A TPIU Sync packet is emitted at this time (FF_FF_FF_7F)
• • Configure the ITM and write the ITM Stimulus register to output a value

31.18 DBG register map

The following table summarizes the Debug registers.

Table 140. DBG register map and reset values

Table 140. DBG register map and reset values (continued)

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