SWD协议详解：从寄存器访问时序到调试器连接故障排查

开始调试一个全新的 ARM 板子，或者是正在调试的板子突然连不上调试器，大多数人的第一反应是先检查接线，然后怀疑目标板供电，实在不行就把目标板电断了重来。但如果你问过自己：SWD 协议究竟在线上是怎么跑的？为什么明明确认了 SWDIO 和 SWCLK 没有接反，Keil 还是提示RDDI-DAP Error？这背后其实不是运气问题，而是对协议层的理解问题。这篇文章我就把 SWD 协议中寄存器操作的整套逻辑拆开讲，重点放在时序图上，结合我这几年在各种 ARM Cortex-M 平台上调试器连不上的真实经历，把每个寄存器的访问周期是怎么在 SWCLK 和 SWDIO 上流动的讲清楚。适合两类人看：一是被调试器连接问题折磨过的嵌入式开发，二是打算自己写 SWD 主机逻辑、想彻底搞懂底层协议的人。

1. 为什么我在用过一阵 JTAG 之后，转头把 SWD 的报文结构摸了个透

1.1 从四条线变两条线，换来的不只是体积

JTAG 调试接口在 ARM 平台上已经存在很多年，TMS、TCK、TDI、TDO 四根线加上若干控制线，接起来非常占地方。后来 ARM 在 Cortex-M 系列上推广 SWD 调试接口，物理上只需要 SWCLK 和 SWDIO 两根线，这基本是板上钉钉的优势。很多六脚或者十脚的调试座，排开电源和地，真正在跑的其实也就是这两根信号。

省一排引脚只是表象。SWD 协议本身是半双工的单线数据传输，SWDIO 这根线既要承担主机发出请求的命令，又要承担目标芯片回复的数据。这种半双工的行为和 JTAG 的全双工 TDI/TDO 设计思路完全不同，由此带来的信号方向切换、应答机制和位时序安排，才是深入理解 SWD 的真正价值所在。我身边不少同事在用 SWD 调试一年多以后，遇到“偶尔连接失败”“下载一半断开”这种问题仍然只能靠换线、降频这些土办法解决，很大程度就是因为没吃透协议层。

1.2 协议细节不清楚，排查问题就靠猜

在嵌入式开发中，如果只是用现成的 J-Link、DAPLink 调试器，上层软件是 OpenOCD 还是 Keil 都不需要知道协议细节。但问题在于，调试器无法连接的现象往往五花八门：有的板子冷启动能连上，热复位就连不上；有的调试器换了一根线就正常；有的板子放了一会儿第一次能连，第二次就报错。这些现象如果从协议层去理解，很容易找到根因，比如复位时序不对、SWDIO 线上的上拉电阻缺失、目标芯片在连接过程中没有足够的时钟周期来完成初始化等。如果不懂协议，面对这些问题只能逐个试错，效率极低。

所以我一直建议身边做嵌入式固件的人，即使日常只是点击调试按钮，也要把 SWD 的报文结构、寄存器访问链路、时序帧这几件事弄清楚。这不仅是为了排查连接问题，更直接的价值在于：当你想在产线上做一个自动烧录工具，或者想在 Bootloader 里增加固件升级时的调试信息输出，又或者想用单片机的 GPIO 模拟出一个 SWD 主机去给另一颗芯片烧录时，这些协议细节就是你的底层基础。

1.3 SWD 适合谁，以及读完你能带走什么

如果你正在做 STM32、GD32、NXP 等各类 Cortex-M 平台的裸机或 RTOS 开发，这篇文章里涉及的连接时序、DP/AP 寄存器访问方式，能在你遇到调试器通信异常时提供一套完整的排查思路。如果你正在研究如何让一颗 MCU 通过 GPIO 模拟 SWD 协议去烧录另一颗 MCU，这篇文章中关于数据包格式、翻转周期、奇偶校验的说明，可以直接照着做。

2. SWD 的物理信号与报文格式，先把每一 bit 的来龙去脉搞清楚

2.1 两根线上的电平约定

