JTAG与SWD调试接口全解析：协议差异、选型与排障

板子焊回来，第一件事是插上调试器看看能不能连上。我见过太多项目，硬件一次点亮，软件却卡在“目标未找到”上耗掉两三天，最后发现是调试口少焊了一个上拉、走线绕到了电源底下、或者固件里把调试引脚复用成了普通 IO。JTAG和SWD这两个词，几乎每个做嵌入式的人都绕不开，但真正把两者的协议差异、引脚复用关系、拓扑限制、以及“什么时候该用哪个”说清楚的材料并不算多。这篇就按我自己的实际经验来铺：先把两种接口在电气和协议层面拆开讲透，再落到硬件布线与调试器配置的具体操作，最后把我踩过的坑整理成能直接查的表。适合刚接触单片机的朋友建立整体认知，也适合已经能连上但总在量产、低功耗、多板卡场景里翻车的老手对照排查。

1. 先把这两种接口的本质讲明白

1.1 调试口的本质：给芯片内部开一扇观察窗

很多人把调试口当成“下载口”，这是最常见的认知偏差。烧录固件只是它最基础的功能之一，真正值钱的是运行时的可观测性与可控性：能不能在读一个变量的时候不打断 CPU，能不能在某一行业指令执行完的瞬间冻结内核，能不能在 CPU 全速跑的时候把日志从芯片里吐出来。这些能力全都建立在调试接口之上，而不仅仅是那几根数据线。理解了这一点，后面的选型判断就顺了——你选的不只是一个烧写通道，而是一整套调试能力的天花板。

从结构上看，调试系统通常分三层：最上面是你在电脑上操作的 IDE 或命令行工具，中间是调试探头（那个插 USB 的小盒子），最底下才是芯片内部嵌入的调试模块。探头和芯片之间跑的就是 JTAG 或 SWD 协议，探头和电脑之间一般是 USB。这三层里任何一层出问题，表现都是同一句话：“连不上”。所以排查的时候千万别一上来就怀疑协议，先把供电、地、复位、时钟这几件事确认掉，八成问题出在这里。

还有一个容易被忽略的点：调试模块在芯片内部是独立于 CPU 内核的一小块逻辑，它有自己的时钟域和复位域。这就解释了为什么会出现“CPU 跑飞了但调试器还能连上”——因为调试逻辑没死。反过来，如果芯片进了深度低功耗模式，把调试模块的时钟关掉了，那探头就真的看不见它了。这个特性在设计低功耗产品时是必须提前想清楚的，不然你会经历“上电正常、一进睡眠就失联”的经典场面。

1.2 JTAG 的本来面目：它压根不是为调试发明的

搞清楚 JTAG 的历史很重要，因为它解释了这个接口为什么长成现在这副样子。它最初是为边界扫描测试设计的，目的很单纯：板子贴片完成后，焊点有没有虚焊、芯片引脚有没有短路断路，用几根线就能测出来，不用拿探针一根根戳。做法是在每个 IO 引脚旁边串一个移位寄存器单元，这些单元首尾相连形成一条扫描链，从 TDI 进、TDO 出，TCK 推、TMS 控制状态，就能把整块板子上所有引脚的当前电平"读"出来，也能强制"写"进去。

正因为出身是测试，JTAG 的协议结构天生带着通用性和冗余度。它有一台 16 个状态的 TAP 状态机，靠 TMS 在每个 TCK 上升沿的取值来决定往哪走。所有操作都是围绕两条寄存器链展开的：指令寄存器 IR和数据寄存器 DR。你想读芯片 ID，就往 IR 里塞 IDCODE 指令，然后从 DR 里移出 32 位内容；你想访问内部的调试模块，就把 IR 切到对应的调试指令上，之后的 DR 访问就变成了对调试寄存器的读写。这套机制非常灵活，同一套物理接口能挂测试、能挂调试、能挂编程，甚至能给 FPGA 加载配置。

灵活是要付出代价的。多器件连接时，JTAG 采用菊花链拓扑：所有芯片的 TCK 和 TMS 并联，TDI 串到第一颗，第一颗的 TDO 接第二颗的 TDI，一直串下去。这意味着你要访问链上的第 N 颗芯片，前面所有芯片的 IR 长度都必须精确知道并绕过，旁路（BYPASS）指令就是把某颗芯片的 DR 缩成 1 位。链上多一颗芯片、少一颗芯片、或者某颗芯片的上电时序不同，整条链的行为就变了。我在实际项目里遇到过一块板子上挂了四颗器件，标称总 IR 长度是 24 位，实际扫出来对不上，最后发现其中一颗的复位引脚悬空导致状态机没归位，这种问题查起来相当磨人。

