You copied the Doc URL to your clipboard.

4.2.3. JTAG and SWD interface

The external JTAG interface has four mandatory pins, tck, tms, tdi, and tdo, and an optional reset, ntrst. JTAG-DP and SW-DP also require a separate power-on reset, npotrst.

The external SWD interface requires two pins:

  • A bidirectional swdio signal.

  • A clock, swclk, that can be input or output from the device.

The block level interface has two pins for data and an output enable that must be used to drive a bidirectional pad for the external interface, and clock and reset signals. To enable sharing of the connector for either JTAG or SWD, connections must be made external to the SWJ-DP block. In particular, tms must be a bidirectional pin to support the bidirectional swdio pin in SWD mode. When SWD mode is used, the tdo pin is normally re-used for Serial Wire Output (SWO). You can use the tdi pin as an alternative input function.


If you require SWO functionality in JTAG mode, you must have a dedicated pin for traceswo.

Operation in JTAG-DP mode

When operating as a JTAG-DP this follows the JTAG-DP as defined in the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2. It also contains a detailed explanation of its programmers model, capabilities and features.

The JTAG-DP contains a debug port state machine that controls the JTAG-DP mode operation, including controlling the scan chain interface that provides the external physical interface to the JTAG-DP. It is based closely on the JTAG TAP State Machine, see IEEE Std 1149.1-2001.

This section contains the following:


The JTAG-DP, IEEE 1149.1 compliant scan chains are used to read or write register information. A pair of scan chain registers is used to access the main control and access registers within the Debug Port. They are:

  • DPACC, for DP accesses.

  • APACC, for AP accesses. An APACC access might access a register of a debug component of the system to which the interface is connected.

The scan chain model implemented by a JTAG-DP has the concepts of capturing the current value of APACC or DPACC, and of updating APACC or DPACC with a new value. An update might cause a read or write access to a DAP register that might then cause a read or write access to a debug register of a connected debug component. The operations available on JTAG-DP are described in the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2. The implemented registers present within the supplied JTAG-DP are described in JTAP-DP register descriptions.

Implementation specific details

The implementation specific information are described in Operation in JTAG-DP mode.

Physical interface

Table 4.1 shows the physical interface for JTAG-DP and the relationship to the signal references in the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2. The JTAG-DP interface defined in the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2 permits an optional return clock signal. However, the CSSoC JTAG-DP implementation does not include a return clock signal.

Table 4.1. JTAG-DP physical interface
Implementation signal name, JTAG-DPADIv5.2 signal name, JTAG-DPTypeJTAG-DP signal description
tdiDBGTDIInputDebug data in
tdoDBGTDOOutputDebug data out
swclktckTCKInputDebug clock
swditmsDBGTMSInputDebug mode select
ntrstDBGTRSTnInputDebug TAP reset

Operation in SW-DP mode

When operating as an SW-DP Interface, this implementation is taken from the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2 and operates with a synchronous serial interface. This uses a single bidirectional data signal and a clock signal.


The SW-DP provides a low pin count bidirectional serial connection to the DAP with a reference clock signal for synchronous operation.

Communications with the SW-DP use a 3-phase protocol:

  • A host-to-target packet request.

  • A target-to-host acknowledge response.

  • A data transfer phase, if required. This can be target-to-host or host-to-target, depending on the request made in the first phase.

A packet request from a debugger indicates whether the required access is to a DP register, DPACC or to an AP register, APACC, and includes a 2-bit register address. For more information about the protocol, see the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2.

Implementation specific details

This section contains the following:

  • Clocking.

  • Overview of debug interface.


The SW-DP clock, swclktck, can be asynchronous to the dapclk. swclktck can be stopped when the debug port is idle.

The host must continue to clock the interface for a number of cycles after the data phase of any data transfer. This ensures that the transfer can be clocked through the SW-DP. This means that after the data phase of any transfer the host must do one of the following:

  • Immediately start a new SW-DP operation.

  • Continue to clock the SW-DP serial interface until the host starts a new SW-DP operation.

  • After clocking out the data parity bit, continue to clock the SW-DP serial interface until it has clocked out at least 8 more clock rising edges, before stopping the clock.

Overview of debug interface

This section gives an overview of the physical interface used by the SW-DP.

Line interface

The SW-DP uses a serial wire for both host and target sourced signals. The host emulator drives the protocol timing, that is, only the host emulator generates packet headers.

The SW-DP operates in synchronous mode, and requires a clock pin and a data pin.

Synchronous mode uses a clock reference signal that can be sourced from an on-chip source and exported, or provided by the host device. The host uses this clock as a reference for generation and sampling of data so that the target is not required to perform any over-sampling.

Both the target and host are capable of driving the bus HIGH and LOW, or tri-stating it. The ports must be able to tolerate short periods of contention to enable for loss of synchronization.

Line pull-up

Both the host and target are able to drive the line HIGH or LOW, so it is important to ensure that contention does not occur by providing undriven time slots as part of the hand over. So that the line can be assumed to be in a known state when neither is driving the line, a 100kΩ pull-up is required at the target, but this can only be relied on to maintain the state of the wire. If the wire is tied LOW and released, the pull-up resistor eventually brings the line to the HIGH state, but this takes many bit periods.

The pull-up is intended to prevent false detection of signals when no host device is connected. It must be of a high value to reduce IDLE state current consumption from the target when the host actively pulls down the line.


Whenever the line is tied LOW, this results in a small current drain from the target. If the interface is left connected for extended periods when the target must use a low-power mode, the line must be held HIGH, or reset, by the host until the interface must be activated.

Line turn-round

To avoid contention, a turnaround period is required when the device driving the wire changes.

Idle and reset

