干了这么多年嵌入式，最闹心的事就是烧录。开发阶段自己板子烧不进去，还能耐着性子折腾；产线上一批板子烧录良率掉到百分之九十以下，那真是火烧眉毛。明明代码是好的，方案是验证过的，偏偏每隔几块就冒一个“No target connected”或者校验失败，拔下来重新夹一下又好了。这种问题最磨人，因为它不是稳定复现的崩溃，而是概率性的抽风。
这篇文章想聊的，就是把烧录这条链路从头到尾掰开看一遍。从电脑端软件、调试器/烧录器、连接线缆、目标板供电、芯片状态一直到产线夹具和操作时序，哪个环节掉链子都会变成“良率上不去”。我会按自己排查的习惯，从故障域划分讲起，再逐个环节拆解，最后聊聊批量产线上真正容易被忽略的隐形杀手。不管你用的是Keil、J-Flash、STM32CubeProgrammer、esptool还是OpenOCD，也不管目标芯片是STM32、ESP32、nRF51822还是海思、Jetson，排查思路都是相通的。
1. 先弄清楚烧录失败的“故障域”：板子、工具还是文件？
很多朋友一遇到烧录失败，第一反应就是换根线，或者把软件卸载重装。这种盲试运气成分太大，真正有效的做法是先做故障域划分。烧录这条链路上，能出问题的无非三块：目标板本身、烧录工具链（包括调试器、驱动、软件配置）、固件文件。三者独立又互相影响，把范围缩小了，后面就好办了。
1.1 烧录一条链上有哪些环节
一次完整的烧录，信号流大概是这样的：电脑上的烧录软件产生烧录指令，通过USB/以太网发给调试器或者编程器，编程器再通过SWD、JTAG、UART、SPI、I2C等接口跟目标芯片通信，芯片内部固化好的BootROM或者调试端口负责接收数据并写入Flash。同时目标板还得有稳定的供电、正确的启动模式、允许擦写的芯片状态。
每个环节都可能变成瓶颈。比如电脑USB口供电不足，导致调试器枚举不稳定；线缆过长导致SWD时钟信号变形；目标板复位电路搭得不好导致连接瞬间芯片跑飞；固件文件本身地址跟芯片Flash不匹配，烧进去能进但跑不起来；芯片开了读保护，调试器连不上。所以第一步不是猜，而是先做一套标准化的复现动作，把故障现象固定下来。
1.2 故障定位的快速二分法
我自己的习惯是：先试一块已知完好的板子。如果好板子能烧录，问题大概率出在目标板本身或者目标板相关的状态上；如果好板子也烧不进去，那问题大概率在工具链或者固件文件。这个二分法在产线上尤其好用，因为它能立刻把十几个工位的故障缩小到几个工位还是全厂故障。
第二步，用同一块故障板换一个烧录器再试。有时候J-Link连不上，但ST-Link能连上，这说明芯片没坏，而是某个调试器与芯片之间的时序或者电平协商出了问题。反过来也一样，换烧录器还是连不上，那基本可以认定是板子或者芯片状态异常。
第三步，看报错信息。这里的建议是，不要只看中文工具弹窗里的“烧录失败”四个字，要把详细日志打开。Keil的Build Output窗口、J-Flash的Log窗口、OpenOCD的terminal输出、esptool的串口打印，都藏着真正的失败原因。比如OpenOCD报的“Error: init sequence failed”，跟“Error: target not halted”完全是两码事，前者是复位/时钟初始化失败，后者是芯片已经跑起来没法进入调试模式。
1.3 良率的两个衡量维度：首烧成功率和重测通过率
产线上说的良率，其实要拆成两个数来看。第一个是首烧成功率，就是板子第一次放到夹具上，成功烧录的比例。第二个是重测通过率，指的是首烧失败后，重新调整或者恢复后能烧录成功的比例。这两个数能帮我们判断问题的性质。
如果首烧成功率低，但重测通过率很高，那大概率是接触问题、操作时序问题或者夹具问题。因为板子本身没坏，重新放一次就好了，只是每次都看运气。如果首烧失败后，重测也一直失败，那多半是芯片已经进入保护状态、硬件有坏道，或者固件本身有问题。如果是全工位首烧成功率突然集体下降，那大概率是烧录器固件被更新了、电脑系统更新了驱动、或者这一批芯片批次有差异。这些判断听起来简单，但很多工程师忙了一天，恰恰是在没有拆分指标的情况下，把两种完全不同的故障混在一起查，越查越乱。
2. 硬件连接与信号完整性：从夹具到芯片引脚的隐形杀手
排除完故障域，如果锁定在目标板或连接线路上，那就要把目光放到物理层。烧录失败里面，物理层问题占了相当大的比例，尤其是批量产线，信号完整性和接触可靠性往往决定了良率上限。我见过很多研发阶段用飞线杜邦线随便插都能烧录的板子，到了产线用夹具按压反而烧不进去，原因就是夹具的接触电阻、线缆长度、地线回流路径跟手工插线完全不一样。
2.1 供电是第一个要怀疑的对象
芯片要烧录，首先得保证它在正常的供电范围内。目标板的VDD不能只在启动瞬间拉到标称值，然后一路掉到欠压区间。调试接口、Flash写入电路对电压波动非常敏感，特别是有些芯片在2.7V以下还能跑，但是Flash擦写已经不可靠了。
排查时不要只看万用表测出的静态电压，要用示波器抓烧录瞬间的电源波形。很多板子在Flash擦写时会突然出现几百毫秒的电流尖峰，如果电源走线太细，或者去耦电容离芯片太远，这个尖峰就会把VDD拉低几百毫伏。芯片内部逻辑还在工作，但烧录状态机已经进入异常，表现出来就是校验失败或者“Program failed at address 0x0800xxxx”。
调试器供电也是个常见坑。很多便宜的ST-Link/J-Link clone会从USB取电，板子如果也由调试器供电，一个USB口带不动大电流负载就会掉电压。我的经验是：产线烧录工位必须用独立稳压电源给板子供电，调试器只负责信号，不要把调试器的3.3V当成主力供电。如果实在要用调试器供电，至少确认USB口是直连主板而不是前置面板，且线缆质量靠谱。
2.2 SWD/JTAG/串口接线：地线、复位、Boot引脚和线序
连接线上的问题，最常见的就是地线没接好。SWD虽然只有时钟和数据两根信号线，但地线是信号的参考平面。如果只接了SWDIO和SWCLK，靠的是板子与调试器之间的电源共地，一旦两者地电位有压差，通信就会随机失败。这个现象在产线上很典型：调试器插在工控机上，板子用另一路开关电源供电，两个地之间可能有几十毫伏甚至几伏的电位差，结果就是时好时坏。正确做法是，烧录排线里必须有一根可靠的地线，最好从夹具上直接连到调试器的地。
复位引脚也容易翻车。有些芯片在连接调试器时需要把复位脚拉低再释放，才能进入调试模式。尤其是芯片已经跑起来、看门狗在运行的情况下，如果调试器没有正确控制NRST，SWD握手就会超时。更隐蔽的是，很多板子的复位电路用了较长的RC延时或者加了复位芯片，导致复位释放时间跟调试器的预期不一致。遇到这种情况，可以在烧录软件里把连接模式改成“Connect under reset”或者“Hardware reset”，并把复位延时适当调大。STM32、nRF52、树莓派这些都适用。反过来说，如果复位引脚被硬件拉死在地，那JTAG/SWD是永远连不上的，按下复位键同时点连接也不行的。
串口烧录（ISP/UART Bootloader）对Boot引脚更讲究。比如STM32的BOOT0要拉高才能进入Bootloader，ESP32则需要确定IO0（或对应GPIO）在上电瞬间为低。很多工程师在开发板上用跳线帽能烧录，一到自制板就失败，十有八九是Boot引脚的电平没有在复位瞬间建立好。注意，这个电平必须在芯片复位释放之前稳定，不是等芯片跑起来了再去拉高。STC的片子更麻烦，它需要冷启动，也就是先点下载按钮再给芯片上电，很多刚开始用的人就是卡在这里。
2.3 接触不良与夹具老化：工业现场最容易被忽略的问题
产线烧录最常见的良率杀手，其实是机械接触。探针、压针、弹簧针、金手指，在长时间按压后会出现接触电阻变大、氧化、变形、移位。接触电阻一旦超过几十欧姆，SWCLK/SWDIO上的信号边沿就会严重退化，轻则偶尔失败，重则完全连不上。
判断接触不良有个很简单的办法：看失败率是否跟按压次数相关。如果一块板子第一次放上去失败，拿下来重新放一次就成功，那大概率是接触问题。另一个办法是用热像仪或者红外点温枪看夹具针脚温度，接触电阻大的针脚在连续烧录时会明显发热。不过更推荐的做法是建立周期性保养制度：每天下班前用无尘布蘸无水酒精擦拭针尖，每周检查针尖的弹力高度和磨损情况，每两到四周根据产量更换一批探针。别觉得这是小题大做，很多工厂的烧录良率从95%掉到88%，查了一圈最后就是换了一排探针解决的。
接触不良不只是夹具，还包括烧录插座。如果你用的是锁紧座或者弹簧座，芯片引脚氧化、引脚间距不对、插座弹片疲劳，都会造成同样的结果。研发阶段无所谓，产线就要用夹具厂家推荐的压力范围和针尖形状，不要自己乱改。
2.4 线缆长度、干扰与时钟速率
SWD/JTAG对线缆长度和时钟速率都很敏感。J-Link手册里一般建议SWD线缆不超过20cm，JTAG不超过10cm。产线实际用起来，很多工位为了布线方便会拉一根五六十公分的杜邦线过去，还绕了几个弯。结果就是SWCLK频率稍高一点就乱码。解决思路有三个：缩短线缆、降低接口速率、增加信号地隔离。
降低速率是最立竿见影的。J-Flash里可以把SWD速度从4MHz调到1MHz甚至100kHz，STM32CubeProgrammer里也可以设置连接频率。很多人不愿意降速，觉得生产节拍会拉低，但实际上一块小容量MCU烧录也就几十KB，就算用100kHz也比反复失败重试快得多。我见过一个项目，从失败重测率20%降到1%，仅仅是把SWD时钟从4MHz改成了1MHz。有时候稳定比快更重要。
如果降低速率还不行，就要怀疑是不是有电磁干扰。产线工位附近有伺服电机、变频器、大功率开关电源，都会在空间耦合噪声。这时候改用屏蔽线缆、把信号线双绞、在调试器端加磁环，都有帮助。最彻底的办法是把烧录夹具的线缆从平行走线改成树形短接，让每一路SWD分支离调试器尽量近。树莓派、Jetson这类高速平台的系统烧录，除了线缆，还要注意USB/网口转接芯片的信号质量，尽量不要用一分多的HUB跑烧录。
3. 烧录工具与上位机配置：芯片型号错了，什么都白搭
硬件没问题，调试器也连得上，可烧录就是报错，这时候十有八九是软件配置的问题。烧录工具的种类太多了：Keil MDK集成的是CMSIS-DAP/ST-Link/J-Link的驱动，J-Flash是SEGGER家的老牌烧录软件，STM32CubeProgrammer是ST官方工具，esptool是ESP32的Python烧录脚本，flash_download_tools是乐鑫家更傻瓜化的GUI，还有海思的HiBurn、Vivado的硬件管理器、树莓派的rpi-imager等等。每个工具都有自己的配置逻辑，但坑往往是相通的。
3.1 目标芯片型号与Flash容量匹配
最基础的坑，是芯片型号选错。你不是选了“STM32F103C8”，而是选了“STM32F103C8T6”，两者Flash大小一样，但未必能烧录成功。因为同系列不同型号的Flash扇区布局、选项字节地址、调试组件可能不同。J-Flash里如果选了带C的器件，去连不带C的芯片，虽然也能连上，但烧录时地址重叠可能会破坏保留区。
芯片容量也要严格匹配。同样封装可能是64KB和128KB两种Flash，如果编译器生成的文件大小大于实际Flash容量，烧录工具一般会报“file too large”或者直接超地址写入失败。这时候不要只怀疑软件，先用编程器读出芯片ID，确认真实的容量和修订版本。esptool的“esptool.py chip_id”或者“flash_id”命令可以拿到ESP系列芯片的Flash信息，STM32CubeProgrammer也能识别芯片型号和Flash大小。
3.2 固件文件格式与下载地址：hex、bin、s19的区别
很多烧录失败不是真失败，是烧进去了但起不来。这种最容易让人误判为硬件问题。其实问题很可能出在固件文件格式和下载地址上。HEX和S19都是文本格式的固件文件，内部自带地址信息，烧录软件一般会读取文件里的地址段，自动放到对应位置。BIN文件是纯二进制，没有地址信息，需要你手动指定起始烧录地址。如果你把ESP32的BIN文件直接烧到起始地址0x00000000，可能就覆盖了Bootloader，自然跑不起来。
Motorola S-Record（S19）在汽车电子里用得很多，它的每一行都带有地址和校验字节，烧录软件会逐行解析。如果烧录工具不支持S19格式，或者S19文件的地址偏移跟目标芯片的Flash基地址对不上，就会出现“Verification failed at address 0x00000000”这类报错。处理办法是用工具把S19转成HEX或BIN，转换时尤其注意地址偏移量。德州仪器、飞思卡尔（NXP）的MCU经常遇到这种问题。
另一个容易忽略的是烧录内容本身。有些芯片的Flash起始地址不是0x08000000，而是有Boot ROM前导区。比如很多STM32从0x08000000开始，但有些STM32H7系列有用户Boot Flash。ESP32的固件分区表（Partition Table）是烧录在固定扇区的，用esptool烧录时要把bootloader、partition-table、app三个文件分别烧到不同地址，乐鑫的flash_download_tools里已经预设好了，但用命令行esptool的时候得自己写对地址。Jetson、树莓派的系统烧录则是整个SD卡或eMMC的分区镜像，工具会自动处理，但若用dd命令手动烧录，写错块设备就是另一回事了。
3.3 J-Flash、Keil、STM32CubeProgrammer、esptool的典型配置坑
先说说J-Flash。它的界面看着简洁，但配置项不少。新建工程时不仅选芯片型号，还要选“Connections settings”里的接口类型（SWD还是JTAG）和速度。如果之前在JTAG模式跑习惯了，换到SWD板子忘记改接口，就会一直报“Cannot find ICE-Pick”。还有一个坑是“Production”模式下的“Programming options”：默认是烧录后校验，但如果勾选了“Erase sectors before programming”却不勾“Erase full chip”，芯片里残留的旧数据可能造成部分地址无法擦除。长期烧录同一型号芯片，我会直接把“Auto-erase”打开，省心。
Keil MDK里烧录失败的报错很多是“RDDI-DAP Error”或者“Error: Flash Download failed - Target DLL has been cancelled”。这种问题一半是驱动版本和MDK版本不匹配，一半是调试器clone的固件太老。解决办法是去Keil官网更新Pack里的Flash算法，或者换用新版本的DLL。StlinkV2在Keil里偶尔会报“Invalid ST-Link disk”，多数是驱动被系统更新顶掉了，重新装一遍ST-Link USB驱动就好。还有人在VS Code里用PlatformIO或者Eclipse插件编译成功，但烧录时一直连不上，这种情况往往是调试器被前一个进程占用，把VS Code终端里挂着的OpenOCD进程杀掉就好了。
STM32CubeProgrammer（简称Cube Prog）烧录时，要格外注意“Read Out Protection”（RDP）选项页。RDP Level 0是未保护，Level 1是只读限制，Level 2是永久锁定。如果前手把芯片设成了Level 1，Cube Prog连接时还能识别芯片，但擦除和编程都会报“Error: No STM32 target found”或者“Cannot access memory”。这时候要在选项字节页里先把RDP降到Level 0，注意降低RDP会做一次整片擦除。千万别手滑设到Level 2，那是不可逆的。
esptool烧录ESP32时的常见坑有两个。一个是UART下载模式没进对：芯片上电时IO0必须是低电平，同时EN引脚要先拉低再释放，这样才能进入Bootloader。如果串口回显出现“Waiting for download”反复出现但连接不上，大概率是IO0时序问题。另一个是用esptool自动检测波特率失败。ESP32系列有内置USB-Serial-JTAG的，和用外接UART桥是不同的接口，最新的ESP32-C3、S3、C6等板子要确认选对端口。烧录时如果遇到“A fatal error occurred: Timed out waiting for packet header”，可以先按住IO0和复位键，但时序还是不行就改用自动复位电路，很多DIY下载器没有把DTR/RTS引脚正确接入EN和IO0，造成一直进不了下载模式。
3.4 烧录速率和时钟选择：为了稳定而放弃速度
前面说过降低SWD频率能解决很多问题，其实“降速”不仅适用连接，也适用Flash写入过程。很多调试器默认使用的Flash算法在目标芯片主频过低时是跑不动的。比如STM32烧录时，内部Flash编程算法依赖系统时钟，如果外部晶振没起振，内部HSI也能工作，但频率只有8MHz。这时如果调试器选择太高写入频率，容易出现“Flash Timeout”.
解决办法是，在烧录软件的options里把“Verify”勾上，但把“Flash Download”里的“Erase Full Chip”改成“Erase Sectors”，减少擦除时间，从而降低总超时概率。同时可以把连接速度降到1000kHz甚至500kHz。生产节拍慢个一两秒，换来的是良率和少返工，这笔账很划算。批量烧录多片时，如果工具支持同时烧录多路，尽量选用同一供电基准，别让不同路的调试器各自带板子，这样不同板之间地电位不一致会互相干扰。
4. 芯片状态与安全位：读保护、写保护、熔丝位把芯片“锁”住时怎么办
很多烧录失败到最后都会演变成“救砖”现场。研发阶段最常见的是芯片读保护等级被误设，或者软件里不小心写错了Option Bytes，把调试端口给关了。生产阶段则可能是上一道工序的板子被设置了保护，结果流转到烧录工位后怎么也擦不掉。芯片一旦被锁，光靠换线换软件是没用的，必须按芯片的保护机制逐层解。
4.1 一言不合就锁死的Flash保护机制
不同芯片的“锁”五花八门。STM32用RDP（Read Out Protection）分Level 0/1/2；nRF51822这类Nordic芯片有UICR寄存器里的读保护配置，还有Approach保护的三个级别；NXP的Kinetis/LPC有Flash加密和Mass Erase引脚；ESP32有eFuse熔丝，烧了禁止加密、禁止下载甚至禁止读回；AVR有锁定位（Lock Bits），XTiny等还有NVM控制器权限；很多车规MCU还有HSM安全启动，外部调试端口默认关闭。
保护位的目的是防抄板、防固件泄露，但它误设后对产线是个噩梦。最常见的原因有三个：一是Bootloader代码里主动写了保护选项；二是烧录软件界面勾选了“Set protection”或“Secure flash”；三是芯片本身出厂时带默认保护，比如某些车规芯片默认Debug Port锁定，需要用制造商专门的命令解锁。遇到这种情况，不要急着推翻自己的硬件，先查一下芯片手册里“Debug Port”“Read Protection”“Security”这几章。
4.2 STM32读保护解除与“SWD脚配置错误”救砖
STM32的RDP Level 1解除很简单：用STM32CubeProgrammer选“Connect under reset”，然后在“Option Bytes”页把RDP从Level 1改成Level 0，点Apply。工具会提示执行一次Full Erase，整个过程几十秒。麻烦的是你的代码把PB3/PB4/PA15这几个SWD引脚重映射成了普通GPIO，同时把RDP也开了，导致外部调试器连不上，连接时直接报“No target connected”。解决办法就是进入Bootloader模式（BOOT0=1），用串口ISP协议连接，先把RDP降级。因为即使SWD引脚被占用，Bootloader里的系统存储区仍然开放ISP接口。同理，STM32F405的SW脚配置错误导致连不上，也可以通过BOOT0跳线的方式救回来，这是我反复验证过的流程。
更麻烦的是Level 2保护，一旦开启，芯片的调试端口彻底失效，连Bootloader ISP都会被禁止，几乎无法用软件手段恢复。所以任何跟STM32烧录相关的产线流程，我都建议在保护等级页面强制设置“Level 1”而不是“Level 2”作为上限，并且每一个烧录工位的软件模板里不要勾选任何“Disable debug port”选项。宁可烧录后让客户自己加保护，也不要产线层面误锁。
4.3 ESP32的eFuse与烧录模式进入失败
ESP32系列芯片里的eFuse是一次性熔丝，其中几个比特直接控制调试和下载权限。比如ESP32的“DIS_USB_JTAG”熔丝一旦烧写，USB-JTAG就永久禁用；ESP32-C3的“DIS_LEGACY_SPI_BOOT”会关掉一串下载方式；还有“SECURE_BOOT_EN”和“FLASH_CRYPT_CNT”组合起来会变成安全启动+加密Flash，外部工具无法直接读回明文固件。
如果产线上的ESP32烧录失败，先别怀疑硬件，用esptool读取eFuse状态。命令是esptool.py read_flash_status和esptool.py efuse_summary（新版叫esptool.py --chip esp32c3 efuse_summary）。如果发现下载相关熔丝已经烧写，这片芯片基本就废了，只能当半个“只读”芯片用。另外，ESP32的烧录失败还有个经典原因是SPI Flash配置不一致。芯片内部eFuse里存的Flash电压和频率如果跟外部Flash实际不符，会被识别成“invalid head of packet”或者进入无限重启。这类问题在ESP32-S3和ESP32-C3上尤其多，解决方案是更换匹配的Flash型号，或者通过esptool设置--flash_freq、--flash_mode保持一致。
4.4 专用工具对锁死芯片的恢复策略
除了常规烧录工具，针对被锁芯片还有一些专用恢复手段。ST-Link、J-Link都提供“unlock”或者“unsecure chip”命令。比如J-Link Commander里执行unlock Kinetis可以解除NXP Kinetis系列的整体保护；OpenOCD连接STM32被锁芯片时，可以在配置脚本里加上set CONNECT_UNDER_RESET 1，并在telnet模式下执行stm32f1x unlock 0来解锁。对于AVR，用高压编程器（HVPP/HVSP）可以把锁定位擦除，但需要额外的高压信号发生器。
产线遇到锁死芯片，我的建议是设立独立返修工位，专门用一套包含BOOT0跳线、高压编程器和专用的解锁脚本的夹具来处理。同时，把“被锁芯片”的统计数据单独记录——如果锁死率超过0.5%，就要回到烧录软件配置里查是不是不小心勾了什么保护选项，或者上一级Bootloader固件里的保护代码有bug。返修不可怕，可怕的是同样的锁死不定期出现却找不到共性。
5. 批量产线上的隐形杀手：夹具、时序、静电和记录
研发和单板调试遇到的问题，只要细心基本都能解决。产线批量烧录的难点在于，所有问题都会被放大，还会叠加一些研发阶段根本不会出现的新因素。即使你的单板烧录成功率是100%，跳线手工烧录随意插都行，到了自动化工位，良率可能只有80%。这节提到的内容，是我在产线跟线时踩过的坑攒下来的经验。
5.1 夹具接触电阻与压针寿命
前面提过接触问题，这里再展开讲讲。烧录夹具里的探针（Pogo Pin）不是永久的。国产优质探针的机械寿命标称通常在10万次到20万次，电气寿命在5万次左右。产线如果一天烧录2000片，一个月就是4万次，半年后探针的弹力和镀层基本就到寿命了。最重要的是探针表面的镀层，镀金探针因为氧化导致的接触电阻上升，很难用肉眼看出来。一个简单的判断方法：同一批板子用固定参数的烧录软件，如果指令间隔时间变长、偶尔出现“target connection lost”，就把探针拆下来用放大镜看针尖，如果针尖出现发黑、压痕过深或高度不一，直接更换。
还有一种隐蔽问题叫“压力不均”。多根探针排列时，如果板边翘曲、夹具定位柱磨损、气缸下压高度不准，会有一根针没有压到位。这根没压到的针正好是SWCLK的话，失败率就会变得很随机。很多工厂排查一整天，最后发现是夹具压板上的海绵垫厚度变了。所以夹具的定期点检不只是看探针，还要包括压板平面度、定位销位置、压合行程这些机械参数。
5.2 供电时序与复位时序：先上电还是先连调试器？
机器自动烧录时，时序控制搞反，会埋下很深的雷。有些调试器在USB枚举完成前就尝试拉高复位脚，而板子此时还没上电，芯片根本来不及响应；还有的夹具把电源和信号同时接通，上电瞬间的浪涌会通过SWD信号线灌到调试器端口，导致调试器锁死。经验法则是：先给目标板上电，等电源稳定50ms以上，再让调试器建立连接；烧录完成后再先断开调试器的连接，再断电。用PLC或者单片机控制继电器实现这个顺序最可靠。
STM32、ESP32这类芯片有上电启动时间要求，不同芯片从VDD上升到能响应调试器的时间从几毫秒到几十毫秒不等。如果夹具下压时同时完成供电和信号接触，芯片和调试器会处在“竞争”状态。解决方法是把烧录排线分成两组：先触发电源针，再延迟50~100ms触发信号针；或者把信号针的长度做得比电源针长（物理上先接触信号后接触电源），具体顺序需要按实际效果验证。批量烧录时，最好在治具软件里加入“上电等待时间”参数，真实测量芯片供电稳定后再开始握手。
5.3 ESD/EOS对烧录口的积累损伤
产线静电对烧录口的损伤，是很多人的盲区。板子从传送带、塑料托盘取出来时，人体和材料的摩擦很容易产生几千伏的静电。静电虽然未必当场打坏芯片，但会经SWD引脚、地线、电源引脚灌入芯片内部的IO保护二极管。一次两次可能没事，几十次后IO的漏电流就会增大，表现为烧录时信号边沿变差、偶尔握手失败。这种损伤用万用表很难测出来，只能用高倍显微镜看引脚旁边是否有微小的烧蚀点，或者直接用更换芯片对比验证。
对策很简单：产线工位铺防静电桌垫，夹具金属部分良好接地，操作员佩戴有线防静电手环，板子不要用塑料袋直接装，改用防静电周转箱。关键点是烧录器本身也要接地。很多USB调试器的金属外壳和USB屏蔽层是连通的，如果工控机外壳接地不良，反而会把工频干扰引到信号线上。我在产线见过最严重的一次，是几台工位良率集体下降，排查到后来发现是工控机电源的地线和夹具地线之间流过几十毫安的共模电流，在SWD线上产生了严重的电位漂移。把两个地彻底连成等电位就好了。
5.4 烧录次数与Flash寿命：每片芯片能擦写多少次
批量烧录还有一个隐形指标，就是Flash擦写寿命。MCU内部的Flash技术手册里一般标称10万次擦写（数据保持期限内），但注意这是擦写整个扇区的次数，不是单字节的次数。如果产线反复烧录测试、返修、重新烧录，一片芯片被擦写几百次都是可能的。Flash在临近寿命末期时，擦除时间会变长，极个别扇区可能出现写保护错误或者校验失败。
更常见的是PCB板上的Flash芯片（比如外挂SPI NOR Flash），它的寿命与解锁、擦除操作次数相关。ESP32模块、树莓派的SD卡其实也有写寿命问题。如果良率报表里集中在某一个固定位号的板子反复烧录失败，且报错都是擦除/校验错误，那可能就是这片Flash已经被折磨得不行了。产线流程里最好增加“烧录次数计数”功能：每次烧录成功给板子写入一个出厂标记，如果同一块板子重烧超过三次，就转到人工判定，而不是一直硬烧。这样既保护芯片寿命，也让返修数据更干净。
5.5 烧录记录与不良追溯：用数据找规律
聊了一堆技术细节，最后想强调数据。烧录良率上不去的时候，不要只盯着修板子，要把每一次失败记录下来。记录项至少包括：设备编号、烧录软件版本、调试器固件版本、板卡批次、芯片批次、夹具编号、操作班次、失败错误码、重试次数、重测是否成功。然后每天按这些维度做统计。
我见过一个案例，某工位白班良率100%，夜班良率下降到90%。排查来排查去，最后发现是夜班工位附近多了一台大功率UPS，启动瞬间的电磁干扰影响了SWD线。没有记录的话，这种跟设备编号强相关的规律很难发现。另一个案例是，某批次PCB的板边没处理好，沉金面有轻微毛刺，导致夹具上的地针接触电阻忽高忽低。通过记录比对，发现所有失败板都集中在这一批次，问题就锁定了。数据不一定能直接解决问题，但一定能缩小范围。
产线烧录这件事，说到底就是把“能烧录”变成“稳定烧录”。单板能烧通，只是第一步；把烧录当做一个系统工程去对待，从硬件、软件、芯片、夹具、流程、数据六个方向持续打磨，良率才真正可控。每次遇到烧录失败，先别急着怪芯片或工具，按这几个环节从头理一遍，大多数坑都在里面。