1.3 SWD 的出现：把五根线压到两根

SWD 的设计动机非常直接——省引脚。在引脚资源紧张的封装上，为了调试单独占用四到五根线是很奢侈的事，尤其是那些二三十个引脚的小封装，用户可能把剩余 IO 全用满了。于是就有了这套两线方案，只用一根时钟加一根双向数据，就能完成几乎全部调试功能。

关键在于，SWD 并不是凭空造的新物理层，它在引脚上和 JTAG 是复用的：SWDIO 复用 TMS，SWCLK 复用 TCK。这个设计极其聪明，意味着你在画板子的时候不用二选一，把 TMS 和 TCK 引出来，硬件上同时兼容两种模式，用软件去切换就行。切换的机制也很朴素：芯片上电默认停在 JTAG 状态，调试器先发一串特定的线序列（业内通常叫 JTAG-to-SWD 切换序列，常见值是 0xE79E），芯片检测到这个模式后就把 TAP 状态机切到 SWD 模式；反过来要切回 JTAG 也有对应的序列。

协议层的差别就更大了。JTAG 是围绕状态机和移位链组织的一大套通用机制，SWD 则是为调试量身定做的包式协议：每个事务由主机发出 8 位请求（含 APnDP、RnW、地址、校验位），目标回 3 位应答（OK、WAIT、FAULT），然后跟上 33 位数据（读操作还带奇偶校验）。整个过程没有那台 16 状态的 TAP 状态机，只有明确的事务握手。带来的直接好处是效率：SWD 在传输同样数据量时，时钟周期开销明显小于 JTAG 走完整链路的开销，尤其是在只访问单个目标的时候。

这张表不是让你背的，是让你在方案评审时能快速定位问题。比如有人问“为什么这块板子只能连一颗芯片”，答案往往就是拓扑那一行——SWD 是点对点的，四颗芯片挂在同一组线上，地址冲突，谁也连不上。

2. 电气与时序层面的关键差异

2.1 信号方向与电平匹配，别在小地方翻船

JTAG 的信号方向是固定的：TCK 和 TMS 由探头驱动，TDI 探头驱动，TDO 由目标驱动。这种固定的单向性让电路设计相对好推理，你只要保证每条线的驱动方向不错就行。SWD 就不一样了，SWDIO 是双向半双工的，同一个引脚一会儿当输入一会儿当输出，方向切换由协议中的周转周期（turnaround）来控制。

这个双向特性带来一个很实际的坑：如果你的板子上在 SWDIO 上串了一个电阻，或者在探头和目标之间加了电平转换、隔离器件，方向切换的那一刻可能出现信号争用或者边沿畸变，表现就是“能识别到芯片但读寄存器随机出错”。我一般在 SWDIO 上只串一个几十欧的电阻做限流保护，绝不放缓冲器，除非万不得已。真要做隔离，得选支持双向、切换延时不大的方案，并且把速率降下来验证稳定性。

电平匹配是另一个高频问题。调试器的 IO 电压通常靠目标板上的 VTREF 引脚来感知，探头采样这个电压后调整自己的输出电平。所以VTREF 必须接，而且必须接在目标板的 IO 电源上，不是接主电源。我见过有人把 VTREF 接到 5V 输入上，而芯片 IO 是 3.3V，结果探头按 5V 电平输出，SWDIO 长期超压，芯片没当场坏，但调试时好时坏，非常难查。

注意：VTREF 接错电压域是隐性问题，短期不炸、长期不稳，比直接烧芯片更难排查。画原理图时把这条线单独标出来，评审时专门确认一次。

2.2 速率不是越高越好，算一下就明白瓶颈在哪

调试时钟的速率，取决于三件事：探头支持的上限、目标芯片调试模块能接受的上限、以及你板子上的信号完整性。前两个是手册里写的，第三个只能靠实测。很多新手上来就把速率拉到最高，连不上就开始怀疑人生，其实降到 1 MHz 立刻就通了。

这里有个粗略的带宽估算，帮你判断“够不够用”。以 SWD 为例，读一次 32 位数据大约需要 8 位请求加 3 位应答加 33 位数据，再加方向切换开销，一个事务在 46 个时钟周期上下。如果时钟跑 10 MHz，理论上每秒能做二十多万次事务，折算成下载速率大概在几百 KB/s 量级。实际受限于探头固件、USB 传输、协议握手延迟，往往打对折甚至更多。JTAG 走完整链路时如果有多个器件在链上，每次访问还要把数据穿过前面的旁路单元，开销会明显变大。