Between transfers, the host must either drive the line LOW to the IDLE state, or continue immediately with the start bit of a new transfer. The host is also free to leave the line HIGH, either driven or tri-stated, after a packet. This reduces the static current drain, but if this approach is used with a free running clock, a minimum of 50 clock cycles must be used, followed by a read ID as a new reconnection sequence.

There is no explicit reset signal for the protocol. A reset is detected by either host or target when the expected protocol is not observed. It is important that both ends of the link become reset before the protocol can be restarted with a reconnection sequence. Resynchronization following the detection of protocol errors or after reset is achieved by providing 50 clock cycles with the line HIGH, or tri-state, followed by a read ID request.

If the SW-DP detects that it has lost synchronization, for example, if no stop bit is seen when expected, it leaves the line undriven and waits for the host to either re-try with a new header after a minimum of one cycle with the line LOW, or signals a reset by not driving the line itself. If the SW-DP detects two bad data sequences in a row, it locks out until a reset sequence of 50 clock cycles with DBGDI HIGH is seen.

If the host does not see an expected response from SW-DP, it must permit time for SW-DP to return a data payload. The host can then retry with a read to the SW-DP ID code register. If this is unsuccessful, the host must attempt a reset.

Transfer timings

This section describes the interaction between the timing of transactions on the serial wire interface, and the DAP internal bus transfers. The section describes when the target responds with a WAIT acknowledgement.

An access port access results in the generation of a transfer on the DAP internal bus. These transfers have an address phase and a data phase. The data phase can be extended by the access if it requires extra time to process the transaction, for example, if it must perform an AHB access to the system bus to read data.

Table 4.2 shows the terms used in Figure 4.7 through Figure 4.9.

Table 4.2. Terms used in SW-DP timing
W.APACCWrite a DAP access port register.
R.APACCRead a DAP access port register.
xxPACCRead or write, to debug port or access port register.
WD[0]First write packet data.
WD[-1]Previous write packet data. A transaction that happened before this timeframe.
WD[1]Second write packet data.
RD[0]First read packet data.
RD[1]Second read packet data.

Figure 4.7 shows a sequence of write transfers. It shows that a single new transfer, WD[1], can be accepted by the serial engine, while a previous write transfer, WD[0], is completing. Any subsequent transfer must be stalled until the first transfer completes.

Figure 4.7. SW-DP to DAP bus timing for write

Figure 4.7. SW-DP to DAP bus timing for write

Figure 4.8 shows a sequence of read transfers. It shows that the payload for an access port read transfer provides the data for the previous read request. A read transfer only stalls if the previous transfer has not completed, therefore the first read transfer returns undefined data. It is still necessary to return data to ensure that the protocol timing remains predictable.

Figure 4.8. SW-DP to DAP bus timing for read

Figure 4.8. SW-DP to DAP bus timing for read

Figure 4.9 shows a sequence of transfers separated by IDLE periods. It shows that the wire is always handed back to the host after any transfer.

Figure 4.9. SW-DP idle timing

Figure 4.9. SW-DP idle timing

After the last bit in a packet, the line can be LOW, or Idle, for any period longer than a single bit, to enable the Start bit to be detected for back-to-back transactions.

SW-DP multi-drop support

The SW-DP implements the multi-drop extensions defined as part of Serial Wire protocol version 2 in the ARM Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2. This enables multiple SW-DP implementations supporting multi-drop extensions to share a single target connection.

The multi-drop extensions are fully backwards compatible. All targets are selected following a Wire Reset, and remain selected unless a TARGETSEL command is received that selects a single target.

Each target must be configured with a unique combination of target ID and instance ID, to enable a debugger to select a single target to communicate with:

  • The target ID is a 32-bit field that uniquely identifies the system accessed by the SW-DP.

  • The instance ID is a 4-bit field that is used to distinguish between multiple instances of the same target in a system, for example, because the same chip is used more than once on a board.

The multi-drop extensions do not enable the target ID and instance ID of targets to be read when multiple targets share a connection. The debugger must either be programmed with the target ID and instance ID of each target in advance, or must iterate through a list of known of target IDs and instance IDs to discover which targets are connected.

Target ID

The SW-DP target ID is configured using a 32-bit input to the SW-DP, targetid[31:0]. Table 4.3 shows how it must be connected.

Table 4.3. TARGETID input connections
[31:28]Revision The revision of the part. This field is not used when selecting a target.
[27:12] Part numberIdentifies the part.
[11:1]Designer Identifies the designer of the part. The code used is assigned by JEDEC standard JEP-106 as used in IEEE 1149.1 and CoreSight identification registers. Bits[11:8] identify the bank, and bits[7:1] identify the position within that bank.
[0] ReservedMust be HIGH.

The target ID must be configured even in systems where multi-drop operation is not required, because it can be used for more part identification. In most cases, it can be configured with the same information provided in the DAP ROM table identification registers described in Chapter 3 Programmers Model. Table 4.4 shows the ROM table identification registers map to the target ID.

Table 4.4. TARGETID mapping
TARGETIDROM table register
[31:28]Peripheral ID2 [7:4]
[27:24]Peripheral ID1 [3:0]
[23:16]Peripheral ID0 [7:0]
[15:12]Drive LOW
[11:8]Peripheral ID4 [3:0]
[7:5] Peripheral ID2 [2:0]
[4:1] Peripheral ID1 [7:4]
[0]Drive HIGH

Instance ID

The SW-DP instance ID is configured using a 4-bit input to the SW-DP, instanceid[3:0]. If multiple targets with the same target ID might share a connection, instanceid must be driven differently for each target, for example by using non-volatile storage configured differently for each target. In most cases, you can tie this input as LOW.