Difference between revisions of "DAP"

From SEGGER Wiki
Jump to: navigation, search
(DAP topology examples =)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
The debug access port (DAP) means the DP and all APs that are connected to the DP. It is to describe the whole debug hierarchy. It was initially designed as a standard to enable debug access to ARM cores but has been developed to a standard that also allows to access ARM and non-ARM cores in the same design via a single debug connector, all sharing the same pins on the device. This enables silicon vendors to easily create hybrid devices that contain ARM and non-ARM cores in the same design and which only expose a single standardized debug interface that allows debug access to all of the cores in the device.
 
The debug access port (DAP) means the DP and all APs that are connected to the DP. It is to describe the whole debug hierarchy. It was initially designed as a standard to enable debug access to ARM cores but has been developed to a standard that also allows to access ARM and non-ARM cores in the same design via a single debug connector, all sharing the same pins on the device. This enables silicon vendors to easily create hybrid devices that contain ARM and non-ARM cores in the same design and which only expose a single standardized debug interface that allows debug access to all of the cores in the device.
   
[[File:DAP_General.svg|DAP setup|thumb|none]] <!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
+
[[File:DAP_General.png|DAP setup|thumb|none]] <!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
   
 
= DP =
 
= DP =
Line 25: Line 25:
 
= AP =
 
= AP =
 
A access port (AP) mainly is a memory bus interface to access the actual debug logic / resources. While the DP performs the protocol translation, an AP usually performs real memory accesses to read/write debug register. APs are comparable to DMAs and allow to issue memory accesses without using the CPU core. There are different types of APs:
 
A access port (AP) mainly is a memory bus interface to access the actual debug logic / resources. While the DP performs the protocol translation, an AP usually performs real memory accesses to read/write debug register. APs are comparable to DMAs and allow to issue memory accesses without using the CPU core. There are different types of APs:
  +
* AHB-AP <span style="color:#a2a9b1">Advanced High-performance Bus - Access Port </span>
* AHB-AP
 
  +
* APB-AP <span style="color:#a2a9b1">Advanced Peripheral Bus - Access Port </span>
* APB-AP
 
  +
* AXI-AP <span style="color:#a2a9b1">Advanced eXtensible Interface - Access Port </span>
* AXI-AP
 
  +
* JTAG-AP <span style="color:#a2a9b1">Joint Test Action Group- Access Port </span>
* JTAG-AP
 
   
 
While there is only one DP in a DAP system, multiple APs may be connected to a single DP.
 
While there is only one DP in a DAP system, multiple APs may be connected to a single DP.
   
 
== AHB-AP ==
 
== AHB-AP ==
This was the first AP type to be introduced and was first used on Cortex-M based MCUs. The AHB-AP acts like a second memory interface to the system memory and debug registers of the CPU core. In this setup, the AHB-AP and the CPU core share the same 4 GB address space. This means, the debug registers are accessible via the debug interface as well as from the CPU core itself. A nice side effect of this setup is that the AHB-AP allows reading / writing the system memory (RAM, SFRs, ...) independent from the core (like a DMA). This allows techniques like [https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/ SEGGER RTT] to be used.
+
This was the first AP type to be introduced and was first used on Cortex-M based MCUs. The AHB-AP acts like a second memory interface to the system memory and debug registers of the CPU core. In this setup, the AHB-AP and the CPU core share the same 4 GiB address space. This means, the debug registers are accessible via the debug interface as well as from the CPU core itself. A nice side effect of this setup is that the AHB-AP allows reading / writing the system memory (RAM, SFRs, ...) independent from the core (like a DMA). This allows techniques like [https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/ SEGGER RTT] to be used.
   
 
For AHB-AP based debug designs (Cortex-M), the location of the debug registers is fixed in the address space. This means, having multiple Cortex-M cores in a DAP requires a separate AHB-AP for each of them.
 
For AHB-AP based debug designs (Cortex-M), the location of the debug registers is fixed in the address space. This means, having multiple Cortex-M cores in a DAP requires a separate AHB-AP for each of them.
   
 
== APB-AP ==
 
