Understanding the SWD Debug Interface Protocol

Scan to FollowLearn Embedded Systems Together, learn and grow together

Overview

1.1 What is the SWD Protocol

SWD (Serial Wire Debug) is a two-wire debugging interface protocol developed by ARM, specifically designed for debugging and programming Cortex-M series microcontrollers.

As a replacement for the traditional JTAG interface, SWD significantly reduces the number of pins while maintaining powerful debugging capabilities, making it the mainstream choice for embedded system debugging.

1.2 Development History

The SWD protocol has evolved with the introduction of Cortex-M processors:

• 2006: First introduced with Cortex-M3
• Subsequent versions gradually improved, supporting more features
• It has now become part of the ARM debugging interface standard

1.3 Comparison of SWD and JTAG

Feature	SWD	JTAG
Number of Pins	2 wires (minimum configuration)	4 wires (minimum)
Speed	Higher	Medium
Wiring Complexity	Low	Higher
Functionality Integrity	Complete debugging functionality	Full functionality
Applicable Scenarios	Cortex-M series	Widely applicable

Physical Layer

2.1 Interface Pin Definitions

The standard SWD interface includes the following signals:

1. SWDIO (Serial Wire Debug I/O):

• Bidirectional data line
• Open-drain or push-pull output configuration
• Typically requires a pull-up resistor

SWCLK (Serial Wire Debug Clock):

• Clock signal provided by the debugger
• Typical frequency 1MHz-50MHz
• Data sampled on the rising edge

Optional Pins:

• RESET: System reset
• VREF: Reference voltage
• SWO: Serial Wire Output (for tracing)

2.2 Electrical Characteristics

• Voltage levels: Typically 1.2V-3.3V (consistent with the target system)
• Maximum clock frequency: Depends on the target device (usually up to 50MHz)
• Input impedance: High impedance (typically >100kΩ)
• Driving capability: Able to drive at least 20pF load

Data Link Layer

3.1 Basic Communication Format

SWD communication is based on a request-response model, with each transaction consisting of:

1. Request packet sent by the host (debugger)
2. Response from the target device
3. Data transfer (read or write)

3.2 Data Frame Structure

Request Packet (8 bits):

Start Bit(1) | Transfer Direction(1) | APnDP(1) | Address A[2:3](3) | Parity(1) | Stop Bit(1) | Idle Between Packets(1)

• Start Bit: Fixed at 1
• Transfer Direction: 1=write, 0=read
• APnDP: 0=DP access, 1=AP access
• Address A[2:3]: Address bits 2 and 3
• Parity: Make the count of 1s odd

Response Packet (3 bits):

Response(3) | Idle(1)

Response Types:

• OK(001): Success
• WAIT(010): Retry
• FAULT(100): Error
• Others: Reserved

3.3 Data Transfer Timing

1. Host sends request packet (8 SWCLK cycles)
2. Target returns response (3 SWCLK cycles)
3. If it is a read operation, target returns data (32 bits + parity)
4. If it is a write operation, host sends data (32 bits + parity)
5. Final idle cycle

Transaction Types

4.1 Debug Port (DP) Access

DP registers include:

• CTRL/STAT (0x0): Control status register
• SELECT (0x8): Select current AP and register
• RDBUFF (0xC): Read buffer

4.2 Access Port (AP) Access

After selecting AP through the DP’s SELECT register, the following can be accessed:

• AP registers (0x0-0xC)
• Memory-mapped registers

4.3 Typical Transaction Flow

1. Initialize connection (send at least 50 SWCLK cycles high)
2. Send SWD switch sequence (16-bit 0xE79E)
3. Read DP’s IDCODE register to verify connection
4. Configure DP and AP registers
5. Perform memory access or debugging operation

Initialization and Connection Establishment

5.1 Connection Sequence

1. After power-up, hold high for at least 50 SWCLK cycles
2. Send SWD switch sequence (16-bit 0xE79E)
3. Send SWD reset request (0xFFFFFFFF)
4. Send SWD switch sequence again
5. Read IDCODE to verify connection

5.2 Line Reset

When communication issues arise, the following can be sent:

• At least 50 SWCLK cycles high
• Or send more than 8 consecutive 1s (causing protocol error)

SWD Debug Architecture

6.1 Overview of CoreSight Architecture

SWD is part of the ARM CoreSight debug architecture, which includes:

• Debug Access Port (DAP)
• Multiple Access Ports (AP)
• Memory-mapped debug components

6.2 Debug Components

1. Flash Patch and Breakpoint (FPB): Hardware breakpoints
2. Data Watchpoint and Trace (DWT): Data watchpoints
3. Instrumentation Trace Macrocell (ITM): Software tracing
4. Embedded Trace Macrocell (ETM): Instruction tracing

SWD Performance Optimization

7.1 Methods to Improve Transfer Efficiency

1. Use appropriate clock frequency (typically 10-20MHz is best)
2. Keep AP selection unchanged during bulk transfers
3. Utilize automatic address increment feature
4. Use polling and waiting judiciously

7.2 Error Handling Mechanisms

1. Wait and retry on response errors
2. Reduce clock frequency on consecutive errors
3. Reinitialize connection on severe errors
4. Use DP’s ABORT register to clear error states

Practical Applications

8.1 Typical Debugger Implementations

Modern debuggers such as J-Link and ST-Link support the SWD protocol, typically containing:

• USB interface chip
• SWD protocol processor
• Voltage level conversion circuit
• Debug firmware

8.2 Hardware Design Considerations

1. Keep wiring as short as possible (<15cm)
2. Avoid running parallel to high-frequency signals
3. Add appropriate pull-up resistors (typically 10kΩ)
4. Add buffers if necessary
5. Ensure good power decoupling

8.3 Common Issue Troubleshooting

1. Unable to Connect:

• Check power and reset signals
• Verify SWDIO/SWCLK connections
• Try reducing clock frequency

Unstable Connection:

• Check signal integrity
• Add appropriate termination resistors
• Shorten cable length

Read/Write Errors:

• Verify target voltage
• Check timing parameters
• Ensure correct AP selection

Conclusion

The SWD protocol, with its simple two-wire design and powerful debugging capabilities, has become the de facto standard for debugging Cortex-M series microcontrollers.

Understanding the working principles and implementation details of the SWD protocol is crucial for embedded system development and debugging.

With the rise of IoT and edge computing, the SWD protocol will continue to play an important role in embedded debugging due to its low pin count and high efficiency advantages.

Follow 【Learn Embedded Systems Together】 to become better together!

If you find this article helpful, click “Share”, “Like”, or “Recommend”!