嵌入式调试偶发Bug三招：换机排除、录屏取证、批次对照

做嵌入式调试久了会发现，真正磨人的不是那种一复现就能确认的 bug，而是“偶尔来一下，你一动它就好”的怪问题。串口用着用着丢一帧、蓝牙听歌听一半自己断开、烧录十次成功八次却偏偏失败两次，都会让人血压升高。这类偶发问题之所以难，是因为它太依赖环境和时序，而且现场往往没留下证据。这段时间我集中处理过串口、蓝牙、烧录三块的问题，也踩了不少坑，最后总结出来三招最实用：串口假故障就换机排除，蓝牙偶发断连就录屏取证，烧录不稳定就做新旧批次对照。下面把整套思路和具体操作拆开讲，希望能帮到正在跟偶发 bug 较劲的朋友。

1. 先拆解偶发bug：它大概率不是玄学

1.1 偶发bug的三个典型成因

偶发bug的麻烦在于，它的表现可能完全一样，但根因却千差万别。我自己总结，绝大多数偶发问题逃不出三类成因。

第一类是时序竞争。上电时各路电源的先后顺序、中断响应和主循环执行到一半的状态、Flash写操作被中途打断，都可能造成随机失败。这类问题尤其容易出现“换个环境就消失”的情况。比如一个串口中断服务函数里，如果既读数据又清标志，表面逻辑没问题，但一旦主循环刚好也在操作同一块缓冲区，就会偶发丢数据。你回过头用示波器抓波形，可能什么都抓不到，因为触发条件是两条指令在同一千分之一秒内撞上了。

第二类是物理层临界状态。接口接触不良、信号电平刚好落在门槛附近、线缆受到外部干扰，都属于这一类。这类问题最迷惑，因为拿万用表去量的时候它又正常了，于是被判断成“假故障”。串口偶发乱码、蓝牙不时断开，很多时候不是协议栈的问题，而是物理层已经处在悬崖边上。温度一变、线缆动一动、USB供电稍微波动，就掉下去。

第三类是环境变量没有被固定。芯片批次更新了、固件升级了、USB驱动变了、换了一个烧录器，这些变量只要有一个变化，就可能触发问题。而我们在测试的时候经常同时换好几个东西，问题复现后又无法确认到底是哪一个改变的。曾经有个朋友跟我说“换了芯片型号后整个系统都不稳”，我问他同时换了什么，他说顺手把杜邦线也换成排线了，还把电脑从Win10升到了Win11。这种多个变量一起变的情况，再厉害的调试验证也白费。

所以偶发bug不是玄学，而是我们掌握的变量不够。要找到它，首先得把“可能变化的因素”拆出来。

1.2 建立你的排障主线：隔离变量、固定证据

面对偶发bug，我习惯用两条主线推进：一条是隔离变量，另一条是固定证据。

隔离变量的意思是，每次只改变一个变量。很多人一遇到问题就同时换电脑、换线、换芯片、换固件，如果问题消失了，根本不知道是谁的功劳。正确做法是先列一个变量清单，包含电脑型号、USB口、线材、转接芯片、波特率、供电方式、软件版本、硬件批次，然后一次动一个，并且记录结果。哪怕结果看起来“好像好了”，也要再恢复原样验证一次，防止误判。

固定证据的意思是，在问题还没有复现的时候，先把现场能抓到的信息抓下来。偶发bug最怕事后回忆，因为人的记忆会美化现场，也会漏掉细节。把日志、截图、录屏、软件版本号、芯片丝印批次都留下，才能给后续分析提供素材。

后面要讲的换机排除、录屏取证、新旧批次对照，本质上就是这两条主线在三类典型场景下的落地。换机排除对应隔离电脑侧的变量；录屏取证对应固定操作时序和现象；新旧批次对照对应隔离硬件和工具链的版本变量。想通这一点，你就不会把这三招当孤立技巧用了。

2. 串口假故障：换机排除法怎么操作最有效

2.1 串口假故障长什么样

所谓“串口假故障”，不是说bug不存在，而是指设备本身没有坏，但系统或排障者误以为它坏了。常见几种表现：