SWD 接口在工作时由主机（调试器）产生 SWCLK 时钟，目标芯片作为从机接收时钟并响应数据。SWDIO 是双向数据线，方向由主机通过协议中的 turnaround 周期来控制。SWCLK 提供位同步时钟，所有数据采样都在时钟上升沿或者下降沿完成，具体采样沿取决于协议传输阶段。网络上关于 SWD 采样的说法并不统一，实际标准中主机在输出数据时通常在 SWCLK 上升沿之后改变 SWDIO，目标芯片在上升沿采样，而主机读取目标数据时则是在上升沿之后释放总线、在紧接着的周期内采样。如果 GPIO 模拟时没有处理好这个边沿关系，很容易出现首字节错误或奇怪的偶发失败。

除了两根信号线，规范的连接还要求共地。SWDIO 建议有上拉电阻，SWCLK 建议有下拉电阻，很多 MCU 内部已经集成了这些电阻，但如果你用的是自己设计的板子，外部加上 100k 左右的上拉下拉会让系统更稳定。实际应用中最容易碰到的问题是：目标板由调试器供电，调试器上电时序和目标板复位时序冲突，导致 SWD 主机发出的第一个连接序列时芯片还没完成上电初始化，后续通信自然失败。

2.2 一个完整 SWD 报文由哪些字段组成

SWD 协议里，一次传输由主机发出 8 位数据包请求头（Packet Request）。这 8 位的排列顺序是这样的：

这个 8 位结构是整个 SWD 协议通信的基础。举个例子，如果主机想读取 DP 的 IDCODE 寄存器，寄存器地址是 0x0，此时 APnDP 为 0（表示 DP），RnW 为 1（表示读），地址位 A[2:3] 为 00，那么前 4 位就是 0、0、1、0、0，其中奇偶校验的计算对象是 APnDP=0、RnW=1、A2=0、A3=0，这 4 位里 1 的个数为 1，是奇数，偶校验要求总数为偶数，所以校验位 Parity 应为 1。如果你在做固件模拟时校验位算错，目标芯片会直接不回 ACK，整个通信卡住。这个细节我在实际调试中就踩过坑，当时读 IDCODE 总是不返回数据，用逻辑分析仪把主机发出去的报文抓出来对比才发现校验位恒为 0，怎么调都不对。

2.3 从请求到响应，线上数据如何切换方向

主机发出 8 位请求头之后，协议进入 turnaround 周期，也就是所谓的线切换周期。在 SWD 标准中，默认的 turnaround 周期是一个时钟周期，用 TRN 表示。在这个周期里，主机把 SWDIO 驱动释放，目标芯片接管总线，准备回复 ACK 和数据。这里有个关键点：主机释放总线之后，SWDIO 线上的电平处于外部电阻决定的状态，目标芯片必须在接下来的时钟周期内把 SWDIO 驱动到有效电平并回复 ACK。如果主机配置的 turnaround 周期数不对，比如把默认的 1 改成 0 或者 2，方向切换的窗口就会错位，数据采样就会落到错误的时刻。

目标芯片在收到完整请求头后，会回复 3 位 ACK 响应。ACK 为 001 表示 OK，010 表示 WAIT，100 表示 FAULT。主机收到 ACK 后，如果是写操作，就继续发送 32 位的数据和 4 位 CRC 校验位；如果是读操作，则再次进入 turnaround 周期，由目标芯片输出 32 位数据和 4 位 CRC。整个读操作的线上时序可以概括为：主机发送请求头、线切换、目标回复 ACK、线切换、目标输出 32 位数据、目标输出 4 位校验。每一段方向变化的地方，都需要精确地插入 turn-around 周期，否则就会采样到高阻态或中间态。这也是为什么很多软件模拟 SWD 的代码里，turnaround 的处理往往是 bug 的高发区。

3. DP 和 AP 的寄存器访问链路，搞懂这一层才算真正理解 SWD

3.1 DP 是门户，AP 是走廊，寄存器是房间

SWD 协议设计的精髓是把调试接口分成两层：DP（Debug Port，调试端口）和 AP（Access Port，访问端口）。DP 是主机直接面对的寄存器集合，负责处理连接、复位、状态控制；AP 则是真正访问目标系统内存和外设的通道。主机要读内存地址 0x20000000 处的数据，不是直接发一个“读内存”命令，而是要经由 DP 的寄存器选中 AP，再操作 AP 的寄存器来发起传输。

