Debug and trace

The debug and trace system offers a flexible and powerful mechanism for non-intrusive debugging.

Figure 1. Debug and trace overview Debug and trace overview
The main features of the debug and trace system are:
  • Access port connection to application core ARM® Cortex®-M33
    • Eight breakpoints
    • Four watchpoint comparators
    • Instrumentation trace macrocell (ITM)
    • Embedded trace macrocell (ETM)
    • Access protection through APPROTECT, ERASEPROTECT and SECUREAPPROTECT
  • Access port connection to network core ARM® Cortex®-M33, with:
    • Eight breakpoints
    • Four watchpoints
    • Access protection through APPROTECT and ERASEPROTECT
  • Serial wire debug (SWD) interface protocol version 2 with multidrop support
  • Trace port interface unit (TPIU), with:
    • 4-bit parallel trace of ITM and ETM trace data
    • Serial wire output (SWO) trace of ITM data

DAP — Debug access port

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

Note:
  • The SWDIO line has an internal pull-up resistor.
  • The SWDCLK line has an internal pull-down resistor.

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

Table 1. Access port overview
AP ID Type Description
0 AHB-AP Application subsystem access port
1 AHB-AP Network subsystem access port
2 CTRL-AP Application subsystem control access port
3 CTRL-AP Network subsystem control access port

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

Registers

Table 2. Register overview
Register Offset Security Description
TARGETID 0x042  

The TARGETID register provides information about the target when the host is connected to a single device.

The TARGETID register is accessed by a read of DP register 0x4 when the DPBANKSEL bit in the SELECT register is set to 0x2.

 
DLPIDR 0x043  

The DLPIDR register provides information about the serial wire debug protocol version.

Accessed by a read of DP register 0x4 when the DPBANKSEL bit in the SELECT register is set to 0x3.

 

TARGETID

Address offset: 0x042

The TARGETID register provides information about the target when the host is connected to a single device.

The TARGETID register is accessed by a read of DP register 0x4 when the DPBANKSEL bit in the SELECT register is set to 0x2.

Bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ID

C

C

C

C

B

B

B

B

B

B

B

B

B

B

B

B

       

A

A

A

A

A

A

A

A

A

A

A

 
Reset 0x30070289 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 1
ID R/W Field Value ID Value Description
A R

TDESIGNER

   

An 11-bit code JEDEC JEP106 continuation code and identity code. The ID identifies the designer of the part.

     

NordicSemi

0x144

Nordic Semiconductor ASA.

B R

TPARTNO

   

Part number.

     

nRF53

7

nRF53 Series.

C R

TREVISION

   

Target revision.

     

nRF5340LS

2

nRF5340 limited sampling.

     

nRF5340

3

nRF5340.

DLPIDR

Address offset: 0x043

The DLPIDR register provides information about the serial wire debug protocol version.

Accessed by a read of DP register 0x4 when the DPBANKSEL bit in the SELECT register is set to 0x3.

Bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ID

B

B

B

B

                                               

A

A

A

A

Reset 0x00000001 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
ID R/W Field Value ID Value Description
A R

PROTVSN

   

Protocol version.

     

SWDPv2

1

SW protocol version 2.

B R

TINSTANCE

   

Target instance.

This value is set by the UICR.TINSTANCE register.

Electrical specification

SW-DP

Symbol Description Min. Typ. Max. Units
Rpull

Internal SWDIO and SWDCLK pull up/down resistance

.. .. ..
fSWDCLK

SWDCLK frequency

.. .. .. MHz

Trace port

Symbol Description Min. Typ. Max. Units
Tcyc

Clock period, as defined by ARM in Embedded Trace Macrocell Architecture Specification (see Timing specifications in Trace Port Physical Interface section)

.. .. .. ns

Access port protection

Debugger transactions through an access port can be protected in different ways.

The following table gives an overview of the access port protection schemes.