真正影响体验的不是峰值速率，而是单步调试时的响应延迟。你按一下 F10，等半秒钟才返回，一上午下来效率极低。这个延迟主要来自探头固件和 USB 通信，跟协议关系不大。我在选探头时的经验是：看它的批量读写吞吐，更要看小事务延迟，后者直接决定你调试时的手感。

2.3 拓扑结构决定了你板子能挂几颗芯片

JTAG 的菊花链在多器件场景下是无解的优势。一块板子上有主控、有一颗协处理器、还有一片可编程逻辑器件，用一条 JTAG 链串起来，一个探头全搞定，工具里按链序访问就行。麻烦在于链路长度必须精确配置，任何一环对不上，整条链都访问不了。链上器件的 IR 长度是累加的，你要访问最后一颗，就得先给前面所有器件打 BYPASS 指令，让它们的 DR 缩为 1 位。

SWD 则是点对点，一组 SWCLK/SWDIO 只能对应一个调试目标（多 drop 的 SWD 在标准里存在，但实际产品里支持得很少，别指望）。板子上有多颗需要调试的芯片，常见做法有两种：一种是给每颗芯片留一组独立的调试焊盘，用哪个接哪个，成本最低但调试时要插拔；另一种是加一颗多路模拟开关做切换，用 GPIO 控制通路选择，量产测试台上很常见。后者的代价是开关的导通电阻和寄生电容会劣化信号，速率得往下压。

提示：多芯片板子在设计阶段就要决定“哪几颗需要独立调试口”。全留会浪费面积，全共用会连调试都调不了，这个决定最好在原理图评审时定下来，别等到打样后才发现。

3. 选型逻辑：什么情况下选哪个

3.1 引脚紧张的小封装，SWD 基本是唯一解

二十几个引脚的单片机，IO 本来就捉襟见肘。这时候留四根给 JTAG，等于把可用的外设接口砍掉一大块。SWD 只占两根（加上复位和地在排针上通常是四到五针的接口），剩下的引脚全给应用逻辑，这个账很好算。

但省引脚是有前提的：你得确认这颗芯片确实支持 SWD，而且调试模块没有被厂商裁剪掉。有些低成本型号只保留了最基础的烧写能力，跟踪输出、硬件断点数量都被砍到很可怜的水平。选型时看手册里“调试”那一章的表格，重点确认三件事：断点数量、观察点数量、是否支持跟踪输出。断点只有两个的芯片，调试复杂状态机时会非常难受，你不得不反复在代码里插打印语句来替代断点。

还有一个现实考量：小封装芯片的调试口往往和启动模式引脚复用。上电瞬间那几个引脚的电平决定了芯片从哪启动，如果外部电路上有强上拉或强下拉，可能干扰启动模式判断。这时候要么在调试接口上加隔离，要么在电路上做跳线选择。我见过一块板子因为调试排针上接了 LED 指示灯，导致每次上电都进不了正常启动模式，查了很久才发现是 LED 的限流电阻把引脚拉到了错误电平。

3.2 需要边界扫描和多器件串联时，JTAG 无可替代

什么场景必须上 JTAG？我总结了三类。第一类是硬件调试阶段需要做互连测试，尤其是 BGA 封装、焊点肉眼看不见的板子，边界扫描能在不上电的情况下验证引脚连接，这个能力 SWD 完全没有。第二类是板上有可编程逻辑器件需要配置，这类器件的配置流程本身就是走 JTAG 的。第三类是多器件串联，尤其是需要在一个调试会话里同时观察主控和协处理器的状态。

还有一类容易忽略的：某些芯片的 SWD 实现有 bug，或者某些老型号压根不支持 SWD。我在做旧平台维护时遇到过只能走 JTAG 的芯片，调试器换了三个才发现是接口不支持。所以拿到一颗不熟悉的芯片，第一件事是翻手册确认它到底支持哪些调试接口，别想当然。

实际工作中更常见的做法是两者兼容：硬件上把 TMS、TCK 引出来，同时按 SWD 的四针或五针接口布局，软件里靠切换序列选择模式。这样一块板子既能用便宜的 SWD 探头，也能用功能更全的 JTAG 探头，还能在 SWD 出问题时切到 JTAG 交叉验证——这个交叉验证的价值极高，能快速区分“是芯片问题”还是“是探头或接线问题”。

