SWD协议深度解析：从物理层到DP/AP寄存器实战

1. 项目概述：为什么SWD协议值得你花时间啃透

“调试备忘录-SWD协议解析”这个标题看起来平平无奇，甚至有点老派——没有炫酷的AI前缀，也没有“零基础速成”这类流量钩子。但如果你正在STM32、NXP i.MX RT、RISC-V MCU或任何基于ARM Cortex-M内核的嵌入式项目里卡在“烧不进程序”“断点不命中”“寄存器读出来全是0xAAAAAAAA”这类问题上，那这份备忘录不是可选项，而是你手边最该打开的一页纸。SWD（Serial Wire Debug）不是某种高级调试技巧，它是现代MCU开发中默认启用、底层支撑、却极少被真正理解的通信骨架。它比JTAG引脚更少（仅需SWDIO+SWCLK两根线），比UART调试更底层（直接操作CPU核心寄存器），比GDB命令更原始（GDB背后调用的正是SWD驱动）。我做过不下20个量产级MCU项目，从消费电子到工业PLC，凡是调试链路出问题，70%以上根源不在代码逻辑，而在SWD握手失败、时序错位、寄存器镜像失同步这些“看不见的层”。比如你用ST-Link V3烧录STM32H7，突然报“Target not connected”，换根杜邦线就恢复——这不是运气，是SWD信号完整性在说话；再比如你在FreeRTOS任务里读取SysTick->VAL寄存器，值始终为0，查半天发现是调试器未正确使能Debug Halting Control寄存器（DHCSR），而这个动作必须通过SWD写入——这就是协议层缺失导致的“功能存在但不可见”。本备忘录不讲抽象理论，只拆解真实调试现场：SWD物理层怎么抗干扰、协议帧如何构造、AP/DP寄存器怎么寻址、为什么SWDIO要开漏输出、SWCLK频率为何不能超过目标芯片标称值的1/4……所有内容都来自我焊过板子、测过示波器、抓过逻辑分析仪的真实记录。适合刚拿下第一个STM32点亮LED的新手，也适合被客户现场“复位后无法连接”问题逼到凌晨三点的资深工程师。它不教你用Keil还是VS Code，但能让你看懂J-Link日志里那行“SWD ACK WAIT”到底在等什么。

2. SWD协议设计思路与核心逻辑拆解

2.1 为什么放弃JTAG，选择SWD？——资源、速度与可靠性的三重博弈

很多人以为SWD是JTAG的简化版，这是典型误解。SWD不是“阉割”，而是针对MCU场景的精准重构。JTAG标准定义了TCK/TMS/TDI/TDO四根线，支持边界扫描（Boundary Scan）和调试（Debug）双模式，但MCU开发中，边界扫描几乎不用——你不会拿万用表去测PCB走线连通性，而是直接用示波器看信号。SWD砍掉TMS/TDI/TDO，只保留SWDIO（双向数据线）和SWCLK（时钟线），物理层精简50%，这对引脚紧张的QFN24封装MCU（如GD32E230）是救命稻草。但精简不等于降级：SWD协议层反而更高效。JTAG的IR（Instruction Register）和DR（Data Register）需要多轮移位才能完成一次寄存器访问，而SWD用事务原子化设计：一个完整的读/写操作，只需发送1个请求帧（Request Packet）+ 1个确认帧（ACK）+ 数据帧（Data Packet），总线占用周期比JTAG少40%以上。实测数据：在STM32F407上，SWD读取一个32位系统控制寄存器（SCB->ICSR）耗时约1.8μs，JTAG同类操作需2.9μs。更关键的是可靠性。JTAG的TMS线负责状态机切换，若受干扰产生毛刺，整个状态机可能跳转到未知态，导致调试器“失联”；SWD则采用握手机制：每次传输后，目标端必须返回ACK（OK/FAULT/WAIT），主机收到WAIT才重发，FAULT则触发错误处理流程。这就像快递员送件，JTAG是“扔下就走”，SWD是“签收才算送达”。我在做一款车载OBD设备时，EMC测试中JTAG频繁断连，换成SWD后通过率从65%提升至98%——因为SWDIO的开漏输出配合上拉电阻，天然具备抗共模干扰能力，而JTAG的推挽输出对电源噪声更敏感。所以SWD不是“够用就好”，它是ARM官方为MCU场景量身定制的调试协议，其设计哲学是：用最少的硬件资源，换取最高的通信确定性。

