The different DAPs

The term DAP refers to the Debug Access Port. The DAP usually includes two parts: the Debug Port (DP) and the Access Port (AP).

The DP can be controlled from an external debugger using Arm’s Serial Wire Debug (SWD) protocol or Joint Test Action Group IEEE 1149.1 (JTAG) protocol. The SWD protocol, described in the Arm Debug Interface Architecture Specification (ADI), may implement version 1 or 2 of the protocol. The version 1 of the protocol supports only a single point-to-point connection. The version 2 of the protocol supports Multi-Drop, allowing one debugger to control multiple DAPs on one or more devices at the same time.

One or more APs in a DAP can send debug requests to processors, CoreSight debug and trace components or memory subsystems.

The DAP provides multiple driving ports, all accessible, and controlled through a single external interface port so that it can achieve:

• Real-time access to physical memory without halting the target and without any target-resident code.
• Debug control and access to all status registers.

Over the years, the DAP has evolved and is structured differently in different products. Some chip designers may be unclear on selecting the correct DAP for their required usage, especially when they need to support the multi-drop features in SWD version 2. This document introduces various DAPs to help you understand the differences between DAPs and to help you to choose suitable DAPs for your SoCs.

1. The legacy DAP-Lite

In the early 2000s, Arm released a DAP-Lite product in some legacy processors’ bundles, such as the Cortex-A9 processor bundle. Figure 1 shows the diagram of this legacy DAP-Lite.

Figure 1: The legacy DAP-Lite

The legacy DAP-lite supports Arm Debug Interface (ADI) version 5 and CoreSight Architecture Specification v2.0. It has the following features:

• The legacy DAP-lite supports both SWD port and JTAG protocols on the Debug Port.
• The SWD protocol in the legacy DAP-Lite does not support multi-drop.
• The DAP-Lite has a single APB Access Port (APB-AP), which can be integrated with different CoreSight components and Cortex-A and R processors.
• The DAP-Lite has a System APB interface that allows the AP to be controlled from an on-chip agent, such as a processor, through the chip’s memory map.

2. The DAP in legacy CoreSight Design Kits

The DAP-Lite, in the previous section, supports only a single AP, while some designs require a multiprocessor debug and trace solution which needs multiple APs. In the past, Arm provided CoreSight Design Kits to address this requirement. These CoreSight Design Kits provide a fixed DAP, shown in figure 2.

Figure 2: the DAP in the CoreSight Design Kits

The DAP in the legacy CoreSight Design Kits supports ADI version 5 and CoreSight Architecture Specification v2.0. As the design of this DAP is fixed, chip designers cannot modify it.

The DAP in the CoreSight Design Kits has the following features:

• It supports both SWD and JTAG protocols.
• Its SWD supports multi-drop.
• It includes a single APB-AP, which is provided to integrate the CoreSight components and Cortex-A/R processors
• It includes a single JTAG-AP, which is provided to integrate with the legacy processors with JTAG debug interfaces, such as Arm7, Arm9, and Arm11 processors.
• It includes a single AHB-AP, which is provided to integrate with a single Cortex-M processor (excluding Cortex-M3/M4) or integrate with an AHB-based on-chip memory system.
• It includes an APB_MUX interface, which is provided to integrate with a single Cortex-M3/M4 processor with an internal AHB-AP built-in.

3. DAP built with CoreSight SoC-400

As the fixed DAP in the legacy CoreSight Design Kits do not allow designers to select the specific APs needed for their system, Arm developed and released CoreSight SoC-400 to address this. SoC-400 provides configurable CoreSight components so that designers can customize the DAP to match their system requirements.

SoC-400 supports ADI version 5 and CoreSight Architecture Specification v2.

SoC-400 allows designers to select the components to build their DAP. A typical DAP built with SoC-400 has a structure similar to the example shown in figure 3, with the following features:

• It supports both JTAG and SWD interfaces.
• Its SWD interface supports multi-drop.
• The DAPBUS interconnect can be configured with up to 32 APs.
• The example DAP shown in figure 3 has one AXI-AP, one AHB-AP, one APB-AP, one JTAG-AP, and one DAPBUS port. You can vary the number of each of these, for example:
  • In a design with no legacy targets, there is no need for a JTAG-AP.
  • In a design with Cortex-M3 and M4, which contains its own AHB-AP, each processor needs to integrate with one DAPBUS port.
  • In a design with Cortex-M except for Cortex-M3 and M4, each Cortex-M processor needs to integrate with one AHB-AP.