• COM口在设备管理器里时有时无，插拔后能恢复。
• 串口调试助手能打开端口，但接收区偶尔多几个乱码，或者数据粘包。
• 上位机报“打开串口失败”，但重启软件、重插USB后又能工作。
• Linux下设备节点出现，一读取就丢数据，或者第一次打开正常，第二次打开就卡死。

这些现象如果只出现一两次，很多人都会直接归因于“串口不稳定”“芯片质量差”。但我实际遇到的情况里，相当一部分根因其实在电脑侧、线材侧或者供电侧。

我曾经遇到一块设备板，在办公室调试一切正常，拿到客户现场后，上位机每十分钟就失去响应。现场工程师怀疑是串口芯片损坏，要换板。我让他先别换，把笔记本从USB HUB改到电脑后置USB口，同时换掉一根一米五的USB延长线，问题就再没出现过。这就是典型的假故障：USB口供电不足和劣质延长线造成了USB层面的偶发掉线，但看起来像是串口坏了。

2.2 换机排除的标准顺序

换机排除，不是简单说“换一台电脑试试”，而是有一套能落地的顺序，否则容易得出错误结论。我先给一个标准顺序表，每一步都记录结果。

顺序的逻辑是，先做成本最低、影响面最大的动作。不要上来就换板，板子往往没问题，换来换去反而浪费时间。

实际操作时还要注意，Windows上换电脑前最好把旧驱动彻底卸载，再装新驱动。因为很多“换机后正常”的结论，其实是换了驱动版本得到的，不是电脑本身的问题。Linux上则要注意权限和udev规则，有时候/dev/ttyUSB0被别的进程占用，用lsof查一下就知道。还有一点，换机后要保留原有的波特率、校验位、停止位、流控设置，不要顺手改参数，否则你分不清是换机起效还是参数变化起效。

使用串口调试助手时，建议不要一次性发大量数据，而是先发一小段测试。如果小数据正常、大数据丢帧，问题多半在缓冲区或流控，而不是电脑。

2.3 容易被忽略的底层原因

串口假故障背后，有几个底层原因很容易被忽略。

第一个是USB转串口芯片的驱动差异。CH340、CP210x、FTDI、PL2303这些芯片，在Windows下行为不完全一样。某些系统用CH340时，枚举速度慢，打开端口后第一帧数据可能丢失。如果上位机没有做重试，就会表现为偶发无响应。这种情况换一台装有另一种芯片转接线或转接板的电脑，往往就稳定了。

第二个是波特率误差。串口收发双方的波特率是分频出来的，如果两边晶振精度不同，误差超过一定阈值就会出现偶发乱码。尤其当收发双方分频后的误差方向相反时，短数据没事，长数据就出问题。可以用示波器量一下实际波形和理想波形的偏差，或者用串口调试助手循环发0x55 0xaa这类测试字符观察稳定程度。

第三个是电平匹配。很多嵌入式板是3.3V电平，USB转串口有的是3.3V，有的是5V电平，TTL转RS232或者外接电平转换电路有焊接问题，都会导致信号落在临界区。偶发故障和温度、线长都有关系，非常难查。对于这种情况，用回环测试能快速定位：把目标板的TX短接到RX，在电脑端自发自收。如果回环稳定，说明电脑和线缆没问题；如果回环都乱码，问题很可能在转接电路或线缆。

另外，串口和烧录常常是同一套通路。后面要讲的烧录排查里，很多“烧录失败”其实也是串口假故障的一个变体。先用换机排除法把USB转串口链路确认好了，再去做烧录对照，会少走非常多弯路。

2.4 串口排查速查清单

为了方便日常使用，我把串口假故障排查整理成一个速查清单，遇到问题可以照着走：

• 先确认是USB层还是串口层。打开设备管理器，观察插拔时端口是否消失；在Linux下用dmesg | grep ttyUSB看枚举是否正常。
• 串口调试助手打开失败时，先看进程是否占用端口，Windows下用任务管理器关闭残留进程，Linux下用lsof /dev/ttyUSB0。
• 用回环测试隔离目标板。短接TX/RX，有输出就说明链路通，问题大概率在对方设备或上位机逻辑。
• 检查供电。很多USB转串口模块的3.3V输出是给外接电平敏感电路用的，不能给整板供电；目标板供电不足会导致偶发数据异常。
• 逐个更换USB口、线、转接芯片、电脑，每换一步都记录现象。
• 如果问题只在特定软件出现，试试换一个串口调试助手或虚拟串口软件做对照，排除上位机缓存逻辑问题。