2.2 SWD协议栈分层：从物理层到寄存器访问的完整映射

理解SWD，必须跳出“它就是一根下载线”的思维。它是一个完整的五层协议栈，每一层都解决特定问题：

• 物理层（Physical Layer）：定义SWDIO/SWCLK的电气特性。SWDIO必须为开漏（Open-Drain）输出，外接1kΩ~10kΩ上拉电阻至目标VDD（非调试器VDD！），这是为了兼容不同电压域（如调试器3.3V，MCU核心1.2V）。SWCLK为推挽输出，频率范围通常为100kHz~50MHz，但实际可用上限由目标芯片手册明确限定（如STM32L4系列最大支持24MHz，超频会导致ACK丢失）。我曾因忽略这点，在STM32L476上将SWCLK设为32MHz，结果所有寄存器读写返回0xFAFAFAFA——这是SWD协议规定的FAULT响应码。

• 数据链路层（Data Link Layer）：处理帧结构与错误检测。SWD最小通信单元是事务（Transaction），包含请求帧（Request）、确认帧（ACK）和数据帧（Data）。请求帧长8位，格式为[START][APnDP][RnW][ADDR[3:2]][PARITY][STOP]，其中APnDP=1表示访问AP（Access Port，即外设寄存器），RnW=1表示读操作；ADDR[3:2]是地址高2位，决定访问DP还是AP的哪个寄存器。这里有个易错点：ADDR[3:2]不是完整地址，而是寄存器组索引，比如DP的CTRL/STAT寄存器地址为0x0，AP的CSW寄存器地址为0x0，全靠APnDP位区分。ACK帧3位，值为0b001（OK）、0b010（WAIT）、0b100（FAULT），主机必须严格解析，不能只看是否非零。

• 访问层（Access Layer）：定义DP（Debug Port）和AP（Access Port）的寄存器模型。DP是调试器与芯片的“总控台”，含4个核心寄存器：SELECT（选择AP）、CTRL/STAT（控制状态）、RESEND（重发请求）、ABORT（中止操作）。AP则是“外设代理”，每个AP对应一个物理外设（如Cortex-M的CoreSight AP、Flash编程AP），含CSW（Control Status Word）、TAR（Transfer Address）、DRW（Data Read/Write）等寄存器。关键逻辑是：所有对MCU内部寄存器（如GPIOA->ODR、NVIC->ISER）的访问，必须先通过DP选择AP，再通过AP的TAR设置目标地址，最后用DRW读写。这就像寄快递：DP是邮局柜台（SELECT选哪个窗口），AP是分拣中心（CSW设分拣模式），TAR是收件人地址（目标寄存器地址），DRW是包裹内容（数据）。

• 调试抽象层（Debug Abstraction Layer）：将AP访问映射到CPU核心行为。当AP执行对CoreSight AP的访问时，实际触发的是ARM CoreSight架构的调试逻辑，如写入DEMCR寄存器使能DWT（Data Watchpoint and Trace）单元，或读取DHCSR获取当前CPU halted状态。这一层隐藏了硬件细节，让GDB等工具只需发“read memory 0xE000ED04”指令，底层自动转换为SWD事务序列。

• 应用层（Application Layer）：即我们日常使用的调试器软件（J-Link Commander、OpenOCD、ST-Link Utility）。它们将用户操作（如点击“Reset and Run”）翻译为DP/AP寄存器操作序列：先写DP_ABORT清异常，再写AP_CSW设访问宽度，写AP_TAR设复位向量地址0x00000000，最后写AP_DRW触发复位脉冲。

这种分层设计的意义在于：当你遇到“SWD connect failed”时，可以逐层排查——示波器看SWCLK有无波形（物理层）→逻辑分析仪抓SWDIO波形看ACK是否为0b001（数据链路层）→用J-Link Commander手动读DP_CTRL/STAT寄存器（访问层）→检查GDB配置是否匹配芯片型号（应用层）。而不是盲目换线、重启调试器。

2.3 SWD与JTAG的协议级差异：不只是引脚数量的区别