用一个生活化的类比：DP 是小区大门门口的物业办公室，AP 是通向各栋楼的走廊，你想去某个房间（内存地址），得先到物业办公室（DP）问清楚该走哪条走廊（AP），然后穿过走廊（AP 的寄存器操作）到达房间。这个层级关系如果你没弄清楚，看时序图会一头雾水，因为线上流动的地址位并不是内存地址，而是寄存器编号。

3.2 DP 侧关键寄存器：IDCODE、CTRL/STAT、SELECT、RDBUFF

在 DP 这一层，有几个寄存器几乎是每次连接都要用到的。第一个是 IDCODE，地址为 0x0，只读。它保存着芯片的厂商 ID、型号和版本信息，每次调试器连接时都会先读它来识别目标芯片。在读 IDCODE 的过程中目标芯片无需额外初始化，所以它也被用来验证 SWD 物理连接是否正常。

第二个是 CTRL/STAT，地址为 0x4，包含调试使能、复位控制、错误标志等关键状态位。比如 CTRL/STAT 中的 CSYSPWRUPREQ 和 CDBGPWRUPREQ 位需要被置 1，请求系统电源和调试电源上电，目标芯片只有在这些电源请求被确认后，才能进行后续的内存访问。如果忽略这一步，后面的 AP 访问大概率会返回 FAULT 或者直接无响应。

第三个是 SELECT，DP 地址为 0x8。SELECT 寄存器用于选择当前操作的 AP 和 AP 内的寄存器组（Bank）。它的低 4 位是 APSEL，用于选择 AP 编号，中间几位是 APBANKSEL，用于选择 AP 寄存器组。因为 AP 内部寄存器数量超过 4 个，而 DP 地址位只有 A[2:3] 两位，所以需要 SELECT 配合才能选中具体的 AP 寄存器。很多人第一次看到 SWD 连接过程的日志里出现大量对 0x8 的写操作，不明白在做什么，其实就是调试器在切换 AP Bank。

第四个是 RDBUFF，DP 地址为 0xC，只读。它的作用是缓存上一次 AP 读操作的结果。在 SWD 协议中，AP 的读操作如果立即返回数据，效率很低，标准设计是：主机发起读请求，目标芯片在下一个读周期才把数据真正返回，RDBUFF 就是用来完成这个流水线的。所以你会发现，调试器在读完数据之后，总会再多读一次 RDBUFF，把真正有效的数据取回来。

3.3 AP 侧关键寄存器：CSW、TAR、DRW 的配合

AP 层真正负责和总线打交道。以最常见的 MEM-AP（内存访问端口）为例，它会提供一组寄存器来完成对目标系统总线的读写。其中最核心的就是 CSW、TAR 和 DRW。

CSW（Control/Status Word）寄存器负责配置传输方式，包括传输大小（8 位、16 位、32 位）、地址自动递增、传输模式等。在对内存进行连续读取时，通常会把 CSW 中的地址自动递增位打开，并在 Size 字段设置为 2（表示 32 位传输）。实测下来，如果 Size 字段设置错误，比如要读 32 位数据但配置成 8 位，后面的 DRW 读出来的数据就会完全错乱。

TAR（Transfer Address Register）寄存器存放当前要访问的目标地址。写 TAR 相当于告诉 AP 走廊通向哪个房间。DRW（Data Read/Write Register）则是数据进出的大门。写 DRW 会把数据写到 TAR 指向的地址，读 DRW 会返回 TAR 指向地址的数据。

这三个 AP 寄存器的访问路径是固定的：先通过写 SELECT 选择 AP Bank，再写 CSW 配置传输属性，然后写 TAR 配置目标地址，最后读写 DRW 完成数据传输。任何一种顺序错乱或者漏掉中间某一步，都会导致总线上的访问结果完全不可预期。这也是为什么用 GPIO 模拟 SWD 时，最稳的做法是先把这套流程写成几个固定的函数，比如 swd_write_ap(reg, value) 和 swd_read_ap(reg)，而不是每次都重新拼寄存器序列。

