Debugging Armv8 platforms with CSAT

Tutorial on performing low-level debug of Armv8 platforms with CSAT as shipped with Arm Development Studio (Arm DS).

Introduction Armv8 topology Worked examples Conclusion Further information

Armv8 topology

Armv8 platforms use a debug infrastructure called CoreSight to provide visibility into a SoC (System on Chip) for debug purposes. CSAT directly interacts with the CoreSight infrastructure to debug issues at a lower level than most debug tools. To understand how to use CSAT, you must have a basic understanding of the CoreSight infrastructure and its components.

To prepare you to work with CSAT, this section includes information on the following CoreSight topics:

What are CoreSight components?

CoreSight components provide the debug and trace infrastructure of a SoC. The components include control and access devices like the following:

  • Debug Access Port (DAP)
  • Trace sources
  • Trace links
  • Trace sinks.

A DAP is a Debug Port (DP) that is connected to one or more Access Ports (APs). A DP provides a connection from outside the SoC to one or more APs. An external debugger connects to a DAP to access the CoreSight infrastructure.

An AP provides a bridge into another system on the SoC. A Memory Access Port (MEM-AP) provides a window into a memory system. This window allows memory-mapped accesses to debug resources like Debug registers. Read Understanding the CoreSight DAP for more information on DAPs and APs.

An example of a MEM-AP is an Advanced Peripheral Bus Access Port (APB-AP). In this tutorial, with CSAT, we use the target APB-AP to access the memory-mapped Debug registers.

One type of trace link is a cross-trigger network that consists of Cross Trigger Interfaces (CTIs) and Cross Trigger Matrices (CTMs). CTIs enable the distribution of events to and from sources and destinations in the system. CTIs are connected to each other using one or more CTMs through channels.

The cross-trigger network works by input triggers or the user generating channel events on a channel or connected channels. This channel event triggers an output trigger event like a core halt or restart request. For example, if multiple cores are connected to a channel and one core halts, a synchronous halt of all connected cores occurs. For an Armv8 core, core halt and restart must happen using CTIs. Read your core Technical Reference Manual (TRM) for more information on the use of CTI channels and triggers.

Read Understanding trace for more information on how trace works in Arm systems.

What is a CoreSight ROM Table?

A CoreSight ROM Table stores the locations of all the debug components accessible through a DP or MEM-AP. ROM Table values are usually read consecutively starting at the base address of the ROM Table. To find the ROM Table base address, look at the memory map in your target Technical Reference Manual (TRM). Alternatively, read the MEM-AP register BASE at offset 0xF8 to find the ROM Table base address for the MEM-AP.

The processor might see the debug components at a different address to the external debugger. This difference might occur so the external debugger can bypass locks used to restrict software access to the Debug registers. For example, on the Arm Cortex-A53x2 SMM target, the TRM states the debug components start at address 0x20000000. The external debugger accesses the debug components starting at address 0x80000000. For more information, read the 'Memory system design' section of the Arm CoreSight Architecture Specification.

A ROM Table is usually at the beginning of a memory system and is 4KB in size. For targets with more than one cluster of processors, there is usually a top-level ROM Table and a ROM Table for each cluster. Read Understanding the CoreSight DAP for more information on ROM Tables and the CoreSight architecture.

Useful Debug Registers

To perform low-level debug using CSAT, you must read and write registers that are accessible VIA the external memory mapped interface. The following are some useful Debug registers:

Register name

Memory-mapped offset

Register description

External Debug Status and Control Register (EDSCR)


Main debug control register for an Armv8 core.

OS Lock Access Register (OSLAR_EL1)


Controls the OS Lock. Unlocking the OS Lock allows you to access the Debug registers. Write-only register.

External Debug Program Counter Sample Register[31:0] (EDPCSRlo)


External Debug Program Counter Sample Register [63:32] (EDPCSRhi)




Optional registers to read the Program Counter when externally debugging. Read-only registers. Not present in all implementations.

External Debug Power/Reset Control Register (EDPRCR)


Controls the powerup, reset, and powerdown functionality of the CPU.

External Debug Processor Status Register (EDPRSR)


Contains status information on the reset and powerdown state of the CPU.

Debug Breakpoint Value Register (DBGBVR<n>_EL1)*

0x400 + 16n

Contains address of hardware breakpoint n.

Debug Breakpoint Control Register (DBGBCR<n>_EL1)*

0x408 + 16n

Controls and enables hardware breakpoint n.

Debug Watchpoint Value Register (DBGWVR<n>_EL1)**

0x800 + 16n

Contains address of watchpoint n.

Debug Watchpoint Control Register (DBGWCR<n>_EL1)**

0x808 + 16n

Controls and enables watchpoint n.

*Each hardware breakpoint uses a pair of registers to control, set, and enable the breakpoint. The number of hardware breakpoints available is IMPLEMENTATION SPECIFIC.

**Each watchpoint has a pair of registers to control, set, and enable the watchpoint. The number of watchpoints available is IMPLEMENTATION SPECIFIC.

To find the offsets of other Debug registers in an Armv8-A system, read the 'External Debug Register Descriptions' section of the Arm Architecture Reference Manual Armv8-A. These offsets are relative to the address of the debug memory system of the core. The core debug memory system address is found in the target TRM. For example, calculate the address of the EDSCR register for a core with the following information:

  • Base address of the target debug and trace system is 0x80000000.
  • Cluster offset is 0x02000000.
  • Individual core debug region offset is 0x00010000.
  • EDSCR at offset 0x088.

Add the previous information together

0x80000000 + 0x02000000 + 0x00010000 + 0x088

to get an EDSCR address of 0x82010088.

Useful CTI registers

To halt or restart the core, use one or more target CTIs. The following are useful CTI registers:

Register name

Memory-mapped offset

Register description

CTI Control Register (CTICONTROL)


Used to enable or disable CTIs.

CTI Channel Gate Enable Register (CTIGATE)


Controls whether the internal channels are connected to the CTM. Internal channels allow channel events on specific cores to propagate to other components.

CTI Input Channel to Output Trigger Enable Registers (CTIOUTEN<n>)

0x0a0 + 4n

Connects input channels to output trigger n. This connection allows channel events on these channels to generate trigger events on output trigger n. The number of output triggers available is IMPLEMENTATION SPECIFIC.

CTI Input Trigger to Output Channel Enable Registers (CTIINEN<n>)

0x020 + 4n

Connects input trigger n to output channels. This connection allows input trigger n to generate channel events on the connected channels. The number of input triggers available is IMPLEMENTATION SPECIFIC.

CTI Application Pulse Register (CTIAPPPULSE)


Can generate channel events on a specific channel. Write-only register.

CTI Output Trigger Acknowledge Register (CTIINTACK)


Can create soft acknowledgements of output triggers. Can deassert a trigger event by writing 1 to bit[0]. Write-only register.

CTI Trigger Out Status Register (CTITRIGOUTSTATUS)


Gives the status of the trigger outputs. To confirm an output trigger has been deasserted, the debugger must poll bit[0] until it reads as 0. Bit[0] must read as 0 before attempting to generate another trigger event. Read-only register.

To find the offsets of other CTI registers in an Armv8-A system, read the “External Debug Register Descriptions” section of the Arm Architecture Reference Manual Armv8-A. These offsets are relative to the address of the CTI region for a core. The CTI addresses are available in the “CoreSight debug and trace” section of the target TRM.

For more detailed CTI register descriptions for an Armv8-A system, read the Arm Architecture Reference Manual Armv8-A.

Previous Next