常有人问：“SWD和JTAG能混用吗？”答案是：物理层不兼容，协议层不可互译。这不是接口转换问题，而是根本性设计差异。JTAG的状态机有16个状态（Test-Logic-Reset, Run-Test/Idle, Select-DR-Scan等），靠TMS线电平序列驱动；SWD只有3个核心状态：Line Reset（拉低SWDIO+SWCLK至少50个周期）、Idle（空闲）、Transfer（数据传输）。更本质的区别在于寻址机制：JTAG用IR（Instruction Register）预设操作类型（如SAMPLE/PRELOAD用于读引脚，EXTEST用于边界扫描，IDCODE用于读芯片ID），再用DR（Data Register）传输数据；SWD则将操作类型编码进请求帧的RnW和ADDR位，无需预设指令。这意味着JTAG调试器必须预先知道目标芯片的IR长度（如ARM Cortex-M3为4位，Cortex-M4为5位），而SWD调试器只需识别DP/AP寄存器布局即可适配所有ARMv7-M/v8-M内核。实操中，这带来两个直接影响：第一，SWD调试器固件升级成本更低——新增一款MCU，只需更新AP寄存器映射表，无需重写状态机；第二，SWD对时序容错更强。JTAG的TCK上升沿采样TMS，若时钟抖动超0.5ns，状态机可能误判；SWD的SWCLK上升沿采样SWDIO，且ACK帧有独立校验，允许±2个周期的时序偏差。我在用国产CH552 USB调试器调试ESP32-C3时，JTAG模式下必须将TCK降至200kHz才能稳定，SWD模式下直接跑12MHz无误码——因为ESP32-C3的SWD物理层做了增强驱动。

3. 核心细节解析与实操要点

3.1 SWD物理连接的黄金法则：从选线上拉电阻到PCB布局

SWD看似只需两根线，但90%的连接失败源于物理层设计失误。这不是玄学，而是有明确电气规范可循。

上拉电阻的选择是首要关卡。常见误区是“随便用10kΩ”，这在实验室可能正常，量产必翻车。计算公式为：
R_pullup ≤ (VDD_target - V_OL) / I_OL
其中VDD_target是目标MCU的VDD（如3.3V），V_OL是SWDIO输出低电平时的电压（典型值0.4V），I_OL是MCU IO口灌电流能力（查数据手册，如STM32F103为20mA）。代入得：R_pullup ≤ (3.3 - 0.4) / 0.02 = 145Ω。但这是理论最小值，实际需留余量。经验法则是：

• 目标VDD ≤ 2.5V：选4.7kΩ~10kΩ（低功耗场景，减小静态电流）
• 目标VDD = 3.3V：选2.2kΩ~4.7kΩ（平衡速度与功耗）
• 目标VDD ≥ 5V：选1kΩ~2.2kΩ（确保上升沿陡峭）

我吃过亏：某项目用10kΩ上拉在3.3V系统，示波器测SWDIO上升时间达800ns，超过SWD协议要求的500ns，导致高速模式（24MHz）下ACK误判为WAIT。换4.7kΩ后，上升时间压至320ns，问题消失。

PCB布局是隐形杀手。SWDIO/SWCLK必须视为高速数字信号，而非普通IO。规则如下：

1. 等长走线：SWDIO与SWCLK长度差≤50mil（1.27mm），避免时序偏移。我曾见一板子SWCLK比SWDIO长2cm，结果在48MHz下完全无法握手。
2. 远离干扰源：与DC-DC开关电源、电机驱动线、USB 2.0差分线保持≥5mm距离。SWD信号幅值仅VDD，而DC-DC噪声可达1Vpp，耦合0.5V就能淹没信号。
3. 就近放置上拉电阻：电阻必须放在MCU SWDIO引脚旁，而非调试器端。否则PCB走线电容会拖慢上升沿。实测：10kΩ电阻离MCU 5cm时，上升时间增加40%。
4. 禁止过孔：SWDIO/SWCLK走线全程不得打过孔。过孔引入0.3pF电容和1nH电感，高频下形成阻抗不连续点。某客户板子因在SWDIO线上打过孔，导致J-Link识别IDCODE失败，飞线绕过过孔后立即正常。

调试器与目标板的供电隔离常被忽视。标准做法是：调试器只提供SWD信号，目标板由独立电源供电。若调试器通过SWDIO的上拉电阻反向供电（即“偷电”），当目标板VDD掉电时，SWDIO可能通过上拉电阻倒灌电流，损坏调试器IO口。正确方案是：在SWDIO线上串联100Ω电阻（限流），或使用带电源检测的调试器（如J-Link PRO）。

