4.2.5. 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. See the ARM® Debug Interface Architecture Specification, ADIv5.0 to ADIv5.2

Implementation-specific information

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 eight more clock rising edges, before stopping the clock.

Overview of debug interface

This section describes the physical interface that the SW-DP uses.

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 so that it can handle 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 host nor target 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 over an extended period with the target in low-power mode, the host must hold the line HIGH until the interface is re-activated.

Line turn-round

To avoid contention, a turnaround period is required whenever 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 request that initiates 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 are reset restarting the reconnection sequence that restarts use of the protocol. 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 allow 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.

Access port accesses result in the generation of transfers 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.4 to Figure 4.6.

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.4 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.4. SW-DP to DAP bus timing for write

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.

Figure 4.5 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, in which case the first read transfer returns undefined data. It is still necessary to return data to ensure that the protocol timing remains predictable.

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

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.

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

Figure 4.6. SW-DP idle timing

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.

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 distinguishes 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 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 part identification. For more information on how to define the target ID, see the ARM® CoreSight™ SoC-400 System Design Guide.

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.

Copyright © 2011-2013 ARM. All rights reserved.ARM DDI 0480F