== APB-AP ==
This AP type was first introduced with Cortex-A and Cortex-R based MCUs. The APB-AP provides a separate 4 GB address space which is different from the core address space. The idea behind this was to separate debug register access and system memory accesses, so that a core cannot alter/modify the debug registers accidentally. It also leaves more room of the 4 GB system address space to be used for other memories etc., as the debug registers are mapped in their own 4 GB APB-AP address space. This also introduced the possibility to handle multiple cores in a DAP with a single APB-AP, by simply placing the debug registers of a core in a 4 KB tile of the APB-AP address space.
+
This AP type was first introduced with Cortex-A and Cortex-R based MCUs. The APB-AP provides a separate 4 GiB address space which is different from the core address space. The idea behind this was to separate debug register access and system memory accesses, so that a core cannot alter/modify the debug registers accidentally. It also leaves more room of the 4 GiB system address space to be used for other memories etc., as the debug registers are mapped in their own 4 GiB APB-AP address space. This also introduced the possibility to handle multiple cores in a DAP with a single APB-AP, by simply placing the debug registers of a core in a 4 KiB tile of the APB-AP address space.
   
 
The downside of separating debug and system address space is that an APB-AP does not allow to access the system memory (RAM, SFRs, ...) to be accessed independent from the core. There are also Cortex-A based designs that implement an AHB-AP in addition to the APB-AP. While the APB-AP is used to access the debug registers, the AHB-AP in such designs may be used to access the system memory independently from the core (e.g. while it is running).
 
The downside of separating debug and system address space is that an APB-AP does not allow to access the system memory (RAM, SFRs, ...) to be accessed independent from the core. There are also Cortex-A based designs that implement an AHB-AP in addition to the APB-AP. While the APB-AP is used to access the debug registers, the AHB-AP in such designs may be used to access the system memory independently from the core (e.g. while it is running).
   
 
== AXI-AP ==
 
== AXI-AP ==
This AP type was introduced with the introduction of the APB-AP. As the APB-AP does not allow system memory and the AHB-AP is somewhat limited because it only support a 4 GB address space (32-bit), the AXI-AP was introduced to allow memory accesses independent from the core again but keeping the debug / system address space separation. In addition to that, the AXI-AP supports a 64-bit address space which is important for later Cortex-A designs that are based on ARMv8-A and support more than 32-bit.
+
This AP type was introduced with the introduction of the APB-AP. As the APB-AP does not allow system memory and the AHB-AP is somewhat limited because it only support a 4 GiB address space (32-bit), the AXI-AP was introduced to allow memory accesses independent from the core again but keeping the debug / system address space separation. In addition to that, the AXI-AP supports a 64-bit address space which is important for later Cortex-A designs that are based on ARMv8-A and support more than 32-bit.
   
 
== JTAG-AP ==
 
== JTAG-AP ==
Line 49: Line 49:
   
 
= DAP topology examples =
 
= DAP topology examples =
  +
[[File:DAP_CortexM_System.svg|Cortex-M DAP setup|thumb|none]]<!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
 
  +
== DAP topology example - Cortex-M ==
[[File:DAP_CortexA_System.svg|Cortex-A DAP setup|thumb|none]]<!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
 
[[File:DAP_Hybrid_System.svg|Hybrid DAP setup|thumb|none]]<!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
+
[[File:DAP_CortexM_System.png|Cortex-M DAP setup|thumb|none]]<!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
  +
  +
== DAP topology example - Cortex-A ==
  +
[[File:DAP_CortexA_System.png|Cortex-A DAP setup|thumb|none]]<!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
  +
  +
== DAP topology example - Hybrid ==
  +
[[File:DAP_Hybrid_System.png|Hybrid DAP setup|thumb|none]]<!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->
  +
  +
== DAP topology example - Cascaded APs ==
  +
Since CoreSight SoC-600 it is also possible to have the debug AP of the core behind another AP (usually an APB-AP). This is a very rare but possible setup.
  +
[[File:DAP_CascadedAPs_CortexM_System.png|Cascaded APs DAP setup|thumb|none]] <!-- Source of SVG is also in the wiki. Same name but extension .vsdx -->

Latest revision as of 15:21, 13 July 2022

The debug access port (DAP) means the DP and all APs that are connected to the DP. It is to describe the whole debug hierarchy. It was initially designed as a standard to enable debug access to ARM cores but has been developed to a standard that also allows to access ARM and non-ARM cores in the same design via a single debug connector, all sharing the same pins on the device. This enables silicon vendors to easily create hybrid devices that contain ARM and non-ARM cores in the same design and which only expose a single standardized debug interface that allows debug access to all of the cores in the device.

DAP setup

DP

The debug port (DP) translates from the physical protocol that is used to communicate with the debug logic to the ARM specific internal debug logic. There are different types of DPs:

  • JTAG-DP
  • SW-DP
  • SWJ-DP

There is only one DP in a DAP.

JTAG-DP

