Overview

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
    • 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)
    • 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 via the debug access port (DAP).

The DAP implements a standard ARM® CoreSight™ serial wire debug port (SW-DP). The SW-DP implements the serial wire debug (SWD) protocol that is a two-pin serial interface, see SWDCLK and SWDIO in figure Figure 1.

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. An overview is given in the table below.

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 are standard ARM® components, and documented in ARM® CoreSight™ SoC-400 Technical Reference Manual, revision r3p2. The control access port (CTRL-AP) is proprietary, and described in more detail in CTRL-AP - Control access port.

Access port protection

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

An overview of the access port protection schemes is given in the table below.

Table 2. 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.
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 access 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 make sure to put the device back into normal mode and then a pin reset should be performed. The reason is that 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 peripherals that are affected.

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 their code without a failure of the 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 3. 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 4. 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 5. 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 6. 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 features a cross-trigger network that can be used for simultaneous starting and halting of the cores in the system. An overview of the cross-trigger connections is given in figure below.

Figure 4. Cross-trigger network overview
Cross-trigger network overview

Both the application and network core have a cross-trigger interface (CTI) peripheral that can trigger, or get 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.

It is possible to halt the network core when the application is halted (either because of a breakpoint or a stopped debug session). This can be done in the following way:

  1. Configure application CTI to generate an event on channel 0 for CTITRIGIN[0] (processor halted) using CTIINEN[0].
  2. Configure network 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;

For more information about the trigger connections to and from the CTI, see the tables below.

Table 7. 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 8. 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 9. 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 10. Network core triggers from CTI
Signal Description
CTITRIGOUT[0] Processor debug request
CTITRIGOUT[1] Processor restart

Multidrop SWD

Multidrop SWD 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. 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 TRACEDATA[0] through TRACEDATA[3], and TRACECLK in figure Figure 1.

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, please read the debug documentation of your IDE.

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

Trace speed is configured in the TRACEPORTSPEED register. The speed of the trace pins depends on the drive setting of the GPIOs that the trace pins are multiplexed with. See GPIO — General purpose input/output for information about how to set drive settings. Only S0S1 and H0H1 drives are suitable 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). The user shall make sure that these GPIOs' drive setting is not overwritten by software during the debugging session.

Enabling the trace port

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

  1. Enable the debug master by using the code below.
    NRF_TAD_S->ENABLE = TAD_ENABLE_ENABLE_Msk;
  2. Request clock startup.
    NRF_TAD_S->CLOCKSTART = TAD_CLOCKSTART_START_Msk;
  3. Configure TPIU port to pads.
    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. Hand over control of the GPIO pads to the trace and debug subsystem, and 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_H0H1 << 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. Configure ARM® CoreSight™ components (see ARM® CoreSight™ documents for more information).

Registers

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

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

0x44

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

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