Debug and trace

An external debugger can access the device using the DAP.

The DAP is a standard Arm CoreSight™ serial wire debug port (SW-DP) that implements the serial wire debug (SWD) protocol – a two-pin serial interface using SWDCLK and SWDIO pins (see Debug and trace overview).

There are several access ports that connect to different parts of the system. See the following table for more information.

The AHB-AP and APB-AP access ports are standard Arm components documented in the Arm CoreSight SoC-400 Technical Reference Manual, Revision r3p2. The CTRL-AP access port is proprietary (see CTRL-AP - Control access port).

The control access ports are always accessible from the debugger, while access to the system resources through each core's individual access ports (AHB-AP) can be protected in different ways.

The following tables give an overview of the access port protection methods.

The following tables lists the available APPROTECT combinations.

The following figure is an example on how nRF5340 with access port protection enabled can be erased, programmed, and configured to allow debugging. Operations sent from debugger as well as registers written by firmware will affect the access port state. The operation named Reset* is one of the conditions listed above.

Figure 2. Access port unlocking

The debugger can read the access port protection status in the core's AHB-AP, using the Arm AHB-AP Control/Status Word register (CSW), defined in the Arm CoreSight SoC-400 Technical Reference Manual, Revision r3p2. The DbgStatus field indicates that the AHB-AP can perform AHB transfers, while the SPIStatus field indicates if secure AHB transfers are permitted. For a list of all debug access ports, see DAP — Debug access port.

For more details on CTRLAP.ERASEALL, CTRLAP.SECUREAPPROTECT, and CTRLAP.APPROTECT, see CTRL-AP - Control access port.

Before the external debugger can use any of the access ports, the debugger must first request the device to power up via CxxxPWRUPREQ in the SWJ-DP.

As long as the debugger is requesting power via CxxxPWRUPREQ, the device will be in Debug interface mode. Otherwise, the device is in Normal mode. When a debug session is over, the external debugger must return the device back to Normal mode and perform a pin reset. This is due to the overall power consumption being higher in Debug interface mode compared to Normal mode.

Some peripherals behave differently in Debug interface mode compared to Normal mode. These differences are described in more detail in the chapters of the affected peripherals.

For details on how to use the debug capabilities, read the debug documentation of your IDE.

If the device is in System OFF when power is requested via CxxxPWRUPREQ, the device will wake up and the DIF flag in RESETREAS will be set.

The device supports real-time debugging, which allows interrupts to execute to completion in real time when breakpoints are set in Thread mode or lower priority interrupts.

Real-time debugging enables breakpoint setting and single-stepping through code without causing the failure of real-time event-driven threads running at higher priority. For example, this enables the device to continue to service the high-priority interrupts of an external controller or sensor without failure or loss of state synchronization while stepping through code in a low-priority thread.

Each ROM Table on the SoC contains a listing of the components that are connected to the debug port or AHB-AP. These listings allow an external debugger or on-chip software to discover the CoreSight devices on the SoC.

Figure 3. Application core ROM table overview

Figure 4. Network core ROM table overview

The debug system has a cross-trigger network used to simultaneously start and halt the cores in the system.

The following diagram shows an overview of the cross-trigger connections.

Figure 5. Cross-trigger network block diagram

Both the application and network cores have a cross-trigger interface (CTI) peripheral that can trigger events or be triggered by signals in the processor or debug blocks. The CTI can be configured to route trigger in-signals to trigger out-signals within the CTI or the cross-trigger matrix. The cross-trigger matrix has four channels in total that can be used to communicate trigger signals between cores.

You can stop the network core when the application core is stopped (due to a breakpoint or a stopped debug session), by doing the following:

1. Configure the application core CTI to generate an event on channel 0 for CTITRIGIN[0] (processor halted) using CTIINEN[0].
2. Configure the network core CTI to trigger CTITRIGOUT[0] (processor debug request) on channel 0 using CTIOUTEN[0].