3.4 操作时序中不可忽略的 ACK 等待与重试机制

在寄存器读写的实际操作中，目标芯片并不一定每次都立刻返回 OK。当目标芯片正处于忙状态时，它会回复 WAIT。比如，在写入 TAR 后紧接着发起 DRW 读操作，目标芯片正在等待总线访问完成，此时就可能出现 WAIT。调试器需要做的不是直接放弃，而是在等待一段时间后重试。

我在自己实现 SWD 主机时，采用的重试逻辑是：如果收到 WAIT，就重新发起同一个请求头，最多重试 5 次，每次间隔若干个 SWCLK 周期。如果收到 FAULT，说明发生了协议错误或者访问非法地址，需要去读 CTRL/STAT 明确错误原因，然后清除错误标志再继续。这套逻辑虽然朴素，但在实际烧录器场景下稳定跑过了数万次下载测试。

4. 读内存的时序逐段拆解：SWD 时序图上数据到底怎么走的

4.1 连接初始化：从全零复位到读取 IDCODE

当调试器连上一个新的 MCU 时，第一步不是直接读内存，而是先把 SWD 接口置于已知状态。标准做法是：主机向 SWDIO 线上连续输出至少 50 个时钟周期的高电平，以便把目标芯片的 SWD 接口复位到默认状态。随后输出一个特殊的线复位序列，通常是在 SWCLK 连续 16 个周期内保持 SWDIO 为高电平，这样一个序列可以把目标芯片从其他调试协议模式拉回到 SWD 模式。

复位序列结束后，主机立刻发起一次对 DP IDCODE 的读操作。这次读操作不仅用来获取芯片 ID，更重要的目的是让目标芯片完成一次协议同步。我在实际调试中发现，如果复位序列少了时钟周期，有些芯片的 IDCODE 读出来是全 1 或者全 0，但物理连接却是好的。这时候不要急着换板子，先把复位时高电平脉冲的宽度补足再试，往往就正常了。

下面这段用字符画表示的是 SWD 主机读 IDCODE 时 SWCLK 和 SWDIO 上的简化时序，注意这里只画到 ACK 阶段，后面的 32 位数据没有完全展开：

SWCLK: ___/‾‾\___/‾‾\___/‾‾\___/‾‾\___/‾‾\___/‾‾\___/‾‾\___/‾‾\___/‾‾\___ 请求头bit0 bit1 bit2 bit3 bit4 bit5 bit6 bit7 TRN SWDIO: ___/‾‾\_______/‾‾‾\_____________________________________> (方向切换) start=1 ap=0 rnw=1 addr=00 parity=0 stop=0 park=1 释放总线

4.2 读 IDCODE 的完整请求与响应

前面提到请求头的 8 位序列是1 0 1 0 0 1 0 1，也就是 0xA5 反转后的效果。需要特别指出的是，请求头是按 LSB 首先发送的，所以虽然组合出来的字节是 0xA5，线上依次出现的 bit 顺序是 Start=1、APnDP=0、RnW=1、A2=0、A3=0、Parity=1、Stop=0、Park=1。很多人在分析逻辑分析仪抓到的波形时，把 0xA5 直接当成字节序去解析，结果完全对不上。

请求头发送完之后进入 TRN 周期，主机把 SWDIO 释放为高阻输入，目标芯片在接下来的时钟周期里开始驱动 SWDIO。对于 IDCODE 读操作，目标芯片会回复 3 位 ACK，正常情况为 001。随后再次进入 TRN 周期，目标芯片在接下来的 32 个时钟周期内输出 IDCODE 内容，每个时钟周期对应一个数据位，依然是 LSB 在前。最后目标芯片还会输出 4 位 CRC 校验，主机可以根据这 4 位来校验 32 位数据的完整性。

在实际项目里，我至少见过三次读到错误 IDCODE 的情况，最后定位原因各不相同：有一次是 SWDIO 线上拉电阻缺失，导致 TRN 周期内总线电平漂移；有一次是 SWCLK 频率太高，目标芯片无法保持如此快的响应，把 SWCLK 降到 1MHz 就正常了；还有一次是芯片之前被配置成了 SWD 引脚复用为 GPIO，导致主机连不上，需要先把芯片复位并保持复位状态，在复位释放后的极短时间内发起连接。