这张表不是万能的，但能帮你把“设备坏了”这个结论往后放一放，先把免费的变量排除干净，再动硬件。我对同事的建议一直是：串口偶发故障，先怀疑线，再怀疑驱动，最后才怀疑板，顺序反了会越查越乱。

3. 蓝牙断开：录屏取证还原现场

3.1 为什么录屏能解决“偶发”断连

蓝牙问题比串口更隐蔽，因为它牵涉到两端的协议栈、射频环境、音频模式和连接参数。用户反馈“听歌偶尔断”“连不上”“一打电话就断”，如果我们只靠口头描述去猜，很难定位。尤其是偶发断连，复现时你可能错过关键操作，等你想抓日志，它又不断了。

录屏取证的价值在于：它把“操作时序”和“现象时间点”原原本本记录下来。我们不仅要录手机屏幕，还要把电脑上的串口日志或者蓝牙日志也录进来。通过时间轴对齐，就能看出断开之前发生了什么：用户点了什么按钮、信号强度如何、是不是正在切换音频设备。很多蓝牙问题其实是操作序列触发的，不是随机发生的。

我处理过一个案例：用户说蓝牙模块“老是连不上”，录屏后发现他点击设备列表后，系统还没完成服务发现就再次点击，造成一次连接被中断。这属于手机端操作逻辑问题。如果没有录屏，我们很可能去查模块的AT指令配置，白查半天。

3.2 录屏+日志+抓包三件套

我把蓝牙偶发断连的排查拆成三件套：录屏、日志、抓包。

第一件，录屏。手机上打开“显示触摸操作”和“指针位置”，保证操作过程可见；横竖屏固定住，确保时间显示清晰。录屏范围尽量包含手机状态栏，因为状态栏有时间和蓝牙图标，方便和日志对齐。电脑端如果是连接蓝牙适配器做测试，可以用OBS或Windows自带录屏，把桌面和串口调试助手窗口录下来。

第二件，日志。Android手机可以用adb logcat -v time打开带时间戳的日志，过滤蓝牙相关信息；iOS设备则需要通过Xcode的Console抓syslog。电脑端如果跑蓝牙模块，可以用原厂的AT指令日志，或者在串口端记录模块返回的OK/ERROR。关键是日志必须带时间戳，否则无法和录屏对齐。

第三件，抓包。在电脑上使用btmon或者bluetoothctl monitor，抓HCI事件；支持蓝牙嗅探的硬件可以抓射频空包。抓包主要看断连前最后一次控制层面的交互，是链路层丢失了应答，还是HCI断开连接的通知，还是底层ACL超时。这些信息在日志里看不到。

实际操作时，我一般先开录屏，再开日志，最后开抓包，三者在同一台测试机上同步。触发几次问题后，把三份数据按时间线整理好，基本可以还原完整因果链。

# Android 上抓蓝牙日志（需要先运行 adb devices） adb logcat -v time | grep -iE "bluetooth|bt_a2dp|bt_avrcp|hfp" # Linux 上抓 HCI 事件 bluetoothctl monitor on

3.3 两个真实排查案例：HC05重配对失败与A2DP切SCO断连

挑两个我实际处理过的案例，展示录屏取证怎么用。

第一个是HC05蓝牙模块。客户反馈“之前能连，现在连不上”，这其实是很常见的场景。我让客户录屏，发现他在手机蓝牙设置里点击HC05连接，系统显示“配对失败”，整个过程只有两三秒。从日志看，模块没有返回任何响应。再查模块本身，发现HC05的AT指令状态不对。因为HC05模块掉电后参数可能维持也可能改变，如果之前被别人用AT指令改过密码或配对模式，手机端旧配对信息就失效了。让客户在配对前先取消旧设备、再重新扫描，同时用AT指令把模块恢复默认设置，问题解决。这个案例里录屏帮我确认了不是射频问题，而是上下文的配对状态不一致。