JTAG is used to exchange information with the debug logic. The physical protocol may be 4-wire JTAG (IEEE 1149.1) or 2-wire cJTAG (IEEE 1149.7).

cJTAG and DP

Device internally, the DP understands 4-wire JTAG only. In case externally cJTAG is used as the physical protocol, there is a device internal 2-to-4-wire converter unit in front of the JTAG-DP that translates from cJTAG to JTAG. The DP still sees 4 signals internally, but only 2 are physically available at the pins of the MCU.

SW-DP

2-wire Serial Wire Debug (SWD) is used to exchange information with the debug logic.

SWJ-DP

JTAG or SWD may be used to exchange information with the debug logic. The protocol is switched between JTAG and SWD at runtime, using specific switching sequences that are specified by ARM and do not hurt JTAG devices that may be in the same JTAG chain as the SWJ-DP.

AP

A access port (AP) mainly is a memory bus interface to access the actual debug logic / resources. While the DP performs the protocol translation, an AP usually performs real memory accesses to read/write debug register. APs are comparable to DMAs and allow to issue memory accesses without using the CPU core. There are different types of APs:

  • AHB-AP Advanced High-performance Bus - Access Port
  • APB-AP Advanced Peripheral Bus - Access Port
  • AXI-AP Advanced eXtensible Interface - Access Port
  • JTAG-AP Joint Test Action Group- Access Port

While there is only one DP in a DAP system, multiple APs may be connected to a single DP.

AHB-AP

This was the first AP type to be introduced and was first used on Cortex-M based MCUs. The AHB-AP acts like a second memory interface to the system memory and debug registers of the CPU core. In this setup, the AHB-AP and the CPU core share the same 4 GiB address space. This means, the debug registers are accessible via the debug interface as well as from the CPU core itself. A nice side effect of this setup is that the AHB-AP allows reading / writing the system memory (RAM, SFRs, ...) independent from the core (like a DMA). This allows techniques like SEGGER RTT to be used.

For AHB-AP based debug designs (Cortex-M), the location of the debug registers is fixed in the address space. This means, having multiple Cortex-M cores in a DAP requires a separate AHB-AP for each of them.

APB-AP

This AP type was first introduced with Cortex-A and Cortex-R based MCUs. The APB-AP provides a separate 4 GiB address space which is different from the core address space. The idea behind this was to separate debug register access and system memory accesses, so that a core cannot alter/modify the debug registers accidentally. It also leaves more room of the 4 GiB system address space to be used for other memories etc., as the debug registers are mapped in their own 4 GiB APB-AP address space. This also introduced the possibility to handle multiple cores in a DAP with a single APB-AP, by simply placing the debug registers of a core in a 4 KiB tile of the APB-AP address space.

The downside of separating debug and system address space is that an APB-AP does not allow to access the system memory (RAM, SFRs, ...) to be accessed independent from the core. There are also Cortex-A based designs that implement an AHB-AP in addition to the APB-AP. While the APB-AP is used to access the debug registers, the AHB-AP in such designs may be used to access the system memory independently from the core (e.g. while it is running).

AXI-AP

This AP type was introduced with the introduction of the APB-AP. As the APB-AP does not allow system memory and the AHB-AP is somewhat limited because it only support a 4 GiB address space (32-bit), the AXI-AP was introduced to allow memory accesses independent from the core again but keeping the debug / system address space separation. In addition to that, the AXI-AP supports a 64-bit address space which is important for later Cortex-A designs that are based on ARMv8-A and support more than 32-bit.

JTAG-AP

This AP type is different from the other ones as it does not provide a DMA-like functionality to access memory. The JTAG-AP is a special AP type to be able to support legacy core designs that have non-memory-mapped debug registers which are accessed via specific JTAG instructions (Shift-IR). For example, if a design shall incorporate a Cortex-M core and an ARM11 core, the Cortex-M would be accessible via an AHB-AP and the ARM11 would be behind a JTAG-AP, both connected to the same DP. The JTAG-AP allows to issue specific JTAG instructions to the ARM11 without bothering the other cores in the same DAP.

DAP topology examples

DAP topology example - Cortex-M

Cortex-M DAP setup

DAP topology example - Cortex-A

Cortex-A DAP setup

DAP topology example - Hybrid

Hybrid DAP setup

DAP topology example - Cascaded APs

Since CoreSight SoC-600 it is also possible to have the debug AP of the core behind another AP (usually an APB-AP). This is a very rare but possible setup.

Cascaded APs DAP setup