3.2 DP/AP寄存器详解：读懂调试器日志的关键

当你看到J-Link日志里出现“Failed to read DP register 0x04”或“AP transaction timeout”，说明已深入协议核心。DP/AP寄存器是SWD的“操作系统内核”，必须烂熟于心。

DP寄存器（Debug Port）是调试器与芯片的“总控台”，共4个，地址固定：

• DP_SELECT (0x0)：32位寄存器，低8位指定AP索引（如AP0=0x00），高8位指定AP内的寄存器组（如Bank0=0x00）。写此寄存器即“切换操作对象”。例如，要访问CoreSight AP的CSW寄存器，需写DP_SELECT = 0x00000000（AP0，Bank0）；要访问Flash编程AP，则写DP_SELECT = 0x00000001（AP1）。

• DP_CTRL_STAT (0x4)：32位控制状态寄存器，是故障诊断的核心。关键位：

  • CSTICKYORUN (bit31)：上次操作是否因超时失败。为1需写1清零。
  • TRNMODE (bits29:28)：传输模式，0b00=32位，0b01=16位，0b10=8位。必须与目标寄存器宽度匹配，否则返回FAULT。
  • MASKLANE (bits23:16)：字节使能掩码，用于8/16位写操作。
  • ORUNDETECT (bit1)：溢出检测使能。

  提示：若CSTICKYORUN持续为1，说明物理层或时序有问题，不是软件配置错误。

• DP_RESEND (0x8)：32位重发寄存器。当ACK为WAIT时，写此寄存器可重发上一请求，避免超时。

• DP_ABORT (0xC)：32位中止寄存器。bit0=DAABORT（数据中止），bit1=APABORT（AP中止），bit3=STKERR（栈错误）。调试器初始化时必写0x0000001E（全中止位清零）。

AP寄存器（Access Port）是“外设代理”，每个AP有独立寄存器组。以最常用的AHB-AP（ARM CoreSight AHB Access Port）为例：

• AP_CSW (0x0)：32位控制状态字，决定访问属性。关键位：
  • SIZE (bits3:2)：0b00=8位，0b01=16位，0b10=32位。必须与目标寄存器宽度一致。
  • PROT (bits15:12)：保护域，0b0010=privileged access（特权访问），调试时必须设此值，否则返回FAULT。
  • ADDRINC (bits1:0)：地址自增模式，0b00=固定地址，0b01=单字节自增，0b10=单字自增（最常用）。
• AP_TAR (0x4)：32位传输地址寄存器，存目标寄存器地址。如读取SCB->ICSR（0xE000ED04），先写AP_TAR = 0xE000ED04。
• AP_DRW (0xC)：32位数据读写寄存器。写此寄存器即向AP_TAR地址写入数据；读此寄存器即从AP_TAR地址读取数据。

实操陷阱：很多新手以为AP_DRW读写的是“数据”，其实它读写的是地址指向的内存或寄存器。例如，要读取GPIOA->ODR（0x4001080C），流程是：

1. 写DP_SELECT = 0x00000000（选AP0）
2. 写AP_CSW = 0x23000012（32位、特权、自增）
3. 写AP_TAR = 0x4001080C（设目标地址）
4. 读AP_DRW→ 返回GPIOA->ODR值

若跳过第2步，AP_CSW保持默认值（0x23000002，非特权模式），则读取返回0xFAFAFAFA（FAULT码）。

3.3 SWD时序参数实战解析：从示波器波形看协议真相

协议文档里的时序图是理想化的，真实世界充满噪声与偏差。用示波器抓SWD波形，是定位疑难问题的终极手段。

关键时序参数（以STM32F407为例，SWCLK=24MHz）：

• tSU_DATA（数据建立时间）：SWDIO在SWCLK上升沿前的稳定时间，最小值2.5ns。实测中，若PCB走线过长，反射导致建立时间不足，表现为ACK误判。
• tH_DATA（数据保持时间）：SWDIO在SWCLK上升沿后的保持时间，最小值2.5ns。
• tR/tF（上升/下降时间）：SWDIO边沿变化时间，最大值10ns。这直接取决于上拉电阻和走线电容。计算公式：tR ≈ 2.2 × R_pullup × C_load，其中C_load为走线电容+MCU输入电容（典型值5pF）。若R_pullup=4.7kΩ，C_load=10pF，则tR≈103ns，远超10ns要求——必须减小R或C。
• tCYCLE（时钟周期）：1/24MHz=41.67ns，因此高/低电平各需≥20.8ns。

