搞硬件、搞嵌入式的朋友，应该都经历过这种时刻：量产测试线上 20 台设备里有一两台怎么都连不上串口，换个 USB 口又好了；客户反馈蓝牙耳机偶尔断连，但拿到实验室里怎么连都正常；固件昨天烧录得好好的，今天换了新批次的芯片，Keil 直接报 cannot connect。这些问题有一个共同的名字——偶发 Bug。它不给你稳定的现场，也不给你复现路径，留下的只有一句“偶尔出现，多试几次又好了”。
这篇文章不讲抽象理论，只复盘我在串口、蓝牙、烧录三个方向上的真实排错过程：串口假故障的换机排除，蓝牙断开怎么用录屏取证，烧录失败怎么做新旧批次对照。每个案例都会把排查链路完整展开，包括我当时为什么这样做、中间踩了哪些坑、最终怎么定位。适合刚入行的嵌入式开发、硬件测试工程师，以及所有被“偶发”两个字折磨过的同学。
1. 偶发Bug的排查框架：先锁现场，再谈定位
偶发 Bug 之所以难，核心是信息不对称。它不像必现 Bug，给你一个操作步骤就能稳定复现，然后打断点、看变量、加日志，一步步逼近真因。偶发 Bug 的典型特征是：现场无法重现、证据无法回溯、修复无法验证。这三个“无法”凑到一起，很容易让人陷入玄学式的瞎试——换芯片、换板子、换电脑，最后换到怀疑人生。
1.1 为什么偶发 Bug 会让人崩溃
先说最扎心的一点：人类是不可靠的故障记录仪。客户说“蓝牙断了五次”，实际可能是断了五十次然后自动重连了；测试员说“串口偶尔没输出”，实际原因可能是他同时开着两个串口助手，其中一个抢占了端口。这不是客户或同事故意说谎，而是人在描述偶发现象时，会下意识地把细节修剪成自己理解的样子。
举一个我自己的例子。早年做一款带蓝牙功能的桌面设备，客户反馈“设备用十分钟就掉线，掉线后过几十秒自己回来”。我们怀疑是蓝牙模块有问题，换了三个不同厂家的模块，问题依旧。后来我直接跑去客户现场调了一天，才发现他的工位旁边有一台老式微波炉，每次加热时设备必断。这个干扰因素别说客户不会主动描述，连我们自己排查时都未必第一时间想到。
所以要处理偶发 Bug，第一步不是动手修，而是动手记录。这也是我把三个案例放在一起讲的原因——它们都有一个共同的前提：先拿到可靠证据，再谈定位和修复。
1.2 我的排查框架：锁现场、控变量、留证据
这几年的经验我总结成九个字：锁现场、控变量、留证据。
锁现场指的是在故障发生后，第一时间冻结一切环境条件，不要急着重启、换线、动配置。很多时候工程师到了现场，看到设备没反应，条件反射就去断电重启，结果故障消失了，证据也消失了。正确的做法是先把界面、指示灯、日志、外设连接状态全部拍照或录屏，能抓多少抓多少。
控变量指的是每次只改一个条件。换线了就不要再同时换电脑，换了电脑就不要同时换转接板。很多人的排查之所以失败，是因为一次动了三四个变量，最后定位到的是“某个组合”的问题，而不是“某一个”的问题。
留证据则是要把整个排查过程做成可追溯的记录。我习惯用表格记录每个实验的日期、工程版本、硬件批次、供电方式、线缆编号、烧录器序列号。这个习惯在烧录章节会发挥很大作用，因为“新旧批次对照”本质上就是依赖一份可靠的批次溯源记录。
有了这个框架，后三个案例就有了共同的底色：串口假故障用的是换机排除，本质是逐级控制变量；蓝牙断开的录屏取证，本质是先把不可靠的口头描述替换成可回溯的影像证据；新旧批次对照的烧录排查，本质是用硬件批次溯源配合变量拆解，锁定隐性差异。
2. 串口假故障：换机排除的完整链路
串口这玩意儿，看着简单，RS-232、TTL、USB 转串口，一共没几条线，但实际排查起来，它恰恰是偶发故障的重灾区。所谓“串口假故障”，我指的是芯片本身没坏、目标板也没死，但整个链路的状态就是不对——打开串口助手收不到数据、发给设备没反应、偶尔又自己恢复。这种故障最气人，因为你去量引脚电平，往往又是正常的，一接上设备就掉链子。
2.1 假故障是怎么炼成的
串口链路由几段组成：电脑的 USB 口、USB 转串口适配器（常见 CH340、CP2102、FTDI）、连接线（杜邦线或成品线）、目标板的 UART 引脚，以及目标板的电源和地。任何一个环节的电气特性不达标，都会表现出“假故障”：
- USB 线本身质量差。很多廉价 USB 线只有电源线没有数据线，或者线芯细、屏蔽差，插上以后枚举不稳定，表现为串口号时而出现时而不见。
- USB 转串口芯片的驱动状态异常。CH340 在部分精简版系统下枚举很慢，打开串口助手时端口还没准备好，数据自然收不到。
- 连接线过长。TTL 串口的正常通信距离也就一两米，工业现场有人拉十米延长线，波形早就畸变了，偶尔通偶尔不通完全是常态。
- 供电不足。转接板从 USB 取电，同时给目标板供电，目标板外设一启动，电流一冲，电压跌落，串口电平跟着垮。
- 电平不匹配。3.3V 的转接板去连 5V 的目标板，或者反过来，逻辑电平不兼容时不是完全不能通，而是偶发错乱——有时收一帧对一帧错，非常容易误判成协议问题。
2.2 换机排除的实操步骤
面对这类问题，我的做法是严格按照链路顺序，逐段用已知良好的设备替换可疑设备。说的直白一点：不要试图同时怀疑所有环节，而是准备一套“基准测试环境”，然后把被测对象往这套基准里放。
这里的“基准测试环境”就是工作台上那套经过反复验证、确定没问题的串口调试组合：一台固定的电脑、一根质量可靠的 USB 线、一个 CH340 转接板、一套短杜邦线。接下来把故障链路里的组件一个个替换进来。
| 排查步骤 | 操作 | 排除的目标因素 |
|---|---|---|
| 第一步 | 换 USB 口，或者换另一台电脑 | 电脑 USB 口供电异常、主板静电保护、驱动冲突 |
| 第二步 | 换 USB 转串口适配器（CH340 换 CP2102 或反向） | 转接芯片驱动异常、芯片烧毁、劣质芯片型号造假 |
| 第三步 | 换 USB 线，使用短的、带磁环的成品线 | 线材劣质、数据线内部断裂、屏蔽不良 |
| 第四步 | 换杜邦线，或者直接焊接飞线 | 接触不良、线芯氧化、过长线缆导致信号畸变 |
| 第五步 | 给目标板单独供电，断开转接板供电 | 电流不足、电压跌落 |
| 第六步 | 换目标板样机，同一套转换器再试 | 单板硬件故障、引脚虚焊、电源异常 |
这六步走完，如果故障消失了，就能确认问题出在最后替换掉的那个环节；如果所有环节都换完了故障还在，那就不是链路问题，而是目标板自身的问题。这个方法看起来笨，但非常有效，因为每一轮都只改了一个变量，结论不会含糊。
有一个细节值得单独提醒：串口助手本身也会制造假故障。很多调试工具软件会默认记住上次退出时打开的串口号和波特率，如果你换了一个转接板，设备枚举的 COM 号变了，软件仍然盯着旧的 COM 号打开，当然收不到数据。我见过不止一次这样的案例，工程师换了好几根线，最后发现只是串口助手设置里的 COM 号错了。
2.3 案例复盘：一次“板子变砖”的误会
去年处理过一个项目，现场反馈一块 STM32L431 的板子在测试中突然“变砖”——串口完全没输出，按键无反应，指示灯微弱闪烁。测试员怀疑是固件跑飞了，准备重新烧录，结果烧录器也连不上。我接手后第一反应是别急着烧录，先把现场状态记录下来。
我按照上面六步排查，换了 USB 线、换了转接板、换了电脑，现象依旧。直到第五步，我拿万用表量板端 VDD，发现只有 2.8V——STM32L431 的最低工作电压是 1.8V 没错，但板上的射频前端和传感器对电压敏感，2.8V 下外设全部进入异常状态。再往下查，发现是转接板通过杜邦线给目标板供电，杜邦线太长，线阻太大，板子一启动电流上升，电压就被拉垮了。
结论非常打脸：板子从来没坏，是供电环节给了它一个“半死不活”的状态。换成独立供电之后，同一块板子在原串口链路上一切正常。这个案例给我最大的教训是：串口假故障往往不是串口的问题，而是藏在串口背后的电源问题。排查时务必把供电链路纳入视野，不要只盯着两根信号线。
3. 蓝牙断开的录屏取证与证据链构建
蓝牙偶发断连，是另一个非常典型的“口供不可靠”场景。蓝牙链路的偶发问题往往和射频环境、连接参数、电源管理、系统后台策略有关，如果只凭用户描述去猜，基本无从下手。我的做法是：把“描述故障”变成“提交影像证据”，用录屏和日志把断开的全过程固定在时间轴上。
3.1 为什么必须录屏：口供彻底不可靠
用户描述蓝牙断开时，会无意识省略掉大量关键信息。他说“断开了一会儿”，你永远不知道这“一会儿”是五秒还是五分钟；他说“自动重连了”，你不知道重连间隔是两秒还是十秒；他甚至不会告诉你断开时手机是不是锁屏了、设备是不是正在播放大音量音乐、周围是不是有其他蓝牙设备在活跃。
我经历过一次经典的“反复横跳”。客户说设备“偶尔断开又恢复”，我们换了天线、改了固件、调了连接参数，都没解决。后来让客户录了一段屏，才发现断开的频率远超他描述——不是偶尔，而是每隔几分钟就断一次，断开后三秒内自动重连。用户之所以说“偶尔”，是因为重连太快他根本没察觉。这根本不是一个“偶尔出现”的故障，而是一个“稳定复现”的结构性问题，只是用户无意识地美化了描述。
录屏的价值就在这里：它把模糊的口供替换成精确的时序事实。断开的时间点、持续时长、重连间隔、断开前后的界面状态，全部一目了然。
3.2 完整的录屏取证流程
取证流程我一般分四路，尽量对齐时间轴：
第一路是手机录屏。用系统自带的屏幕录制功能或第三方录屏软件，例如 AZ Screen Recorder。录屏时建议把手机的时间显示、电量百分比都露出来，这样后续对时间戳方便一些。从连接建立开始录，一直到断开后自动重连或者彻底断开，中间不要切走。
第二路是 PC 端的调试日志。如果被测设备连接着 PC 串口，用串口助手在后台跑着，每 100ms 打一个带时间戳的状态帧。这样，录屏里看到的断开瞬间，在串口日志里能对应到具体的事件代码。
第三路是蓝牙协议栈日志。Android 开发者选项里有“蓝牙 HCI 信息收集日志”开关，打开后系统会记录完整的 HCI 数据包。抓取完成后，可以在 Wireshark 里打开 btsnoop_hci.log 分析链路层的连接事件、断连原因、重连请求。iOS 也有类似机制，但需要额外工具读取系统日志。
第四路是射频环境记录。如果条件允许，用支持蓝牙嗅探的抓包器记录空口数据包，或者至少用手机上的蓝牙扫描类 App 记录周围 BLE 设备的广播量。蓝牙是共享 2.4GHz 频段的，周围的 Wi-Fi、其他蓝牙设备、微波炉，都会影响链路稳定性。
四路证据对齐之后，断开故障的现场就被完整定格了。
3.3 拿到录屏后怎么看：关键判据
拿到录屏和日志，不是看一眼就完事，而是要找几个关键判据。
第一，看断开发生在哪个阶段。是连接建立后立即断开，还是在数据交互一段时间后断开，还是在锁屏或切到后台时断开。这三个阶段的根因方向完全不同：前者往往指向连接参数或认证流程，中者多半指向功耗、发热、射频干扰，后者几乎必然指向系统后台策略。
第二，看断开前的空口状态。从 HCI 日志里拉出 RSSI 曲线：如果是渐进式跌落，说明设备在远离或信号被遮挡；如果是突然跳变，说明是干扰或电源跳变导致链路崩溃。注意，RSSI 只是参考，因为蓝牙的增益控制和天线方向会影响读数，但它能帮你判断趋势。
第三，看断开后的行为。是快速重连成功，还是反复重试后彻底放弃，还是重连后连接参数被重置。快速重连成功往往意味着链路本身没问题，问题出在链路维持的逻辑上——例如连接参数更新失败，或者协议栈进入了错误状态。
第四，看 Disconnect Reason Code。HCI 日志里每个断连事件都会附带一个原因码，例如 0x08（Connection Timeout）、0x13（Remote User Terminated）、0x3E（Connection Failed to be Established）。原因码不能直接当结论，但能大幅收敛思路。比如 0x13 一般意味着对端主动断链，去查对端软件逻辑；0x08 则是超时断链，去查空口丢包和重传。
我曾经处理过一个桌面蓝牙小音箱的断连投诉，现象是“播放十分钟就断，断开后五六秒又自己回来”。录屏加 HCI 日志跑了两天，终于看到真相：设备连接参数更新失败后，手机和模块陷入反复协商状态，每秒钟产生大量重传包，空口被自己的重传挤爆，链路最终超时断开。断开后模块重启协商，五六秒后恢复连接，然后循环往复。后续把连接间隔调大、开启从机延迟，彻底解决。如果没有录屏和日志，这个问题靠耳朵听是永远听不出来的。
4. “新旧批次对照”的烧录排查
烧录失败是嵌入式开发的高频问题，而“昨天烧得好好的，今天怎么都烧不进去”这剧情，几乎每个工程师都遇到过。这种场景最容易让人乱猜：有人怀疑 Keil 配置改了，有人怀疑烧录器坏了，还有人直接把芯片判死刑，换了三片都没用，最后才发现问题根本不在芯片上。
我的处理思路是“新旧批次对照”：保留旧批次芯片的留样，在完全相同的软件、工装、环境条件下，把新批次和老批次并排烧录。如果老批次能烧而新批次不能烧，变量就锁定在器件本身；如果老批次也烧不了，那问题一定出在工装、软件或环境上。
4.1 烧录失败的经典现场
先还原一下最常见的故障现场：
- 提示 cannot connect，烧录器找不到目标芯片；
- 提示 flash timeout，擦除或写入过程中超时；
- 提示 verify failed，校验的时候数据对不上；
- 或者更隐蔽的一种：烧录显示成功，但运行起来完全不正常，复位几次后程序丢失。
这个现场有几个特点：代码工程没有改动，烧录器和线缆是同一套，供电方式也没有变化，唯一变化的是“今天拿到的芯片是新批次”。所以大多数人的第一反应是“PCB 焊坏了”“芯片是坏的”或者“工程被同事改了”。
但实际排查下来，真相往往没那么简单。
4.2 新旧批次对照的变量拆解
所谓对照，本质上是一次严格的变量隔离实验。我在做之前会先把所有可能变量列成一个表，然后逐个排除：
| 变量域 | 具体变量 | 排除方法 |
|---|---|---|
| 软件侧 | 工程代码、编译器版本、库版本、链接脚本、宏定义 | 用 Git 对比 commit hash，检查工程目录的编译产物时间戳 |
| 工具链 | 烧录器型号、固件版本、线缆、转接板 | 换一套已知正常的烧录器和线缆，在新批次芯片上重烧 |
| 环境侧 | 供电电压、电源纹波、桌面静电、USB 口 | 用稳压电源独立供电，测量目标板 VDD，换机箱后置 USB 口 |
| 硬件侧 | 芯片批次、批次码、丝印版本、封装形式 | 新旧批次留样并排对比，核对 DataSheet 和批次丝印 |
这里有一个容易忽略的细节：软件侧不仅仅是代码，还包括编译器版本、芯片支持包（Pack）版本和烧录算法文件。很多项目拖久了，某次 IDE 自动更新了 Pack，或者同事装了新版本的编译工具链，生成的烧录文件结构变了，老批次芯片能接受，新批次芯片因为 Flash 扇区配置不同就烧不进去。所以对照实验的第一步，永远是先确认软件环境完全一致，而不是想当然认为“代码没改就是软件没变”。
4.3 锁定器件批次差异：从丝印到手册
如果确认软件、工具、环境都一致，只有芯片批次不同，那么就要把注意力放在器件本身。
第一步看丝印。同一型号芯片在不同批次的丝印编码里隐藏着大量信息。以 STM32 为例，丝印第二行的点阵码包含了晶圆批次和封装厂信息；很多国产芯片的批次号直接标注年份周数，例如“2145”表示 2021 年第 45 周。对比新旧批次的丝印，如果点阵码差异明显，就要引起警惕。
第二步查手册。重点看这几处：芯片默认的读保护等级是否一致、Flash 扇区和擦除粒度的版本差异、上电复位的时序要求、BOOT 引脚内部上下拉电阻的差异。不同批次之间，芯片内部的上电时序、复位延时、IDCODE 等参数可能存在微小但致命的差异。例如某些批次对复位脚的上拉电阻要求更严，原来的 10kΩ 上拉不够，导致烧录器无法稳定进入调试模式，表现出来就是连不上。
第三步做单变量验证。从旧批次留样中取一片芯片，焊到完全相同的 PCB 上，用同一台烧录器、同一根线、同一个供电配置去烧。如果旧批次能烧，新批次不能烧，基本可以断定问题出在芯片本身或芯片与板级设计的兼容性上。如果旧批次也不能烧，说明问题不在芯片，而在 PCB 或工装。
我遇到过一种特别隐蔽的情况：新批次芯片的复位脚对时序更敏感，烧录器发出的复位信号太短，芯片根本没进入调试模式。把烧录器的复位保持时间从默认值调大后，新批次也能正常烧录。这就是典型的“板级设计和芯片批次微调不匹配”，芯片本身没有任何质量问题，但就是和你的硬件设计八字不合。
4.4 烧录层面的对症操作
锁定了方向之后，有几类实操手段可以应对：
- 降低 SWD 时钟速度。很多烧录器默认用 4MHz 甚至更高跑 SWD，线缆稍长一点波形就畸变。把时钟降到 400kHz 甚至 100kHz，很多连接不稳定的问题会直接消失。
- 延长复位保持时间。前面提到的时序敏感问题，通过烧录器软件调整复位参数即可缓解。
- 目标板独立供电。有些烧录器可以给目标板供电，但电流余量很小，芯片一上电启动就拉垮电压，导致烧录器误判无法连接。改用稳压电源独立供电后，问题立刻消失。
- 尝试另一种烧录通道。SWD 不行就试 ISP/UART 烧录，或者反过来。这不是逃避问题，而是帮你区分故障域：如果换通道能通，说明芯片本身没死，问题出在调试接口的时序或电平匹配上。
- 检查芯片读保护。最容易被忽略的一个点。不同批次的芯片可能在出厂时的选项字节（Option Bytes）状态上存在差异，如果新批次默认启用了 RDP 读保护，烧录器连接时会报各种奇怪的错误。先执行整片擦除或者解除读保护再烧录。
上面这些操作，本质都是在把“烧录失败”这个问题从玄学拉回工程学：烧录器给出的错误码只是症状，真正的病因在链路、时序和芯片的电气接口上。
5. 偶发Bug排查的通用工具箱
三个案例讲完了，最后把这几年用顺手的工具和记录习惯整理一下。这些不一定是最高端的仪器，但绝对是排查偶发问题时最实用的家当。
5.1 硬件侧常用工具
USB 转串口模块建议备两个不同主控的：一个 CH340，一个 CP2102 或 FTDI。当怀疑转接芯片本身有问题时，直接换另一家芯片交叉验证，比重新下载驱动快得多。注意市面上有很多打磨重标的山寨芯片，标着 FTDI 实际是 CH340 的假货也不少，尽量从正规渠道购买。
逻辑分析仪是排查 UART 波形畸变的好帮手。不需要太高级，几百块的 8 通道 24MHz 采样率就够用。关键场景是把线接在目标板端的 TX/RX，看实际波形的波特率和电平，确认数据到底有没有从芯片发出来。
台式稳压电源比 USB 供电可靠得多。排查供电相关问题时，用稳压电源直接给目标板供电，电流限制设成 500mA 或更低，一旦有短路或异常电流，观察电流表就能快速发现。我在串口假故障案例里就是靠这个发现电压被拉垮的。
5.2 软件侧常用工具
串口助手类的工具比较多，我的习惯是固定用同一款，避免不同工具对端口的占用策略有差异。善用“HEX 显示”和“HEX 发送”模式，因为有些字符会被终端解释成控制字符，造成“没收到数据”的假象。
蓝牙排查方面，Android 开发者选项里的 HCI 抓包功能必须会开，Wireshark 必须会看 basic 的 HCI 事件和 ACL 数据包。iOS 设备建议用系统内置的诊断描述文件抓取日志，虽然麻烦一点，但效果比任何第三方 App 都好。
5.3 记录与追溯习惯
最后一个工具是纸和笔——或者更准确说，是一张严谨的测试记录表。每次做实验，至少要记下：
- 日期、环境温度（如果有条件）；
- 工程 Git commit hash，以及编译器版本；
- 硬件批次丝印、PCB 版本；
- 供电方式、线缆编号、烧录器序列号；
- 复现步骤和现象描述，尽量附上照片或录屏。
这些记录看着繁琐，但只有在翻车之后才知道它们值多少钱。就拿“新旧批次对照”来说，如果你没有批次记录，不知道手里的芯片是哪一批，对照实验就无从谈起。如果你没有 Git hash，两个人各改了一版代码，你根本说不清到底烧的是哪个版本。
我现在的习惯是，只要遇到偶发 Bug，第一反应不是急着动手修，而是先把现场锁住，把证据留下来，把变量一个个排掉。真正解决过几个案例之后你会发现，所谓偶发，多数只是在某个边界条件下稳定复现的必然，只是我们还没把环境变量观察全而已。下次再遇到“怎么都查不出来”的问题，别急着怪芯片，先把那根线换了试试。