第二个是手机连接蓝牙音箱，放音乐一切正常，有电话进来接听的一瞬间断连。这种问题常见于蓝牙的A2DP和SCO切换场景。录屏可以看到断开发生在接听动作之后，HCI抓包显示系统同时在建立SCO链路和HFP服务，而音箱端也在主动切换模式，导致两边状态冲突。处理方式有几种：在模块端固定为只能使用A2DP，或者调整HFP profile支持，或者修改AT指令里的音频连接策略。如果没有录屏，单凭“断连”两个字，排查范围会扩大很多。

再补充一个和MTU相关的点。BLE连接后，如果手机请求的MTU和从机协商不一致，会造成分包异常，表现出来也是偶发断开或数据传输不完整。很多人在网上搜“蓝牙模块mtu”，就是这个问题。录屏时最好把数据收发界面的字符也录进去，对比收发字节数，有时候比抓包更直接。

3.4 证据整理用这张表

调查结束后，证据整理比调查本身更影响结论。我自己习惯用一张表把录屏和日志串起来，避免各说各话。

做这张表时有一个容易犯的错：只看录屏不看日志，或者只看日志不看录屏。时间戳不一致时，一定要先把时间校准。手机录屏自带的时钟可能慢几十秒，最好在录屏开始时对比一次电脑时间，后面对齐时统一平移。日志同理。

录屏文件名也建议规范化：日期_设备_场景_现象.mp4，比如20250219_esp32_a2dp切sco断开.mp4。这样后续回查历史问题会非常省事。我自己吃过教训，录了十来个视频，文件名全是“temp”，结果一个月后想复盘，根本分不清哪个是哪个。

4. 烧录失败的“新旧批次对照”排查法

4.1 烧录失败偶发的根源在五方协作

烧录看着很简单，其实是五方协作：上位机软件（Keil、乐鑫烧录工具、STC-ISP、Arduino IDE）、USB转串口或烧录器、连接线、目标芯片和电源。任何一方处于临界状态，都可能表现为偶发失败。

我见过最多的场景是这样的：第一次插上板子能烧，拔掉重插后失败；或者烧十次成功八次，失败的那两次必须在烧录前手动复位一下。这种偶发问题，如果只用“多试几次”心态，可能会浪费很多时间。更稳妥的是先把它当成环境问题，而不是芯片问题。

烧录失败还有一个特点：它和串口假故障经常纠缠。多数低端芯片的烧录链路就是UART，比如STM32的串口ISP、ESP32的UART下载、STC系列、CH32等。如果USB转串口链路本身有偶发丢数据，那烧录自然也会偶发失败。所以做烧录排查前，我建议先用换机排除法确认串口链路干净，然后再做下面说的新旧批次对照。

4.2 四维对照设计：硬件、固件、工具、方式

“新旧批次对照”这个名字听起来像只对比硬件批次，但实际上要建立起四个维度：硬件批次、固件版本、工具链版本、烧录方式。

四维对照的基本思想是：让所有变量里只有一个不同，其他全部保持固定。比如怀疑新批次芯片有问题，那就用新旧两种批次电路板，在同一个电脑、同一个烧录器、同一条线、同一个烧录软件、同一个固件bin文件下交替烧录。如果只有新批次失败，说明问题在硬件批次；如果新旧都失败，说明问题在环境或工具链。不要同时换电脑和换芯片，否则永远不知道结论该算谁的。

我通常会在笔记本上列一张矩阵，横轴是硬件批次，纵轴是烧录方式，然后批量测试。这里给一个实际用过的模板。

这个例子就说明，新批次芯片对SWD时钟频率更敏感，降频后恢复了正常。如果只做“新旧批次对照”而不测频率，会误以为是芯片跟旧版不一样，最终可能把问题掩盖掉。

对串口ISP类烧录，常见的可调变量有波特率、短接复位或BOOT引脚的方式、上电时序、等待时间。把这些变量也放进矩阵里，能帮你找到最佳组合。

4.3 不同类型芯片的批次排查差异

不同芯片的烧录细节差异很大，我分别说几个常见系列。

STM32系列经常用的Keil5烧录失败，弹“No target connected”或者“Flash Download failed”。这种问题优先检查SWD的时钟频率，新批次PCB如果走线长了，高频就挂。把频率从10MHz降到4MHz往往能解决。还有芯片的读保护、写保护状态，新批次如果设置了选项字节，烧录器无法写入，表现为偶发失败。