#define CTI_TRIGIN_CPUHALTED   0
#define CTI_TRIGOUT_DEBUGREQ   0
#define CTI_TRIGOUT_CPURESTART 1
...
// Enable global CTI routing
NRF_CTI_S->CTICONTROL = CTI_CTICONTROL_GLBEN_Enabled;
// Connect the CPU halted trigger of this domain to debug request of the other domain
NRF_CTI_S->CTIINEN[CTI_TRIGIN_CPUHALTED]    = CTI_CTIINEN_TRIGINEN_0_Msk;
NRF_CTI_S->CTIOUTEN[CTI_TRIGOUT_DEBUGREQ]   = CTI_CTIOUTEN_TRIGOUTEN_1_Msk;
NRF_CTI_S->CTIOUTEN[CTI_TRIGOUT_CPURESTART] = CTI_CTIOUTEN_TRIGOUTEN_2_Msk;

#define CTI_TRIGIN_CPUHALTED   0
#define CTI_TRIGOUT_DEBUGREQ   0
#define CTI_TRIGOUT_CPURESTART 1
...
// Enable global CTI routing
NRF_CTI_NS->CTICONTROL = CTI_CTICONTROL_GLBEN_Enabled;
// Connect the CPU halted trigger of this domain to debug request of the other domain
NRF_CTI_NS->CTIINEN[CTI_TRIGIN_CPUHALTED]    = CTI_CTIINEN_TRIGINEN_1_Msk;
NRF_CTI_NS->CTIOUTEN[CTI_TRIGOUT_DEBUGREQ]   = CTI_CTIOUTEN_TRIGOUTEN_0_Msk;
NRF_CTI_NS->CTIOUTEN[CTI_TRIGOUT_CPURESTART] = CTI_CTIOUTEN_TRIGOUTEN_2_Msk;

Multidrop serial wire debug allows simultaneous access to an unlimited number of devices through a single connection. This is useful for connectivity-constrained products that contain multiple chips with multidrop support.

In order to select a target in a multidrop capable product, the debugger must write the correct TINSTANCE, TPARTNO, and TDESIGNER fields into the SW-DP TARGETSEL register. The values for these fields are located in and fetched from two registers, TARGETID and DLPIDR.

For more information about multidrop SWD, see Arm Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2.

The device supports ETM and ITM trace.

Trace data from the ETM and the ITM is sent to an external debugger via a 4-bit wide parallel trace port (TPIU), see Debug and trace overview (TRACEDATA[0] through TRACEDATA[3], and TRACECLK).

In addition to parallel trace, the TPIU supports serial trace via the serial wire output (SWO) trace protocol. Parallel and serial trace cannot be used at the same time. ETM trace is supported in Parallel trace mode only, while both parallel and Serial trace modes support the ITM trace. For details on how to use the trace capabilities, see the debug documentation of your IDE.

TPIU's dedicated trace pins are multiplexed with GPIOs. SWO and TRACEDATA[0] use the same GPIO. Trace is limited to dedicated pins. See Pin assignments for more information.

Trace speed is configured in the register TRACEPORTSPEED (Retained). The speed of the trace pins depends on the drive setting of the GPIOs that the trace pins are multiplexed with. The drive setting is configured using the DRIVE field of the GPIO register PIN_CNF[n] (n=0..31) (Retained).

Only drive settings S0S1, H0H1, and E0E1 should be used for debugging. S0S1 is the default drive at reset. If parallel or serial trace port signals are not fast enough in the debugging conditions, all GPIOs in use for tracing should be set to high drive (H0H1), or extra high drive (E0E1) for the fastest trace port speeds. Ensure that the drive setting of the GPIOs are not overwritten by software during the debugging session.

In addition to DRIVE, the GPIO pin must be assigned to trace and debug (TND), using the MCUSEL field of the the PIN_CNF register. When pins are assigned to TND, these GPIOs are output-only, and other functionality of the pins is disabled.