抓波形实操步骤：

1. 将示波器探头接地夹接MCU GND，信号钩接SWDIO（或SWCLK）。
2. 设置触发条件：SWCLK上升沿触发。
3. 调整时基至50ns/div，观察一个完整事务（Request+ACK+Data）。

典型故障波形诊断：

• ACK始终为0b010（WAIT）：波形显示SWDIO在ACK时段持续低电平。原因：目标芯片未上电、复位电路异常、SWDIO被其他外设（如SWO调试输出）复用且未关闭。
• ACK随机为0b100（FAULT）：SWDIO在ACK时段出现毛刺。原因：电源噪声耦合、地线环路、SWCLK与SWDIO走线平行走线过长（串扰）。
• Request帧错误：SWDIO在Request时段出现非预期电平。原因：调试器固件bug、目标芯片SWD接口损坏、ESD击穿。

我曾用此法解决一个经典问题：某批量生产的板子，10%概率无法连接。示波器抓取发现，故障板SWDIO在Request帧第3位（RnW位）出现亚稳态——高电平仅维持15ns，低于2.5ns要求。根源是PCB上SWDIO走线经过一个未铺铜的散热焊盘，形成分布电容，导致上升沿变缓。修改PCB铺铜后，问题根除。

4. 实操过程与核心环节实现

4.1 手动构建SWD连接：从零开始验证物理层

当调试器“失灵”时，手动验证是最高效的排障方式。以下是以J-Link Commander为工具的手动连接流程，适用于所有SWD调试器。

步骤1：硬件自检

• 用万用表二极管档测SWDIO与GND间电阻：应为上拉电阻值（如4.7kΩ），若为0Ω说明短路，若为OL说明开路。
• 测SWCLK与GND间电压：应为调试器输出电平（通常3.3V），若为0V说明调试器未供电或损坏。

步骤2：强制复位并检测DP IDCODE
启动J-Link Commander，输入：

J-Link> connect Please specify device family [ARM7/ARM9/Cortex-M]: Cortex-M Specify target interface [JTAG/SWD]: SWD Specify target interface speed [kHz]: 1000 Connecting to target via SWD... Found SWD-DP with ID 0x2BA01477

若显示Found SWD-DP，说明物理层和基本协议握手成功。IDCODE0x2BA01477是ARM Cortex-M系列的标准值，若为0x00000000或0xFFFFFFFF，表明DP未响应。

步骤3：手动读取DP寄存器
继续输入：

J-Link> mem32 0x0 1 # 读DP_SELECT，应返回0x00000000 J-Link> mem32 0x4 1 # 读DP_CTRL_STAT，关注bit31（CSTICKYORUN）

若DP_CTRL_STAT返回0x00000000，说明无错误；若bit31为1，需先写mem32 0x4 0x80000000清零。

步骤4：访问AP并读取CPU ID

J-Link> mem32 0x0 1 # 确认DP_SELECT=0x00000000 J-Link> mem32 0x10 1 # 读AP_CSW，应为0x23000012（默认值） J-Link> mem32 0x14 1 # 读AP_TAR，应为0x00000000 J-Link> mem32 0xE000ED00 1 # 读SCB->CPUID，返回0x410FC241（Cortex-M4）

若mem32 0xE000ED00返回0xFAFAFAFA，说明AP访问失败，检查AP_CSW的PROT位是否为0b0010。

关键技巧：J-Link Commander的mem32命令本质是执行SWD事务，但隐藏了DP/AP细节。若需完全手动控制，可用loadbin加载自定义SWD脚本，或使用OpenOCD的swd newdap命令。

4.2 使用OpenOCD进行深度协议调试

OpenOCD是开源调试利器，其优势在于可完全暴露SWD协议细节，适合协议级研究。

配置文件（stm32f407.cfg）关键段：

# 定义SWD接口 transport select swd swd newdap stm32f407 cpu -enable target create stm32f407.cpu cortex_m -endian little -chain-position stm32f407.cpu # 初始化序列 $_TARGETNAME configure -event reset-init { # 强制DP复位 adapter srst delay 100 # 写DP_ABORT清异常 dap apsel 0 dap apcsw 0x23000012 dap apwrite 0x0 0x00000000 # 使能调试 mww 0xe000edfc 0x01000000 }

