Understanding the CoreSight DAP

A tutorial describing the CoreSight Debug Access Port (DAP) and common Arm Development Studio DAP-related autodetection issues


Overview What is a Debug Access Port What is an Access Port What is a ROM Table Common DAP-related autodetection issues Related information

What is a Debug Access Port?

Typically, CoreSight devices are behind a CoreSight Debug Access Port (DAP). Arm CoreSight technology is used to debug and trace complex SoC designs. 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. Usually, the connection is based on a simple physical interface like JTAG or Serial Wire (SW).

An AP provides a connection from the DP to a subsystem on the SoC. Many subsystems consist of multiple debug components that are arranged in a memory map. An AP provides the connection to these memory mapped components. If more than one subsystem is accessed, more than one AP is used.

DAP implementations follow one of these Arm Debug Interface (ADI) Architecture Specifications:

These architecture specifications describe how debug tools, like Arm Development Studio, interact with CoreSight devices.

CoreSight SoC-400 implements ADIv5.x. CoreSight SoC-600 implements ADIv6.

In the Arm Development Studio platform configurations, the DP is represented by a <name of IP creator>CS-DP device. For example, an Arm-implemented DP is an ARMCS-DP.

DP versions

The ADI and CoreSight SoC versions implemented determine the DP version that is used.

ADIv5.x defines DPv0, DPv1, and DPv2.

ADIv5.x implementations provide an external debugger physical connection interface to debug or trace a SoC. The possible physical connection interfaces are:

Physical connection interfaces
 JTAG interface
Serial Wire Debug (SWD) interface
 JTAG Debug Port (JTAG-DP)

 X

 
 Serial Wire Debug Port (SW-DP)  

X

 A combined Serial Wire/JTAG Debug Port (SWJ-DP)

 X

X

To allow the most physical connection flexibility, most ADIv5.x SoC implementations use a SWJ - DP.

ADIv6.0 defines DPv3, which expands on the features and capabilities of the previous DP versions. ADIv6 introduces a layering system that provides memory-mapped access to all parts of a system from multiple different agents, including external debuggers and on-chip software. These layers include:

  • The physical layer:
    • The physical pins on a target to connect a debugger to a target
    • Examples of physical layers include:
      • JTAG connector
      • Serial Wire debug connector (SWD)
      • USB connector
      • PCIe connector
      • IP sockets
    • The type(s) of physical connections a SoC uses is referred to as debug links.
  • The protocol layer:
    • The JTAG and SWD state machines
  • The link layer:
    • The mechanism to perform basic accesses to DP(s) registers and AP(s)
  • The AP layer:

The following diagram is an example of an ADIv6 system:

Diagram of an ADIv6 system

The following diagram shows an ADIv5.x or ADIv6 external debugger connection:

Diagram of an ADIv6 system for an external debug connection via JTAG or SWD

DAP power control model

The SoC designer determines which power domain the CoreSight devices are in, and how the devices are powered. Typically, a SoC divides the debug devices into a separate debug power domain, and other devices into system power domains. Usually, the SoC power controller determines when and which devices are powered up.

ADIv5.x and ADIv6 define two pairs of power control signals in the DP CTRL/STAT register:

  • CDBGPWRUPREQ and CDBGPWRUPACK
    • CDBGPWRUPREQ is a signal from the debug interface to the power controller to fully power the system and ensure clocks are available to the debug power domain.This ensures that the debugger can access enough debug resources of the CoreSight devices to determine their state.This signal also allows the debugger to perform debug operations like run or step.
    • CDBGPWRUPACK is a signal from the power controller to the debug interface to acknowledge the CDBGPWRUPREQ signal.
  • CSYSPWRUPREQ and CSYSPWRUPACK
    • CSYSPWRUPREQ is a signal from the debug interface to the power controller to fully power the system and ensure clocks are available to the system power domain.This ensures that the debugger can access the non-CoreSight components of the SoC, like main memory and interconnects.
    • CSYSPWRUPACK is a signal from the power controller to the debug interface to acknowledge the CSYSPWRUPREQ signal.

These signals are requests to the system power and clock controller to enable external debugging. The system power and clock controller should honor these requests.

In ADIv6, because CDBGPWRUPREQ and CSYSPWRUPREQ are pieces of DP functionality that are not directly accessible to functional networks like PCIe, the Granular Power Requester (GPR) is the primary powerup request mechanism. The GPR is in the ROM Table(s), or in ADIv5-compliant systems, in the standalone components.

A ROM Table points to debug components. A GPR in a ROM Table uses the debug components pointed to by the ROM Table to allow a debugger to detect the power domain of the components. The debugger requests power from the power controller only for the domains that are required for status checking and debug operation purposes.

The following diagram shows a ROM Table with a GPR, where the GPR requests power to two different power domains:

Diagram of an ADIv6 system with a GPR in the ROM Table

The debugger might need to connect to components that are not pointed to by a ROM Table to debug a SoC. For example, a debugger might need to connect to the system interconnect configuration components. The GPR can support issuing powerup requests to further power domains. These further power domains are referred to as system power domains. The GPR enables a debugger to request power up to components in system power domains across the SoC.

What is ROM Table? provides more information on ROM Tables.

Previous Next