ESP32的烧录通常用串口的GPIO0下拉进入下载模式，另外EN脚复位时序要正确。如果新旧批次烧录失败比例不同，先检查GPIO0的上电状态是否稳定。乐鑫烧录工具或esptool.py版本不一样，默认波特率也不同，高波特率更容易受USB转串口质量影响。可以先用低波特率跑：

python -m esptool --port /dev/ttyUSB0 --baud 115200 write_flash 0x1000 app.bin

如果115200稳定而921600失败，说明链路余量不足。

STC8G1K08A这类芯片只能用厂家ISP工具烧录，烧录时序依赖冷启动：先点下载再给板上电，而且对复位电容很敏感。新旧批次对比时，要记录电源电容容值、晶振频率、串口电平。有个常见坑：新批次换成了更小的贴片电容，导致冷启动瞬间芯片复位不彻底，偶尔下载失败。

Arduino给UNO烧bootloader，一般需要把Arduino Uno当成ISP，使用ICSP接口。如果新旧批次板卡差异导致ICSP线序或供电不稳，也会偶发失败。把master板换成另一个Uno，或者缩短ICSP线，就能看出来。这里重点测的是SPI速度，可以在IDE的boards.txt里调整ISP时钟，有些版本默认太快。

还有CH32X035这类国产芯片，烧录工具和驱动兼容性一般，驱动版本变化会导致偶发连接失败，通常需要降级软件版本。所以工具链版本也必须记录在对照表里。

4.4 固化烧录环境，让偶发变成可追踪

在批量生产环境中，偶发烧录失败最怕两点：一是没有记录，二是没有标准环境。我建议直接把烧录环境固化下来，像软件工程的“锁版本”一样。

具体可以准备一份“烧录环境快照”，里面至少包括：烧录软件名称和版本、驱动版本、USB转串口芯片型号、USB线编号、烧录器型号、固件版本、目标芯片型号与批号、供电方式、波特率或时钟频率、烧录命令。每次烧录前核对快照，出现失败就立刻对照差异。

如果是生产环节，还要给每块板、每个烧录件建立批次台账。记录不良率、失败时的环境温湿度、烧录台编号。往往环境和批次数据一旦拉出来，规律就出来了。比如“新批次在周三下午失败率高”，后来发现是那台电脑的USB口被频繁插拔导致接触不良，跟芯片批次没半毛钱关系。

这些做法看起来繁琐，但对付偶发烧录失败，省下的调试时间远远大于记录时间。反正我后来的体会是：真正有效的排查，不是靠灵光一现，而是靠记录和对照。

5. 通用化：把三招组合成一套排障心法

5.1 三种方法的底层逻辑

你回看会发现，这三招其实是同一种心法在三个场景里的变体。

换机排除，做的是“环境隔离”。它把可疑的电脑、接口、线材从系统里摘出去，用一台干净的设备做参照，判断问题到底在设备侧还是使用侧。

录屏取证，做的是“事件还原”。它对无法稳定复现、依赖操作序列的问题，把现场的全过程按时间轴记录下来，让“感觉它不稳”变成“具体哪一步触发了它”。

新旧批次对照，做的是“版本追溯”。它对软硬件更新导致的回归问题，用矩阵式对照把变量逐一锁死，找到真正生效的那个维度。

这三招组合起来，就是一套完整的偶发bug打法：先隔离环境，再固定证据，最后用版本对表。不管是串口、蓝牙还是烧录，都可以套用。

5.2 一个可以抄走的排障记录模板

最后分享一个我常用的排障记录模板，按这个模板写，信息基本不会缺。

里面的信息，大概率能支撑大多数偶发bug的定位。如果你正在排查一个断断续续的问题，不要急着怀疑“硬件坏了”，先从这些字段开始，一个个填满再说。

说实话，这些东西没有一项是高深理论，全是最笨的记录、对照和换机验证。但恰恰是这些“笨办法”能对付偶发bug。我自己踩过坑，也看过同行因为不记录，反复掉进同一个“偶发”的坑里。如果你现在正被某个偶发串口乱码、蓝牙断连或烧录失败折磨，我的建议很简单：先别换板，先换环境；先别猜，先录屏；先别改，先对照。把能记录的都记录下来，给bug一个完整的“现场”，它就不再那么神秘了。