Table 3. Access port protection overview
Register Description
Application UICR.APPROTECT Blocks all access through the application AHB-AP. This can be used to provide read-back protection of the application. Note that the network core may be able to access non-secure memory of the application core as defined in SPU — System protection unit. This can be prevented by using the network core's APPROTECT register.
Application UICR.SECUREAPPROTECT Blocks all secure transfers through the application AHB-AP. This means that only the non-secure code can be debugged and accessed.
Application UICR.ERASEPROTECT Disables the application core CTRL-AP.ERASEALL and NVMC ERASEALL functionality. This can be used together with APPROTECT to provide read-back and re-purposing protection.
Network UICR.APPROTECT Blocks all access through the network AHB-AP.
Network UICR.ERASEPROTECT Disables the network core CTRL-AP.ERASEALL and NVMC ERASEALL functionality. This can be used together with APPROTECT to provide read-back and re-purposing protection.

Debug Interface mode

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 because the overall power consumption is 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 system will wake up and the DIF flag in RESETREAS will be set.

Real-time debug

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 the developer to set a breakpoint and single-step through in their 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 the developer steps through code in a low-priority thread.

ROM tables

Figure 2. Application core ROM table overview
Application core ROM table overview
Table 4. Application core ROM table entries
Address Component Value
0xE00FEFFC CIDR3 0x000000B1
0xE00FEFF8 CIDR2 0x00000005
0xE00FEFF4 CIDR1 0x00000010
0xE00FEFF0 CIDR0 0x0000000D
0xE00FEFDC PIDR7 0x00000000
0xE00FEFD8 PIDR6 0x00000000
0xE00FEFD4 PIDR5 0x00000000
0xE00FEFD0 PIDR4 0x00000002
0xE00FEFEC PIDR3 0x00000000
0xE00FEFE8 PIDR2
  1. 0x0000002C nRF5340 limited sampling
  2. 0x0000003C nRF5340
0xE00FEFE4 PIDR1 0x00000040
0xE00FEFE0 PIDR0 0x00000007
0xE00FEFCC MEMTYPE 0x00000001
0xE00FE004 TPIU 0xFFF42003
0xE00FE000 ROM table 0x00001003
Table 5. Application ARM® Cortex®-M33 ROM table entries
Address Component Value
0xE00FF01C MTB (not implemented) 0xFFF44002
0xE00FF018 CTI 0xFFF43003
0xE00FF014 ETM 0xFFF42003
0xE00FF00C ITM 0xFFF01003
0xE00FF008 BPU 0xFFF03003
0xE00FF004 DWT 0xFFF02003
0xE00FF000 SCS 0xFFF0F003
Figure 3. Network core ROM table overview
Network core ROM table overview
Table 6. Network core ROM table entries
Address Component Value
0xE00FEFFC CIDR3 0x000000B1
0xE00FEFF8 CIDR2 0x00000005
0xE00FEFF4 CIDR1 0x00000010
0xE00FEFF0 CIDR0 0x0000000D
0xE00FEFDC PIDR7 0x00000000
0xE00FEFD8 PIDR6 0x00000000
0xE00FEFD4 PIDR5 0x00000000
0xE00FEFD0 PIDR4 0x00000002
0xE00FEFEC PIDR3 0x00000000
0xE00FEFE8 PIDR2
  1. 0x0000002C - nRF5340 limited sampling
  2. 0x0000003C - nRF5340
0xE00FEFE4 PIDR1 0x00000040
0xE00FEFE0 PIDR0 0x00000007
0xE00FEFCC MEMTYPE 0x00000001
0xE00FE000 ROM table 0x00001003
Table 7. Network ARM® Cortex®-M33 ROM table entries
Address Component Value
0xE00FF01C MTB (not implemented) 0xFFF44002
0xE00FF018 CTI 0xFFF43003
0xE00FF014 ETM (not implemented) 0xFFF42002
0xE00FF00C ITM (not implemented) 0xFFF01002
0xE00FF008 BPU 0xFFF03003
0xE00FF004 DWT 0xFFF02003
0xE00FF000 SCS 0xFFF0F003

Cross-trigger network

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 4. Cross-trigger network block diagram
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].

Configuring the cross-trigger interface