4.3 写 SELECT 寄存器，选择 AP 和 Bank

读 IDCODE 成功之后，主机会去请求调试电源，也就是写 CTRL/STAT 寄存器。这个操作的关键是要把 CDBGPWRUPREQ 位置 1，然后反复读 CTRL/STAT，直到 CDBGPWRUPACK 位被硬件置 1，表示调试电源已经准备好。在等待电源确认的过程中，目标芯片可能会返回 WAIT，主机需要重试。如果一直收不到 ACK，最常见的原因是目标芯片的调试接口没有供电，或者芯片处于低功耗模式。

电源准备好之后，就要开始访问 AP 了。由于 AP 寄存器通过 SELECT 选择，所以第一步通常是写 DP SELECT 寄存器。比如要把 AP Bank 设为 0，APSEL 设为 0，则写入 SELECT 的值为 0。这个写操作的寄存器地址是 0x8，请求头的 APnDP 为 0，RnW 为 0，地址位 A[2:3] 为 10。需要注意的是，SELECT 本身也是 DP 的寄存器，它地址位的含义和 AP 寄存器不同，不要把 APBANKSEL 和 A[2:3] 搞混。

4.4 写 AP CSW：配置 32 位传输与地址自增

当 SELECT 指向 AP Bank 0 后，主机开始写 AP CSW 寄存器。CSW 在 AP Bank 0 中的偏移是 0x0，所以访问它时，DP 请求头中的 APnDP 为 1，RnW 为 0，地址位 A[2:3] 为 00。数据内容通常是 0x00000012，这个值的含义是：最低 3 位设为 010，表示 32 位传输；TransAcc 位为 1，表示使用调试总线访问；有些实现还会把地址自增相关的位一并配置。

从时序上看，写 AP CSW 的过程是这样的：主机发送 8 位请求头，之后仍然要经过 TRN 周期，但目标芯片只需要回复 3 位 ACK，而不需要返回数据。ACK 为 OK 后，主机再次接管总线和发起数据阶段。从请求头结束到数据阶段开始之间，其实存在两个方向切换点：第一次是主机释放总线让芯片回复 ACK，第二次是芯片释放总线让主机输出数据。如果 turnaround 配置不当，这两个点最容易产生毛刺。

4.5 写 AP TAR：把目标内存地址告诉 AP

CSW 配置好之后，接下来写 AP TAR，把要访问的内存地址写入。TAR 在 AP Bank 0 中的偏移是 0x4，所以请求头中 APnDP=1、RnW=0、地址位 A[2:3]=01。例如要读 0x20000000 地址处的数据，就写入 TAR=0x20000000。

在这步操作中，主机只是把地址值发给了 AP，并不会立刻触发总线访问。真正的总线读操作发生在后续读 DRW 时。因为 MEM-AP 通常支持写 TAR 后自动递增地址，所以在连续读取场景中，只需要在第一轮设置 TAR，之后每读一次 DRW，TAR 就会自动指向下一个地址。

4.6 读 AP DRW：数据返回的完整时序链

现在到了核心环节：读 DRW，从目标内存地址取回数据。DRW 在 AP Bank 0 中的偏移是 0xC，请求头中 APnDP=1、RnW=1、地址位 A[2:3]=11。这时完整时序是：

主机: 8位请求头 -> TRN -> 等待ACK -> TRN -> 等待32位数据 -> 等待4位CRC 目标: ACK(3bit) 32位数据(LSB在前) CRC

但在 SWD 协议中，AP 读操作的实际执行有一个延迟特性。数据并不是在同一个读周期内返回的，而是会在下一个读操作时通过 RDBUFF 返回。因为 AP 需要一定时间到目标总线上完成实际的数据读取。所以标准流程是：读一次 DRW，丢弃这次返回的旧数据；再读一次 RDBUFF 或者再次读 DRW，才能拿到当前地址的有效数据。我在自己用逻辑分析仪调试时，第一次读 DRW 拿到的往往是上一次 RDBUFF 里残留的内容，如果不了解 SWD 的缓存机制，很容易怀疑是硬件不稳定。

