偶发 bug 这东西做硬件和嵌入式的人十有八九都遇到过。最气人的不是它多难修而是它“看心情”出现——你盯着它的时候它乖得很你一转身它就冒出来等你想抓现场了它又消失得无影无踪。串口偶尔丢一帧、蓝牙用着用着断开、烧录十个板子挂一个这种问题单看现象根本无从下手盯着代码翻一天也未必有收获。这篇文章我用三个真实踩过的坑来展开串口假故障怎么通过换机排除、蓝牙断线怎么用录屏加日志锁定真凶、烧录偶发失败怎么做新旧批次对照。这三件事听起来是不同方向背后其实是同一套排查逻辑——把“偶发”变成“必然”把“玄学”变成“证据”。如果你是做单片机、物联网设备、调试工具链的或者被某个偶发问题折磨得睡不着的这篇文章应该能给你一些可以直接照抄的思路。1. 偶发 bug 为什么这么难查先搞懂它背后那点破事1.1 偶发问题的本质是信息不对称偶发 bug 难不是难在修而是难在复现。正常 bug 就像你写了个while(1)忘记退出了程序死得明明白白IDE 一停就知道挂在哪一行。偶发 bug 完全不是这个玩法它的出现往往取决于一堆你根本没有监控的变量供电电压跌了那么 0.1 伏、某个中断晚到了几十微秒、USB 枚举时序差了那么一点点、芯片批次不一样导致内部上拉电阻阻值漂移——任何一个微小的物理量变化都可能成为压垮骆驼的最后一根稻草。做硬件调试我特别认同一句话偶发问题不是随机产生的它只是触发条件没被找到。所谓“偶发”大概率是某个触发窗口非常窄、平时很难碰上而已。比如串口丢帧可能是 DMA 缓冲区在特定时序下被覆盖蓝牙断连可能是设备进入 sniff 模式后主机在某个瞬间没回应烧录失败可能是供电在 erase 阶段瞬间跌落。这些问题每个都有明确的物理原因只是它们组合在一起的时候才爆发单独看哪个好像都没毛病。明白了这一点排查思路就清晰了我们做的所有动作——换机、录屏、日志、批次对照——本质都是在扩大信息采集范围把那些隐藏的触发条件一个一个暴露出来。1.2 排查偶发 bug 的三板斧证据链、环境快照、对照实验那具体怎么操作我自己最常用的是三个手段第一建立完整的证据链。偶发问题很忌讳“我记得当时怎么怎么样”这种模糊描述。录屏、日志、串口抓包、波形记录能留多少留多少。后面蓝牙断连那个案例就是靠录屏加日志时间戳锁定的没有录屏只靠记忆那个 BLE 广播间隔的问题再猜一个月也猜不出来。第二记录环境快照。出现问题时把当前环境信息全部记下来供电电压、温度、连接的设备型号、固件版本、硬件批次、杜邦线还是排线、USB 口是前置还是后置。每一个看起来无关紧要的细节都可能成为对照实验的关键变量。我自己习惯在工位上放一个本子专门记这些“奇怪的现场”时间久了回头翻经常能发现规律。第三做受控的对照实验。一次只改变一个变量不要同时换线、换电源、换模块、换电脑。否则哪怕你运气好修好了你也不知道到底是哪个动作起了作用。这也是下面三个案例里反复出现的核心方法。1.3 心态建设偶发 bug 排查是持久战最后想说点心态上的事。偶发 bug 排查特别容易让人烦躁因为大部分时间你都是在“等 bug 出现”而不是在“修 bug”。这种等待很容易让人自我怀疑是不是自己水平不行是不是方向错了是不是应该先把整个系统重写一遍我的经验是越是想快速解决越是容易瞎折腾。瞎折腾的表现就是同时改一堆代码、换一堆硬件最后问题不出现了但你根本不知道为什么。真正有效的做法反而是慢下来先把排查框架搭好明确每一步想要验证什么假设然后用最小代价去做实验。90% 的偶发问题最后都不需要大改代码真正改的往往只是一个初始化时序、一个去抖延时、一个供电去耦电容。2. 串口“假故障”排查实战从换机开始层层剥茧2.1 什么是串口假故障现象、危害与判断方法先说说串口。串口大概是嵌入式调试里最常用、也最容易出诡异问题的外设了。串口假故障我指的是那种“看起来像坏了、实际上没坏”的情况。典型表现是设备跑着跑着串口突然没有输出了或者输出全是乱码你拔下线重新插一下又好了或者重启一下设备又恢复正常了。这种问题之所以叫“假故障”就是因为重启之后一切正常让人以为只是偶发的小毛病结果它三不五时又犯一次。危害恰恰在这里——它不会让你的设备彻底挂掉但会严重消耗你的调试时间。你可能为了排查这个问题改了一堆串口初始化代码加了各种超时重试机制最后发现根本不是软件的事。判断是不是假故障有个很简单的办法把故障现场的串口线拔下来用一根好的线接上去。如果立刻恢复正常那大概率是线材或连接器问题如果还不行再看是不是 USB 转串口模块、驱动、或者设备端串口外设的问题。这个动作听起来简单得像废话但实际中很多人都跳过这一步直接去查代码。2.2 换机排除法一次只换一个变量的经典示范我在调试一块基于 GD32F470 的板子时就踩过这个坑。设备症状很诡异串口打印日志有时候正常有时候输出到一半突然截断偶尔还会蹦出几个乱码。刚开始我怀疑是固件里串口 DMA 配置有问题因为项目用了 DMA 发送理论上缓冲区管理稍有疏忽就会出现这种“半截输出”的情况。我花了两天时间反复查 DMA 的描述符、中断优先级、缓冲区的读写指针怎么看都没问题。后来我换了一根串口线问题居然就没了。再拿旧线去测发现是这根线的屏蔽层断了在设备启动瞬间电流波动时会偶发干扰数据线。这就是典型的换机排除法——我一开始假设是固件问题但其实问题在物理层。换机排除法的核心逻辑是故障可能出现在链路中的任何一环从设备端到中间线缆再到上位机每一环都要单独验证。一次只换一个变量换完立刻测试确认是否解决不要同时做两件事。2.3 USB 转串口模块的坑CH340、CP2102 与 FT232 的差异换线没用的话下一步就是换 USB 转串口模块了。市面上一堆 CH340、CP2102、FT232看起来功能都一样但实际用起来差别不小。CH340便宜大碗兼容性尚可但有些寨板的晶振精度不够波特率一旦超过 115200 就容易出现误码。我实测过一些劣质 CH340 模块在 921600 波特率下乱码概率明显上升。CP2102稳定性和驱动兼容性比 CH340 好但也有假货芯片遍地的问题用的时候注意辨别来源。FT232老牌贵族兼容性、稳定性口碑最好但价格贵假货也最多。如果调试环境里 USB 口供电质量差FT232 的抗干扰能力确实有优势。在串口假故障排查里USB 转串口模块是很容易被忽略的一环。很多工程师习惯桌面上一排模块随手抓一个就用但恰恰是这些看似不起眼的设备可能才是乱码和丢数据的源头。我的建议是准备至少两个不同主控比如 CH340 和 FT232的模块交叉验证。如果换了模块问题消失基本可以确认是模块本身的问题而不是设备端固件的问题。2.4 软件层面的串口排查dmesg、stty 与波特率误差分析硬件排查没问题之后再看软件。先说 Linux 环境——不少物联网设备调试是在 Linux 上做的串口设备名通常是/dev/ttyUSB0或/dev/ttyACM0。排查步骤用dmesg | grep tty看内核有没有识别到设备有没有报错信息。用stty -F /dev/ttyUSB0 -a查看当前串口参数确认波特率、数据位、停止位、流控是否和预期一致。用cat /dev/ttyUSB0直接看原始数据流注意别让其他程序占用串口。如果要抓二进制数据也可以用hexdump看具体字节内容别只看打印出来的 ASCII 字符。波特率误差是另一个常见的坑。假设你的设备端晶振是 12MHz理论值和实际值差了千分之一短时间内没问题但数据一长累计误差就可能让某一位采样落在不该采的位置于是出现偶发乱码。计算方法是实际波特率 时钟频率 / 分频系数误差率 (实际值 - 理论值) / 理论值 * 100%。一般要求误差在 ±2% 以内但稳妥的设计建议控制在 ±1% 以内。很多国产芯片的时钟校准寄存器没配置好出厂默认误差偏大就会出现“用着用着突然乱码”的诡异现象。2.5 串口干扰的物理层排查地线、供电与线材屏蔽再往深挖一层是物理布线。我调试一块 ESP32 小车时遇到过串口数据偶发丢失的问题现象比刚才那个还隐蔽——不是因为线断了而是因为电机驱动瞬间电流大地线上产生了几十毫伏的电位差直接污染了串口信号。排查这种干扰问题核心是检查共地是否可靠。如果你的设备是电池供电USB 转串口模块是电脑供电两者之间如果只靠信号线连接地回路阻抗偏高电机一转就会出现明显的信号失真。解决方法是把 USB 转串口模块的 GND 和设备 GND 用粗短线直接相连确保共地阻抗足够低。供电方面部分 USB 转串口模块是直接从 USB 口取电的电流一大电压就往下掉。如果模块本身还需要给目标板供电我强烈建议单独用稳压电源给目标板供电别指望从 USB 口取电能稳定输出 5V。特别是在烧录、擦除 flash 这类大电流操作的瞬间电压跌落经常导致一些莫名的“偶发失败”。线材也要讲究。调试用的串口线建议选带屏蔽层的成品线长度不要超过 30cm别为了图方便用那种一捆一米多的杜邦线堆在桌上。大家可能觉得我在小题大做但实际上很多偶发串口问题就是在这种细节上翻车的。2.6 串口 FATAL 案例DMA 与中断优先级导致的“假死”最后补一个很典型的“软件假故障”案例串口 DMA 发送完成后没有及时清理标志位导致下一次发送时 DMA 控制器认为还在忙数据压根没发出去。这种问题在 GD32、AT32 这类国产 ARM 芯片上尤其常见——它们的 DMA 控制器实现和 STM32 有一些细微差异不少人按 STM32 的习惯写代码搬过来就容易踩坑。表现也很像假故障系统正常运行串口突然就“哑”了。查代码看不出问题重启又正常了。这种问题的排查思路是在串口发送函数里加一个超时强制清理 DMA 标志的逻辑同时用逻辑分析仪抓 DMA 请求信号确认是不是真的触发了。我之前调 AT32 串口 DMA 发送时发现只要改一下 DMA 通道优先级问题就消失了——因为低优先级的 DMA 请求在高负载下会被无限推迟表面看就是“串口偶尔没反应”。3. 蓝牙断开录屏取证从现象到证据链的完整闭环3.1 为什么要录屏偶发断连的问题描述不可靠蓝牙偶发断开这个问题比串口更磨人因为它牵涉的链路更复杂主机手机/电脑、蓝牙协议栈、设备端射频、天线环境任何一个环节出问题都可能导致断连。更麻烦的是用户反馈的“断连”往往描述不清——“用着用着就断了”“好像是一动就断”“感觉是连上几分钟就掉”这些信息根本不足以定位问题。我的做法是必须让反馈者录屏。录屏可以记录断连的准确时间点、当时的操作动作、设备端的状态灯变化这些信息比任何口头描述都靠谱。很多人在排查蓝牙问题时觉得录屏多此一举但对我来说录屏是重建现场最重要的工具。有个真实案例用户反应某蓝牙键盘时不时断开特别是打字速度快的时候。看文字描述很难判断是键盘掉线还是系统主动断开。后来用户录了屏我反复看了几遍发现一个细节——键盘断开的瞬间屏幕上刚好弹出了系统输入法切换的窗口。这意味着系统的蓝牙驱动在某个系统事件触发下做了异常处理问题根本不在键盘端。如果没有录屏我可能还在傻乎乎地查 HID 报告描述符。3.2 录屏怎么录才有用时间戳、状态灯与操作动作缺一不可录屏可不是随便拿手机拍个视频就完事有几个细节必须做到位一是屏幕录制和应用内日志同时开这样视频和日志能通过时间戳对齐。手机上可以打开开发者选项里的“蓝牙 HCI 日志”或者用 Logcatadb logcat -b all记录系统日志排查蓝牙问题时 Logcat 里能搜到BluetoothDevice、BluetoothGatt相关条目。电脑上可以用微软的 Bluetooth 日志功能或者 Linux 的btmon。二是把设备端的状态灯拍进去。很多蓝牙设备都有 LED 指示灯不同状态对应的闪烁方式不同。视频里能看清状态灯的变化就能判断是设备端先掉电、还是主机端先断连。比如指示灯如果突然熄灭说明设备端可能是电源问题如果灯还亮着但系统已经显示断连说明是链路层断开了。三是录屏期间的操作动作要自然、完整。不要只录断连发生后的那段而是从连接成功开始到正常使用一直到断连发生为止。这样才能看出断连和操作之间有没有关联——是不是某个特定按键、某个特定角度、某个特定距离会触发断连。3.3 抓取蓝牙 HCI 日志让“断开”不再玄学光有录屏还不够蓝牙问题最终还是要看协议层的数据。HCIHost Controller Interface日志是蓝牙调试的宝矿它记录了主机和蓝牙控制器之间所有的命令、事件和数据包。开启方式各平台略有不同Android 开发者选项里有“打开蓝牙 HCI 信息日志”开启后系统会把 HCI 数据写到/data/misc/bluetooth/logs/下用adb pull可以拉出来。iOS 需要用到 Xcode 的Logger工具。Windows 可以用 Wireshark 加USBPcap或者蓝牙专用过滤器。Linux 下直接装btmon或者用hcidump用起来非常趁手。HCI 日志拿到手之后用 Wireshark 打开重点看断连前后的数据。我最常用的过滤条件btrfcomm.dlci或btl2cap.cid看某条逻辑信道的活动。btatt.opcode看 ATT 层的读写操作用于排查 GATT 连接是否异常。直接看Disconnect事件看断连原因字段——0x08表示连接超时0x13表示远端设备关闭连接0x3E表示连接失败0x16表示不接受新连接不同的原因代码对应的排查方向完全不同。3.4 与录屏时间轴对齐实例解析蓝牙 HID 断连说个我用 HCI 日志和录屏对齐解决的例子。某蓝牙 HID 设备无线遥控器偶发断连用户反馈“屏幕上的鼠标指针突然不动了过两秒又重新连上”。我拿到录屏后先确定了一个关键时间点断连发生在设备从桌面拿起、倾斜某个角度的时候。这个信息很重要暗示可能与天线方向或内部电池接触有关。再看 HCI 日志断连原因代码是0x08Connection Timeout说明是链路层超时——主机在预期时间内没有收到设备端的回应。正常情况下BLE 连接有一个监控超时supervision timeout默认一般是 4 秒或 20 秒设备端需要在这个周期内至少回复一次否则主机认为链接丢了。结合录屏中“设备倾斜”这个动作我怀疑是设备端天线或者射频前端在特定角度下性能骤降。进一步检查发现设备用的 PCB 天线刚好在电池仓旁边电池位置偏移时天线阻抗会发生变化导致射频灵敏度下降。这个结论单靠录屏或者单靠 HCI 日志都很难推理出来但两者一结合整个证据链就通了。3.5 经典蓝牙与 BLE 的断连差异A2DP 切 SCO 与 HID 重连再补充一点蓝牙协议层面的知识。很多人在排查蓝牙断开时不区分经典蓝牙和 BLE其实两者的断连表现和排查方向完全不同。经典蓝牙BR/EDR最常见的断连场景是手机连接蓝牙耳机时听音乐正常一来电话音频就切到 SCO 模式通话模式然后可能出现卡顿甚至断开。这种问题往往不是“断连”而是 A2DP音乐播放配置文件和 SCO语音通话配置文件之间的切换时序没处理好。排查时重点看 HCI 日志里的Switch Role命令和 SCO 连接建立过程。BLE 断连则要关注连接事件间隔connection interval和监控超时。如果主从设备的参数协商不一致或者从设备在某个时刻处理不过来就容易触发监控超时导致断连。有些设备为了省电把连接事件间隔拉得很大比如 30ms 甚至 50ms这时候如果链路质量稍有波动就可能漏掉一个连接事件进而引发超时断开。说实话很多“偶发断连”就是这么来的——不是硬件坏了而是参数配置太激进。4. “新旧批次对照”的烧录排查用硬件差异锁定问题根源4.1 烧录偶发失败现象比你想的更普遍烧录这个问题单独拎出来说是因为它有很强的迷惑性。同一份固件、同一个烧录工具、同一个工程文件有时候一把过有时候怎么都烧不进去有时候十个板子里挂一个两个。这种偶发失败让很多人抓狂因为它在逻辑上几乎是无解的——代码没变、环境没变为什么结果不一样我先说结论烧录偶发失败百分之九十以上和“时序”有关而不是和“代码”有关。具体来说可能是供电时序不对、复位时序不对、烧录器与目标芯片的握手时序不稳定、或者目标芯片本身在这个状态下没有正确进入烧录模式。大部分情况下你以为是在烧录实际上芯片压根没准备好烧录器发了一堆命令对方没回应或者回应错了于是报错。Keil 里常见的烧录失败提示有Could not connect to target、Failed to erase flash、Verification failed等等。JLink 的报错则五花八门——Cannot connect to target、Error: flash download failed、Target has no response。这些报错信息不是玄学它们其实在暗示问题出在哪一层连接失败可能是供电或接线问题擦除失败可能是芯片锁死或 flash 保护位没关校验失败可能是目标芯片的 flash 算法和芯片批次不匹配。4.2 什么是批次对照核心是把“没变的”和“变了的”分开排查烧录偶发失败时我最推荐的方法就是新旧批次对照。具体操作是找一块旧批次之前一直正常烧录的样机再找一块新批次出问题的样机在完全相同的烧录条件下做对照实验。为什么要这么做因为偶发烧录失败经常和硬件版本有关。芯片原厂可能会在某个时间点改进内部 flash 控制器、调整上电默认值、升级制造工艺但型号名称不变。外部看来是同一颗芯片内部门道已经变了。JLink 和 Keil 自带的 flash 算法如果还是旧的就可能在新批次芯片上出现擦除不稳定、写入校验失败的问题。批次对照实验的具体做法确认新旧两批板子和芯片的具体型号、批次号、丝印上的日期代码。用完全相同的烧录工具、烧录线、供电方式分别烧录新旧板子重复十次以上记录各自的成功率。如果旧板子十次全过、新板子十次挂两三次那基本可以确认是新批次芯片的兼容性问题。这时去芯片厂家的官网翻勘误表Errata Sheet和 SDK 发行说明搜一下已知的 flash 烧录相关 bug大概率能对上号。我遇到过一个是 GD32F470 的烧录问题JLink 连接能成功但擦除 flash 时偶尔报错查了半天排除了供电和接线问题后做了批次对照发现旧批次芯片没这个问题新批次芯片的 flash 组织方式有了细微调整。最后到官网下载了最新的 flash 算法文件替换到 Keil 里问题就彻底消失了。这种事在国产芯片圈子里尤其常见——因为国产芯片迭代快同一型号的芯片可能每两三个月就有一次内部改动。4.3 烧录速度、供电与信号完整性的三重检查批次对照不是万能的它只能告诉你问题是不是“批次差异”引起的。如果对照下来新旧批次都失败那就要往下看烧录条件了。供电是第一个要检查的。烧录过程中flash 擦除需要内部电荷泵升压瞬间电流可能比普通运行时大得多。如果目标板的电源带载能力不足或者 USB 口取电时线材压降太大擦除到一半电压跌落芯片就会进入不确定状态。用示波器看烧录瞬间的电源波形这是最直观的排查手段——如果擦除瞬间电压有超过 100mV 的跌落就该考虑加电容或者换电源了。烧录速度是第二个容易被忽视的因素。JLink 的下载速度是可以调的-speed参数从 100kHz 到几 MHz 都有。速度越高对信号质量的要求越严。如果你的连接线比较长、又没有做阻抗匹配把速度调高之后就会出现“时而成功时而失败”的怪问题。这种情况的排查方法很简单把烧录速度降低一个档位比如从 4MHz 降到 1MHz如果问题消失了说明你的硬件连接没法支撑太高的烧录速率。网上很多人问“JLink 烧录 SPI 速度为什么这个慢”其实也是同一个道理——速度和稳定性是跷跷板。信号完整性是第三个层面。烧录接口的线材不能太长SWD 接口推荐尽量控制在 20cm 以内接线要遵循“电源、地、时钟、数据”四线尽量短而粗。如果再严谨一点SWDIO 和 SWCLK 上可以加 33Ω 的串联电阻来抑制振铃。这些不是教科书上的标准答案而是经验。你会发现很多烧录失败在现场偶发拿回实验室就复现不了——大概率就是线和电源环境不同导致的。4.4 国产芯片烧录踩坑Keil 配置、flash 算法与工具链不匹配国产芯片这两年普及率很高但在烧录这块坑真的不少。最典型的是 Keil 的 Pack 版本和 flash 算法文件版本不匹配。你装了新版的 Pack但它默认带的 flash 算法可能是旧版你用的是旧版 Keil但芯片是新批次内置配置又对不上。这会导致一个很尴尬的现象连接 Target 能成功一执行擦除就报错或者擦除能过但校验不过。解决办法是手动更新 flash 算法文件。路径一般在 Keil 安装目录下的ARM/Flash文件夹里或者在芯片厂家提供的 SDK 里。把厂家最新的.FLM文件替换进去然后在 Keil 的 Flash Download 配置界面里选对算法。这个动作不复杂但很隐蔽谁没事会去翻那个文件夹呢。还有烧录模式的问题。ESP32 这种芯片烧录前必须让芯片进入下载模式——自动下载电路会通过拉低 GPIO0 加复位来触发引导加载程序。如果你的板子没有做自动下载电路每次烧录前就要手动按键进入下载模式。这种手动操作本身就容易引入偶发问题按键时机不对、手指碰到别的引脚、静电干扰都可能让芯片没有正常进入下载模式然后烧录器报连接超时。排查时可以在烧录失败后检查一下芯片有没有正确进入下载模式——比如用串口看引导打印正常进入下载模式时芯片会打印类似waiting for download的信息。很多看起来是“烧录失败”的问题实际是“根本没进下载模式”。4.5 从烧录失败到固件运行异常的延伸思考eeprom 与引导程序最后把烧录话题往宽了说一点。烧录失败还有一种特殊形态烧录成功但固件运行不稳定时不时表现异常。这种情况很容易被误判为代码问题实际上可能是引导程序bootloader和应用固件之间的衔接出了问题。比如 bootloader 跳转到应用的时机不对、中断向量表没有重映射到正确的 flash 地址、或者 EEPROM 里的校准数据被意外擦除了。排查方法还是老套路对比不同批次板子的 flash 内容、检查 bootloader 和应用的分区表、确认跳转时是否关闭了中断。这里最容易犯的错误是只比对应用固件是否一致忽略了 bootloader 和配置区的内容。我就见过一个项目应用固件一模一样但某个批次的板子在出厂时 bootloader 没刷成最新版导致和最新应用固件的通信协议对不上表现出来就是“这批板子偶发失灵”。你说这算烧录问题还是代码问题其实只是个版本管理问题但排查起来特别费劲。5. 偶发 bug 排查的通用方法从三个案例提炼一套可复用的执行清单5.1 排查前必做的准备工作环境记录与信息台账讲了三个案例其实背后是同一套方法。把这些经验沉淀下来我整理了一张偶发 bug 排查的通用清单每次碰到这类问题就按这个来效率会高很多。第一步是环境快照。问题发生时不要急着动任何东西先把现场记录下来设备型号、固件版本、硬件批次、供电方式、连接线材、环境温度、操作步骤、复现频率。如果是用户上报的问题一定要问清楚完整的操作链最好能要到录屏或日志。很多工程师习惯一上来就翻代码但我建议先花 20 分钟把环境信息收集好——这 20 分钟能帮你后面省下好几个小时。第二步是建立复现路径。如果问题能复现哪怕是偶发复现也要尽量缩短复现所需的时间。比如在代码里加日志、加计数器、加状态缓存把触发条件一步步收紧。实在复现不了就用长时间的自动化压测来碰运气。我自己常写一些简单的 Python 脚本控制串口或蓝牙反复执行某个操作同时记录所有异常事件通常跑一晚上就能拿到足够的统计数据。第三步是验证假设。每次只改一个变量改完跑足够多的测试轮次来确认问题是否解决。怎么确认“足够多”至少要跑到比之前出问题的次数多一个数量级以上。比如之前通常跑 20 分钟会出一次问题那修完之后至少要跑 200 分钟没再出现问题才算初步通过。5.2 日志取证的技术细节时间戳、格式与多通道对齐日志是偶发 bug 排查的核心资产但日志本身的质量决定了它的价值。我给嵌入式设备写日志时有几个习惯这几年还没翻过车时间戳必须统一。设备端用uptime毫秒计数主机端用系统时间加毫秒。两边日志放在一起对齐时用相对时间起点归零比用绝对时间各时钟可能不同步更好对齐。之前对蓝牙断连时间轴时我就吃过时钟不同步的亏——设备端记的 12:00:33.245 和手机 Logcat 里的 12:00:35.180 之间到底差了多少毫秒根本对不准。后来改成统一起点归零让两边同时记录“开始测试”事件对齐就简单了。日志格式一定要带模块标签和严重级别。比如[BLE] [WARN] connection timeout一眼就能看出是哪一层的问题。很多人写日志图省事直接一个printf(here\n)等到了定位问题的时候满屏都是“here”什么都查不出来。好的日志不是写给自己看的是写给出问题之后三周的自己看的——那时候你大概率什么都不记得了。多通道取证也值得强调。串口日志、蓝牙 HCI 日志、系统 Logcat、录屏视频、电源波形、逻辑分析仪抓取能同时上就同时上。多通道数据一起看的时候问题往往就自己跳出来了。单一通道的数据有太多解释空间两个通道的数据交叉验证就能把范围缩小很多。5.3 常见问题速查表串口、蓝牙、烧录各一张表把前面几个案例里的经验整理成速查表方便大家直接对照排查。串口偶发问题速查表现象优先排查方向手段偶发乱码波特率误差、线材屏蔽、共地测实际波特率、换线、检查地线连接输出突然停了USB 转串口模块、驱动、DMA换模块、查驱动日志、检查 DMA 标志重启后正常电压跌落、干扰示波器抓供电波形、检查去耦电容上位机卡死串口缓冲区溢出、流控打开硬件流控、加大缓冲区蓝牙偶发断开速查表现象优先排查方向手段固定时间断连连接超时参数、sniff/低功耗模式看 HCI 日志监控超时参数调整 connection interval移动时断连天线性能、驻波比检查天线匹配、缩短距离测试特定操作后断连系统事件触发、配置切换录屏定位操作动作、看系统日志多设备共存断连射频共存、干扰用频谱仪扫环境、检查信道跳频烧录偶发失败速查表现象优先排查方向手段连接失败供电、接线、复位电路测电压、缩短线长、检查复位电平擦除失败flash 算法版本、芯片批次换新 flash 算法文件、做批次对照校验失败烧录速度、信号完整性降速、检查信号质量、加串联电阻偶尔整个板子变砖供电大电流跌落、bootloader 损坏示波器抓电源、检查 bootloader 是否可恢复5.4 排除法之外的进阶技巧二分法切分变量空间最后再说一个从老工程师那里学来的技巧二分法切分变量。当排查空间很大的时候不要一个一个变量试那太慢了。你应该把变量空间切成两半看看问题在不在其中一半里。举个例子烧录偶发失败你可以先切换“使用厂家官方烧录工具 vs 第三方烧录工具”。如果官方工具也不稳定就切“短连接线 vs 长连接线”。如果短连接线还是不稳定就切“独立供电 vs USB 供电”。每切一次排查空间缩小一半。几轮下来问题的范围就很小了。这种二分法思路在蓝牙问题上同样适用。比如断连只出现在 Android 设备但 iOS 正常那就把问题范围锁定在 Android 蓝牙协议栈断连只出现在某个特定距离就锁在射频链路。比漫无目的地乱试高效得多。6. 写在最后偶发 bug 排查的本质是还原真相这几个案例做下来我最大的感受是偶发 bug 排查拼的不是智商而是细致程度。每一个看似无关紧要的记录、每一次看似多余的环境快照都可能成为还原真相的关键拼图。用换机排除法查串口用录屏加 HCI 日志查蓝牙用批次对照查烧录——形式上差别很大内核却完全一致尽可能把事实和假设分开用证据说话。我自己踩过无数次坑才养成这些习惯。刚开始做调试那几年遇到偶发问题就抓瞎代码翻来覆去改了一百遍问题照样在。后来才明白问题不在代码里而在那些你根本没注意到的物理细节里——线材质量、供电稳定性、芯片批次差异、甚至上一次烧录留下的残余状态。这些东西不写在代码注释里也不会出现在报错信息里只有靠系统性的排查方法才能把它们一个个揪出来。最后分享一个我坚持了很久的小习惯准备一个“偶发问题笔记本”不管是客户反馈的还是测试发现的只要问题属于“偶发”类型就记下一行——日期、设备、批次、现象、当时环境。这个本子平时看着没用但当你第三次遇到相似问题时翻一翻很可能会发现一个早就埋下的规律。有些问题不是不能修而是信息散落在不同的时间点里拼不起来罢了。