3.3 混合布局的实操约束

想同时兼容两种接口，原理图上不难，难在布局。共用 TMS 和 TCK 意味着这两根线要同时满足两种协议的信号质量要求，而 JTAG 的 TCK 在高速下对走线匹配更敏感。我的做法是把调试接口放在板边，走线尽量短、尽量直，不跨越电源平面分割，不在下面走开关电源的环路。串联电阻靠近探头一侧放，别靠近芯片侧，这样对芯片引脚的寄生影响小。

复位信号要不要接，是个经常被争论的问题。我的结论是：接，而且要用可断开的方式接。调试器需要能拉低复位让芯片停下来再连（常说的“复位下连接”），尤其是在固件一上电就跑飞或者立刻进低功耗的场景里，不复位根本连不上。但复位线上如果并了大电容，探头拉低的速度跟不上，也会失败。所以复位线串一个小电阻、电容控制在几百皮法以内，是比较稳妥的折中。

注意：调试接口附近不要放大功率开关电源的 inductor，也不要让调试走线平行于高频时钟线过长距离。这两条是“时好时坏”类故障的头号来源。

4. 从接线到连上：完整实操流程

4.1 硬件侧的六个检查点

动手之前先做个清单式确认，按顺序过一遍，能省掉大量来回。第一，目标板供电是否正常，IO 电压是不是探头预期的值。第二，地线是否可靠共地，尤其是用 USB 供电的板子接外部电源时，共地不良会导致通信乱码。第三，VTREF 是否接到正确的电压域。第四，复位引脚是否被外部电路持续拉低。第五，调试引脚是否在固件里被复用成了普通功能。第六，探头和目标之间的线是否过长、是否有断线。

这六条里第五条最阴险。很多芯片在启动后会根据配置把调试引脚切换成 GPIO，一旦切了，调试器就再也连不上，除非用“复位下连接”在固件运行前抢进去。这种情况在低功耗产品上尤其常见，因为省电策略会把不用的外设全部关掉，包括调试模块。

我的习惯是：第一次点亮新板子时，固件里先不加任何引脚复用代码，确保调试口能被识别；等基本功能验证完，再逐步加入复用逻辑，每加一步都确认还能连上。这样出问题时能立刻定位是哪一步引入的。

4.2 探头连接与目标识别

接线顺序建议先接地，再接 VTREF，最后接信号线，拆的时候反过来。这不是仪式感，是为了避免带电插拔时信号线先接触导致电平异常。SWD 的接线是 SWCLK、SWDIO、GND、VTREF，如果要跟踪输出再加一根 SWO，要复位控制再加一根 RESET。JTAG 则是 TCK、TMS、TDI、TDO，加 GND、VTREF，可选 TRST 和 RESET。

连上之后先用最低速率尝试识别。识别成功的标志是能读到目标的 ID 码。JTAG 通过 IDCODE 指令读 32 位标识，最低位固定为 1；SWD 通过读调试端口的标识寄存器获取。读不到 ID 说明物理层或协议层有问题，这时候别急着调固件，先解决连接。

用开源调试服务器做识别，一条命令就能看出结果：

# 以 CMSIS-DAP 类探头为例，先扫描链路 openocd -f interface/cmsis-dap.cfg -c "transport select swd; adapter speed 100; init; scan_chain; shutdown"

正常输出里会打出一行带 ID 码的信息。如果打出来的是全 0 或者全 1，基本可以确定是接线问题或者芯片没上电；如果报的是超时，可能是复位或者时钟问题。JTAG 模式下还有一条scan_chain会列出链上每一颗器件的 IR 长度和 ID，这个信息对多器件板子特别有用，能直接验证你原理图上的链序对不对。

4.3 配置文件怎么写才不出错

调试服务器的配置文件分两层：接口配置和目标配置。接口层描述探头类型和传输方式，目标层描述芯片的调试模块结构。目标层最容易写错的是 IR 长度和 ID 码，这两个值必须和手册完全一致。

# 接口层：选择探头与传输方式 adapter driver cmsis-dap transport select swd adapter speed 1000 # 目标层：声明 TAP 与调试端口 set _CHIPNAME demo jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id 0x0BB11477 dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu # 复位策略：让探头在连接时主动拉低复位 reset_config srst_only srst_nogate connect_assert_srst