下面以更完整的方式画出一次读 DRW 加一次读 RDBUFF 的链路：

1) 读DRW请求: 1 1 1 1 1 Parity Stop Park | TRN | ACK=001 | TRN | 数据(无效) | CRC 2) 读RDBUFF: 1 0 1 1 0 Parity Stop Park | TRN | ACK=001 | TRN | 数据(有效) | CRC

这种双阶段读法在实际调试器代码里很常见，也是理解 SWD 高效读内存的关键。

4.7 多条时序交织后的整体观察

把上面这些步骤串起来看，一次普通的内存读操作，线上流动的是这样一系列帧：读 IDCODE、写 CTRL/STAT、读 CTRL/STAT（确认电源）、写 SELECT、写 AP CSW、写 AP TAR、读 AP DRW、读 RDBUFF。这 8 个帧组合在一起，才完成了一个有效数据的读取。很多希望提升烧录速度的人试图优化协议，最后发现瓶颈恰恰在固定访问模式上，该有的步骤一个都省不掉，只能在时钟频率和 turn-around 配置上做文章。

5. 连接失败与数据错乱，按这套排查顺序去定位

5.1 先从物理层找问题

SWD 连不上时，我最先看的是三样东西：共地是否良好、SWCLK 是否有时钟输出、SWDIO 在复位期间是否为高电平。实际排查中，因为地线接触不良导致的连接失败概率非常高，高频数字信号对地弹非常敏感，共地不好，波形就是一团糟。如果你用的是杜邦线连接，优先换短线或者直接用焊接的飞线，如果没有改善，再用示波器观察 SWCLK 和 SWDIO 的波形。

其次要检查目标芯片的供电。SWD 调试接口虽然只有两根数据线，但它的逻辑电平参考是目标芯片的电压域。如果调试器电平是 3.3V，而目标芯片是 1.8V，又没有加电平转换，通信失败是必然的。使用 J-Link 这类调试器时，对目标板供电的跳线帽一定要仔细确认，避免调试器与目标板供电冲突。

5.2 用 IDCODE 作为连接试金石

物理连接看起来正常，但依旧连不上时，我建议把连接步骤简化到只读 IDCODE，这是验证链路是否通的最高效方式。用逻辑分析仪抓取波形，检查主机发出的是不是 0xA5 序列，检查 ACK 是不是 001，再检查 IDCODE 数据是否正确。如果波形显示主机每次只发出请求头，而目标芯片没有任何 ACK 回应，那大概率是目标芯片没有进入调试模式，或者 SWD 引脚被禁用。

还有一种很有意思的情况：目标芯片在睡眠或者掉电模式下，SWD 接口不会响应任何请求。你需要先把芯片唤醒，或者用硬件复位让芯片重新运行。这时候如果调试器支持复位连接，可以在连接前拉低目标芯片的复位引脚，在复位释放后立刻发起连接请求，很多连不上的板子都能通过这种方式救回来。

5.3 时钟速率不是越高越好

很多人在 SWD 通信不稳定时，第一时间想到的是降频，但实际对 SWD 来说，频率过高导致的问题容易理解：SWDIO 线在 turnaround 周期需要被释放和重新驱动，如果 SWCLK 频率太快，线电容没有足够时间让电平稳定，采样就会出错。我一般建议调试器连接阶段用 1MHz 甚至更低的频率，连接成功并完成初始化后再切换到更高频率。如果你使用的是杜邦线，长度超过 10cm 时，10MHz 以上的 SWCLK 基本就不要想了，除非把线改成屏蔽线或者使用专门的调试排线。

我曾经在调试一块屏幕驱动板时，SWD 连接成功率只有一半，最后发现是 SWCLK 频率设置成了 8MHz，而板上的 SWD 走线经过了两个过孔，信号质量差。把频率降到 2MHz 后，连接稳定，连续下载 100 次没有一次失败。

5.4 读回数据错乱时的排查方向