深度调试命令：

• dap info：显示当前DP/AP信息，包括IDCODE、AP数量。
• dap apsel 0：选择AP0。
• dap apcsw 0x23000012：设置AP_CSW为32位/特权/自增。
• dap apwrite 0x4 0xE000ED04：写AP_TAR为目标地址。
• dap apread 0xC：从AP_DRW读取数据。

实操案例：定位“复位后无法连接”问题
现象：MCU上电后可连接，但执行reset run后断连。
排查：

1. 在reset-init事件中添加日志：

   echo "Before reset: DP_CTRL_STAT = [dap dpread 0x4]"

2. 运行后发现，复位前DP_CTRL_STAT=0x00000000，复位后变为0x80000000（CSTICKYORUN=1）。
3. 进一步检查：mww 0xe000edfc 0x01000000（使能调试）后，DP_CTRL_STAT仍为0x80000000。
4. 根源：复位后，MCU的DBGMCU_CR寄存器（0xE0042004）的DBG_STANDBY位被清零，导致睡眠模式下调试被禁用。解决方案：在reset-init中添加mww 0xe0042004 0x00000007（使能所有调试位）。

4.3 基于逻辑分析仪的SWD协议解码

当示波器只能看波形，逻辑分析仪能直接告诉你“协议在说什么”。Saleae Logic 2是性价比之选。

设置步骤：

1. 将通道0接SWCLK，通道1接SWDIO。
2. 采样率设为100MS/s（10倍SWCLK频率）。
3. 添加SWD协议解码器，设置：
   • Clock channel: 0
   • Data channel: 1
   • Bit order: MSB first
   • Idle state: High

解码结果解读：

• Request帧：显示APnDP=1, RnW=0, ADDR=0x0→ 访问AP的CSW寄存器。
• ACK帧：显示ACK=OK→ 事务成功。
• Data帧：显示32位数据0x23000012→ AP_CSW值。

高级技巧：导出CSV文件，用Python脚本分析ACK失败率。例如：

import pandas as pd df = pd.read_csv("swd_log.csv") fault_count = len(df[df['ACK'] == 'FAULT']) print(f"FAULT rate: {fault_count/len(df)*100:.2f}%")

若FAULT率>5%，说明物理层不稳定，需检查上拉电阻或电源。

5. 常见问题与排查技巧实录

5.1 “SWD Connect Failed”问题速查表

5.2 那些年踩过的坑：独家避坑指南

坑1：SWDIO被复用为SWO输出，导致连接失败
现象：新固件烧录后，调试器无法连接，但旧固件正常。
原因：某些MCU（如STM32F7）的SWDIO引脚默认复用为SWO（Serial Wire Output）调试输出，若固件中开启了ITM（Instrumentation Trace Macrocell），SWDIO被占用。
解决方案：在调试器连接前，先执行reset halt，再mem32 0xE0042004 0x00000000（清零DBGMCU_CR），释放SWDIO。

坑2：低功耗模式下SWD失效
现象：MCU进入Stop模式后，调试器断连，唤醒后也无法恢复。
原因：Stop模式下，调试时钟（HCLK）被关闭，DP失去时钟源。
解决方案：在进入Stop前，执行mww 0xE000ED18 0x00000001（使能DBG_SLEEP），确保睡眠时调试时钟保持运行。

坑3：多AP系统中选错AP，读取到错误数据
现象：读取Flash寄存器返回0x00000000，但实际有数据。
原因：未正确设置DP_SELECT，误操作了CoreSight AP而非Flash AP。
解决方案：先mem32 0x0 1确认DP_SELECT值，再根据芯片手册找到Flash AP的索引（如STM32F4的Flash AP索引为1），执行mem32 0x0 0x00000001。

坑4：SWD线缆过长导致高频失败
现象：10cm线缆下24MHz正常，30cm线缆下必须降至4MHz。
原因：线缆电容增大，导致SWDIO上升沿变缓。
解决方案：改用屏蔽双绞线，或在线缆两端各加一个100Ω串联电阻（源端匹配）。

5.3 调试备忘录的终极用法：把它变成你的肌肉记忆

这份备忘录的价值，不在于收藏，而在于随时调用。我的工作台贴着一张A4纸，上面只印三行：

1. 物理层三查：上拉电阻？走线等长？电源稳定？