上面这段里，-irlen 4表示指令寄存器 4 位，这个是多数 32 位内核的常见值，具体以手册为准；-expected-id是期望读到的 ID 码，写对了能在连接阶段就挡住接错板子的情况，写错了则会一直报“expected id 不匹配”，反而误导排查。我的习惯是第一次先不写-expected-id，让它自动读出来，确认无误后再回填，这样避免因为记错 ID 而白白折腾。

复位策略那一行值得单独说。connect_assert_srst的含义是“连接时先把复位拉住再连”，专治那种固件一上电就进低功耗或者跑飞的情况。副作用是如果你的复位线没接或者被外部强上拉，这个策略就不生效，得改成软件复位或者干脆不接复位靠“ halt 抢占”。

烧录和运行的命令组合也很常用：

# 一条命令完成连接、暂停、烧写、复位运行 openocd -f board/demo.cfg \ -c "init; halt; program firmware.elf verify reset; shutdown"

verify这一步别省，它会把写进去的内容读回来比对。曾经有一次批量烧录几十块板子，其中两块因为供电不稳写坏了，就是因为当时图快没加校验，最后靠现场返修才发现。

4.4 跟踪输出：SWD 的隐藏加分项

SWD 相比 JTAG 有一个常被低估的优势：单线跟踪输出。一根 SWO 引脚就能把芯片内部的打印信息以硬件方式吐出来，不占用任何串口外设，也不影响 CPU 执行时序。做实时性要求高的项目时，这个能力比打断点有价值得多——你可以让程序全速跑，同时观察变量的变化曲线。

配置上要注意两点。一是时钟，跟踪输出的波特率是从调试时钟分频出来的，调试时钟变了波特率也跟着变，所以改速率后要重新算分频系数。二是引脚，SWO 复用 TDO，也就是说你在 JTAG 模式下它是 TDO，在 SWD 模式下才是 SWO，硬件上引出一根线就能兼顾。

如果芯片不支持 SWO，还有个替代方案：在内存里开一块环形缓冲区，把日志写进去，调试器通过 SWD 定期把这块内存读出来。这种方式对 CPU 的干扰更小，缺点是读取有延迟，不适合看瞬时事件。

5. 常见故障的排查思路与实录

5.1 连不上、连一次就断的典型成因

“连不上”这三个字背后至少有十几种原因，我按出现频率排个序。最高频的是供电与共地问题，尤其当目标板由独立电源供电、探头由 USB 供电时，两者地电位不一致会导致信号判读错误。解决办法很简单，把两边的地可靠连起来再试。

第二高频的是调试引脚被固件复用。表现是第一次能连上，烧完固件后就再也连不上。这时候用“复位下连接”抢在固件运行前暂停内核，或者用启动模式引脚让芯片停在引导程序里，就能恢复。

第三是复位电路设计不当。复位引脚上并了大电容，或者有强上拉，探头拉不动，连接阶段的握手就失败。示波器量一下复位引脚的边沿，如果下降沿很缓，就该调整电容值或者改成开漏驱动。

第四是速率过高。尤其是用杜邦线飞线调试的时候，10 MHz 基本没戏，降到 500 kHz 立刻就通。这不是探头不行，是线不行。

第五是芯片进了保护状态。有些芯片在检测到异常后会锁住调试口，需要按厂商公开的恢复流程处理。这里要强调一句：恢复流程必须基于芯片手册的公开说明，目的是修复自己手里的板子，任何超出这个范围的操作都不该做。

5.2 低功耗场景下的连接保持

做电池供电产品，一定会在某个阶段遇到“一进睡眠就失联”。原因前面提过：进低功耗时芯片可能关掉调试模块的时钟，或者把调试引脚切换成高阻。解决思路有三条，按推荐度排。第一条是在调试阶段临时关闭低功耗模式，用编译开关控制，量产固件再打开。第二条是配置调试模块在低功耗下保持供电，很多芯片提供了这个选项，代价是待机电流略增。第三条是用复位下连接，每次调试都从头开始，牺牲一点便利性。

我要提醒的是，这三条都不能替代验证。你在调试阶段关掉了低功耗，等于没测过真实的睡眠行为，量产前必须有一段纯量产的固件跑完整流程，确认唤醒、通信、调试口恢复都正常。我见过项目在调试阶段一切正常，量产固件一上电就再也连不上，只能整批返工，就是因为跳过了这一步。

5.3 问题速查表

提示：排查顺序永远是“电源 → 地 → 复位 → 时钟 → 接线 → 配置 → 固件”。从上往下走，别跳步。跳过前面的直接怀疑协议，十次有九次是白费时间。