In this example, the following CTI channels are used:
  • Channel 0 is used to relay debug requests from the application to the network domain.
  • Channel 1 is used to relay debug requests from the network to the application domain.
  • Channel 2 is used by the debugger to send a common trigger for restarting both domains after a breakpoint.

For the application core, add the following code:

#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;

For the network core, add the following code:

#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;

See the following tables for more information about trigger connections to and from the CTI.

Table 8. Application core triggers to CTI
Signal Description
CTITRIGIN[0] Processor halted
CTITRIGIN[1] DWT comparator output 0
CTITRIGIN[2] DWT comparator output 1
CTITRIGIN[3] DWT comparator output 2
CTITRIGIN[4] ETM event output 0
CTITRIGIN[5] ETM event output 1
Table 9. Application core triggers from CTI
Signal Description
CTITRIGOUT[0] Processor debug request
CTITRIGOUT[1] Processor restart
CTITRIGOUT[2] N/A
CTITRIGOUT[3] N/A
CTITRIGOUT[4] ETM event input 0
CTITRIGOUT[5] ETM event input 1
CTITRIGOUT[6] ETM event input 2
CTITRIGOUT[7] ETM event input 3
Table 10. Network core triggers to CTI
Signal Description
CTITRIGIN[0] Processor halted
CTITRIGIN[1] DWT comparator output 0
CTITRIGIN[2] DWT comparator output 1
CTITRIGIN[3] DWT comparator output 2
Table 11. Network core triggers from CTI
Signal Description
CTITRIGOUT[0] Processor debug request
CTITRIGOUT[1] Processor restart

Multidrop serial wire debug

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.

Trace

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

Enabling the trace port

A specific sequence of operations must be performed to enable the trace port.

  1. Enable the debug master.
    NRF_TAD_S->ENABLE = TAD_ENABLE_ENABLE_Msk;
  2. Request clock startup.
    NRF_TAD_S->CLOCKSTART = TAD_CLOCKSTART_START_Msk;
  3. Configure the trace port to use pins P0.8 through P0.12.
    NRF_TAD_S->PSEL.TRACECLK   = TAD_PSEL_TRACECLK_PIN_Traceclk;
    NRF_TAD_S->PSEL.TRACEDATA0 = TAD_PSEL_TRACEDATA0_PIN_Tracedata0;
    NRF_TAD_S->PSEL.TRACEDATA1 = TAD_PSEL_TRACEDATA1_PIN_Tracedata1;
    NRF_TAD_S->PSEL.TRACEDATA2 = TAD_PSEL_TRACEDATA2_PIN_Tracedata2;
    NRF_TAD_S->PSEL.TRACEDATA3 = TAD_PSEL_TRACEDATA3_PIN_Tracedata3;
  4. Configure the GPIO pads so that the trace and debug system can control them. Set high drive strength to ensure sufficiently fast operation. Do this for all trace pins that should be used.
    // Clear the bitfields before configuring to make sure the correct value is written
    NRF_P0_S->PIN_CNF[TAD_PSEL_TRACECLK_PIN_Traceclk]
                        &= ~(GPIO_PIN_CNF_MCUSEL_Msk | GPIO_PIN_CNF_DRIVE_Msk);
    NRF_P0_S->PIN_CNF[TAD_PSEL_TRACECLK_PIN_Traceclk]
                        |= (GPIO_PIN_CNF_MCUSEL_TND << GPIO_PIN_CNF_MCUSEL_Pos)
                         | (GPIO_PIN_CNF_DRIVE_E0E1 << GPIO_PIN_CNF_DRIVE_Pos);
  5. Set trace port speed to 64 MHz.
    NRF_TAD_S->TRACEPORTSPEED = TAD_TRACEPORTSPEED_TRACEPORTSPEED_64MHz;
    Note: Although possible, it is not recommended to run the trace port at less than half the CPU frequency, as it risks dropping some trace packets.
  6. ConfigureArm® CoreSight™ components (see Arm CoreSight documentation for more information).

This document was last updated on
2020-06-24.
Please send us your feedback about the documentation! For technical questions, visit the Nordic Developer Zone.