Figure 3: The DAP built with SoC-400

4. The DAP built with SoC-600

Though SoC-400 allows designers to select APs according to their system requirements, it does not provide a path to access resources behind each AP. Some designers would like on-chip access to debug and trace resources, especially to have a path that other requesters can access Cortex-M processors’ debug and trace resources, which SoC-400 does not support.

SoC-600 was designed to address these requirements. SoC-600 supports ADI version 6 and CoreSight Architecture Specification v3. A typical DAP built with SoC-600 is shown in figure 4.

Figure 4: DAP example built with SoC-600

The main features of this typical example are as following:

• The css600_apbic can be configured to have up to 4 APB interfaces to receive requests from the css600_dp or from on-chip interconnects and up to 64 APB interfaces to drive APs. Connecting the css600_apbic to be driven by the functional interconnect provides a path that allows on-chip agents such as processors to access all debug and trace resources behind each AP.
• The css600_dp in SoC-600 can be configured to support the JTAG, or Serial Wire, or both JTAG and Serial Wire.
• The SWD supports multi-drop.

• The interfaces driving out of the configured css600_apbic can be integrated with the APs and the ROM Table. The ROM Table here identifies which APs are connected to the same css600_apbic.

Compared to MEM-APs based on CoreSight Architecture Specification v2.0, the MEM-APs in SoC-600 have the following features and functions:

• The MEM-APs in SoC-600 provides two logical views of the access port to the debugger. These two views are referred to as twin MEM-APs or logical MEM-APs. These two logical MEM-APs are contiguous in the memory map, and each one of them occupies 4kB address space. One logical MEM-AP is for the on-chip access for self-hosted debug, while the other AP is for the off-chip accesses from the debugger. This means that it has separate dedicated registers space for on-chip and off-chip accesses (that is, in total, 8KB of address space) so that they do not interfere with each other. Still, the behavior of the top and the bottom sets of registers is the same.
• Arm also recommends integrating a ROM Table in parallel with the APs. The entries in this ROM Table should point to each AP with the address offset based on this ROM Table’s base address. The debugger will find the APs by reading these entries.

5. The DAP-Lite 2

The DAP-Lite 2 provides two versions of DAPs that are compliant with ADI version 6.0. One DAP supports application and real-time processors with AMBA APB4 debug interfaces, and the other DAP supports microcontroller processors with AMBA AHB5 debug interfaces. The DAP-Lite2 is designed for single Arm Cortex-based processors.

The DAP-Lite2 bundle includes:

• Two DAP components. You can choose daplite2_ar, whose diagram is shown in figure 5, for Cortex-A and R processors and daplite2_m, whose diagram is shown in figure 6, for Cortex-M processors.
• daplite2_ar has integrated a single APB-AP for CoreSight components and Cortex-A and R processors.
• daplite2_m has integrated a single AHB-AP for the Cortex-M processors.
• daplite2 can be configured to support either Serial Wire protocol or JTAG protocol, or both Serial Wire protocol and JTAG protocol.
• The SWD interface supports multi-drop.
• daplite2_ar has a configurable parameter to set the base address of the internal ROM Table.

Figure 5: DAP-Lite2 AR block

Figure 6: DAP-Lite2 M block

6. The reduced version of DAP in Cortex-M bundles

In the legacy Cortex-M processors, including Cortex-M0, Cortex-M0+, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, and Cortex-M33, a reduced version of DAP is provided. This DAP has removed some functions and features from the full DAP and can only be integrated with a single Cortex-M processor, and does not support multiple processors design. The reduced version DAP in Cortex-M0, Cortex-M0+, Cortex-M7, Cortex-M23 and Cortex-M33 has also integrated an internal AHB-AP. The reduced version DAP in Cortex-M3, and Cortex-M4 has not integrated an AHB-AP, because the processors have an internal AHB-AP. Some main features of the reduced version of DAP are summarized in the following table.