5.4 几条踩出来的经验

第一条，永远在板子上留测试点。调试口旁边留几个裸露的焊盘，飞线的时候不用去戳排针。这个成本几乎为零，救急的时候价值极高。

第二条，准备一个已知能用的最小系统。当你怀疑是板子的问题时，拿一颗同型号芯片焊在最小系统板上，用同样的探头和线连一次。如果最小系统能连、你的板子不能，问题一定在板子上，别再去折腾探头了。这个对照实验能省掉大量无谓的怀疑。

第三条，别在调试口上省钱。ESD 保护器件、限流电阻、足够的排针数量，这些加起来成本不到一块钱，但省掉它们导致的返修成本是这个数字的几十倍。我现在的习惯是调试接口一定做成标准排针间距，并且标上引脚丝印，避免插反。

第四条，把调试配置纳入版本管理。配置文件、接线说明、已知的坑，全部写进项目文档。换人接手的时候，这些信息比代码注释还重要。我接手过一个项目，前一位同事离职后没人知道那颗芯片要用特定的切换序列才能进调试模式，硬生生耽误了一周。

6. 量产阶段与调试口的相处方式

6.1 什么时候该关掉调试口

研发阶段调试口是命根子，量产阶段它就是风险点。原因有两个：一是它提供了对内部存储和运行状态的完全访问能力，产品到了终端用户手里，这个通道不该留着；二是调试口在待机时会带来额外的漏电流，对低功耗产品是实打实的损耗。所以量产固件里把它关掉，是标准做法。

关闭的时机很关键。我的建议是放在产线测试流程的最后一步，前面所有功能测试、校准、写序列号都做完之后再关。关早了，测试不通过时没法返修；关晚了，漏出去的产品就带着开口。实现上通常是在固件里加一个条件分支，用一个标志位或者特定序列触发，具体寄存器操作以芯片手册为准，流程大致是这样：

/* 示意流程：产测流程末尾锁定调试口 * 具体寄存器名称与操作序列必须以芯片手册为准 * 此处仅表达“先确认、再锁定、锁定后不可逆”的逻辑 */ if (production_test_passed && serial_number_written) { /* 1. 擦除调试口相关的配置区（如存在） */ /* 2. 写入锁定标志 */ /* 3. 触发系统复位使配置生效 */ /* 4. 复位后自检：确认调试口已不可访问 */ }

注意最后的自检步骤，一定要在锁定后重新上电确认一次，别写完标志就当成功了。有些芯片的锁定是延迟生效的，要等下次复位才起作用，如果中间掉电，可能处于半锁定状态，行为不可预测。

注意：锁定操作通常不可逆，或者只能通过全片擦除恢复。产测流程里务必加二次确认，别让一个误触发的分支把整批板子锁死。

6.2 锁定后的恢复与产线留口

锁定不一定等于报废。多数芯片提供了公开的恢复路径，最常见的是通过调试口的特定时序触发全片擦除，擦完之后芯片回到出厂状态，调试口重新可用。代价是里面的固件和标定数据全没了，所以要重新烧录和校准。

正因为如此，产线设计时我会建议留两条路：一条是正常流程下不锁定，只在确认产品要出库时才执行；另一条是保留一个物理上的恢复入口，比如板子内部的一个焊盘或者隐藏按键，售后返修时能触发擦除重烧。这个入口不能让终端用户轻易够到，但维修人员要能够到。

还有一类场景值得单独提：代工生产时的调试口管理。外发的板子如果调试口是开的，等于把固件的读取权限交给了对方。这时候要么在发出前就锁定，要么用一次性烧录的方式，把固件和锁定动作在同一次连接里完成。具体怎么做取决于你的产测流程设计，但核心原则是：调试口的开放窗口越短越好。

回过头看，JTAG 和 SWD 的选择从来不是纯粹的技术问题，它牵扯到封装选型、板级布局、产线流程、甚至产品的安全边界。我自己的习惯是：新项目一律按 SWD 布局，把 TMS 和 TCK 都引出来做兼容，调试阶段用 SWD 求快，遇到疑难问题切 JTAG 做交叉验证，量产前按流程锁定。这套组合用下来很少翻车。真要给一句建议的话——别等到连不上的那天才去翻手册研究调试接口，把它当成和电源、时钟同等重要的一环，在原理图评审的时候就把这几根线讲清楚，后面能省下的时间远超你的想象。