连接成功了，但读内存回来的数据偶尔不对，这又是另一个层面的问题。这时候优先检查 CSW 的 Size 字段。如果主机实际打算读 32 位，但 CSW 里配置成了 16 位，那得到的数据会截断或者错位。其次检查地址对齐。SWD 的 AP 传输要求地址对齐到传输宽度，如果你要读 32 位数据但地址是 0x20000001，轻则返回错误数据，重则直接产生 FAULT。内存读写代码里对非对齐访问应当显式处理，而不是依赖调试器自动补齐。

第三个常见原因在 AP 读缓存上。如前所述，读 DRW 后必须再多读一次才能取回有效数据。如果你把第一次读到的数据当成真实值，拿到的很可能是上一次访问的残留。这种错误在调试日志里看着像是随机错乱，实际原因是协议流程不对。

6. 在固件里用 GPIO 模拟 SWD 主机，必须处理的几个细节

6.1 方向切换与延时控制

如果要在一颗 MCU 上用 GPIO 模拟 SWD 主机，重点不是怎么发出 8 位请求头，而是怎么精确控制 SWDIO 的方向切换。方向切换的时机发生在：发出请求头之后、等待 ACK 之前；读取 ACK 之后、准备发送写数据之前。每个切换点都要留出足够的延时，让目标芯片和主机都有时间完成总线驱动权的交接。

具体到代码层面，GPIO 模式切换本身在 MCU 上是有消耗的。比如 STM32 的 GPIO 配置寄存器写入需要等待总线周期，如果在切换后立刻进行采样，可能采到的是引脚模式尚未生效时的电平。我通常会在模式切换后加 2 到 3 个空操作时钟周期，保证总线稳定。如果目标芯片和主机之间线缆较长，这个延时还要适当增加。

6.2 奇偶校验和 CRC 计算不能偷懒

前面说到，请求头里的 Parity 位是对 APnDP、RnW、A[2:3] 这 4 个位的偶校验。写操作时，32 位数据后还要附带 4 位 CRC。这 4 位 CRC 是基于 32 位数据的校验信息，具体算法是 ITU-T 标准的 CRC 校验，和很多通信协议里用的不太一样。如果你只是想快速验证，可以先忽略 CRC 校验，因为目标芯片是否强制校验取决于实现，但要注意某些芯片在 CRC 错误时会直接报 FAULT 或者忽略数据。可靠的实现一定要把 CRC 计算函数写好，并且做一轮回环验证：让主机发出的数据和 CRC 通过逻辑分析仪抓回来，用同一个校验函数重新计算，确认一致。

6.3 ACK 监听与错误重试

GPIO 模拟 SWD 主机时，收到目标芯片 ACK 后要立即判断：是 OK、WAIT 还是 FAULT。WAIT 的情况在目标芯片忙时很常见，我的策略是重发请求头，最多重试 3 次；每次重试前让 SWCLK 保持几个周期的空闲，给目标芯片一点时间。FAULT 则需要读 CTRL/STAT 的 STICKYERR 位来定位错误类型，然后写 1 清除错误标志。如果目标芯片一直不返回任何 ACK，除了检查物理连接，还要检查 SWDIO 在等待 ACK 期间是否被宿主机的内部上拉影响，导致采样一直读到高电平。

6.4 扩展一个实用小技巧：用 SWO 辅助调试

最后分享一个和 SWD 紧密相关的经验。很多 Cortex-M 芯片除了 SWD 的两根线，还支持 SWO 引脚，它可以在程序运行时输出调试信息，比如 ITM 的 printf 数据。用 SWD 连接时，只需要再引一根 SWO 到调试器，就能在不打断程序的情况下观察内部状态。这个功能在我调试实时性要求高的代码时非常有用，程序跑飞时也能从总线数据里定位最后执行的指令。如果你正在做高可靠性产品的移植，建议把 SWO 的配置也纳入调试环境，它能让你对 SWD 协议的理解多一个实际应用出口。

用 GPIO 模拟 SWD 这段经历，我最大的心得是：协议细节不能只靠看文档，要在实际抓到的波形里去验证每一个假设。只有自己把请求头、ACK、数据、校验每一段的实际表现对齐了，才算真正把这个协议吃透。这套经验后来被我应用到产线的芯片烧录器固件里，长期运行下来非常稳定，也让我在面对各种 SWD 通信异常时有了清晰的排查思路，而不是靠玄学调参。