做嵌入式这些年我越来越觉得WiFi和**BT蓝牙**这两类外设在调试思路上跟I2C、SPI、UART这些传统总线设备完全是两个世界。那些总线设备逻辑时序对了基本就通了顶多就是速率上不去、偶发拉低总线这种问题。但WiFi和BT涉及的协议栈深、状态机复杂、射频链路又多了一层“看不见摸不着”的电磁波出的问题千奇百怪——不是连不上就是连上以后掉线再不就是吞吐量上不去或者功耗莫名其妙地高。而这类问题恰恰是嵌入式工程师最头疼的。这篇“嵌入式分享#21”就把我这些年调WiFi和BT外设的思路、套路和踩过的坑系统地捋一遍。内容会从调试前的准备讲起到WiFi的驱动、射频、吞吐、稳定性再到BT的协议栈、配对、音频然后是两者共存的干扰治理最后整理一份排查速查表。不管你是在做智能家居、可穿戴设备还是工业网关、车载模组这套思路都可以直接拿去用。1. 先说结论WiFi和BT调试为什么难很多刚入行的朋友有个误区觉得外设调试就是“把驱动编译进去跑起来就完事”。但到了WiFi和BT这儿这个想法必须丢掉。因为它们根本不是“一个设备”而是一整套协议栈加上射频系统的合集。1.1 这两类外设在调试上的共同难点先说为什么难归纳起来就三条。第一协议栈的层次太多。你从应用层发起一个HTTP请求到WiFi驱动把数据变成802.11帧发出去中间要经过socket、TCP/IP、网络接口层、驱动层、固件层每一层都可能出问题。蓝牙也一样GATT到L2CAP再到HCI最后才到控制器。问题出在哪一层不把日志分层打出来根本定位不到。注意蓝牙调试里HCI层是个天然的分界线。HCI以上主机协议栈的问题和HCI以下控制器/射频的问题排查手段完全不同。拿到一个蓝牙问题第一件事就是问HCI层表现正常吗第二时间和射频因素耦合在一起。SPI调不通你可以用示波器一帧一帧地看波形。WiFi和BT的问题往往带有“随机性”——有时候能连上有时候连不上有时候传一会儿才掉。这背后是射频环境的复杂性。隔壁工位开个微波炉、环境里多了一个蓝牙音箱、天线位置被手挡住都会影响结果。这种“偶发性”会让很多工程师崩溃因为问题无法稳定复现就无从下手。第三软件、硬件、射频三个领域叠加。驱动代码有问题、天线阻抗不匹配、协议栈配置错了一个参数、晶振频偏超标——这四类原因的表现形式可能一模一样连接不稳定。而你一上来就盯着代码看可能几天都找不到原因。我一向的调试原则是先隔离领域再逐层排查。1.2 我平时调试前必做的一件事说个真实经历。之前调一款WiFi模组产品反馈说“路由器隔一堵墙就连不上”我第一反应是天线问题结果拿频谱仪一测传导功率明明达标。后来静下心想了一下把模组厂提供的SDK里一个叫TX power的参数翻出来看发现固件里默认配置的是某个特定国家码下的功率等级换了国家码之后功率直接被压低了好几个dBm。就这么一个不起眼的配置折腾了我三天。所以我现在不管调什么WiFi或BT的外设动手之前先问自己五个问题硬件参考设计是否严格照搬了模组厂商的天线部分有没有改动驱动和固件版本跟硬件是否匹配SDK版本是不是最新的稳定版供电是否满足峰值电流需求有没有用示波器测过瞬间压降晶振频偏是否校准过用的是什么精度的晶振测试环境是不是干净周围有没有同频干扰源这五个问题只要有一个没落实调起来就会事倍功半。尤其是供电WiFi在TX峰值的时候电流能到300mA以上如果供电纹波大或者电流供给不足表现出来的症状就是“概率性连不上”——这个坑后面还会细讲。2. 调试前的准备把环境变量先控制住调试的本质是“控制变量”。WiFi/BT这类外设变量太多所以准备工作比正式动手还重要。2.1 硬件层面天线、晶振、供电先聊硬件。模组厂商给的参考设计天线部分千万不要随便改动。之前有个项目结构工程师觉得板载天线位置碍事让硬件工程师把天线挪了个地方结果灵敏度直接掉了差不多10dBm。你可能会说10dBm听着不多但在射频这里接收灵敏度每少3dB有效距离就差不多少一半。天线部分至少确认三件事天线净空区是否足够周围有没有铺铜或者金属结构件遮挡天线阻抗是否匹配有条件就测一下回波损耗S11在目标频段内S11要低于-10dB天线馈线如果走的是IPEX线是否短而直有没有被其他信号线交叉干扰。晶振这块WiFi和BT对参考时钟的要求很高常规要求是频偏在±20ppm以内有些要求高的会到±10ppm。频偏超了最典型的症状就是“连不上”或“速率奇低”。因为频偏影响了信道中心频率的准确性接收端的解调器无法正确锁定信号。你用频谱仪测发射信号时如果发现中心频率有偏移多半就是晶振的问题。供电是最容易被忽略的。WiFi模块的瞬态电流很大尤其是在TX突发的时候如果前端供电用的是LDO且输入输出压差不够或者电源走线太细就会导致电压跌落。一旦电压跌落到芯片的最低工作电压以下芯片就会自动复位或者丢掉连接。这里我建议用示波器在模块的VDD脚上直接量重点看TX burst期间的纹波和瞬态压降压降超过100mV就要警惕了。提示有些时候“连不上”和“掉线”问题的根源并不在软件而在硬件。调试之前花半天时间把硬件这几个关键点确认掉后面能少加一个多星期的班。2.2 软件层面驱动、固件、协议栈版本的匹配问题软件层面的准备工作核心就是“版本匹配”。之前遇到过一个典型问题SDK里的驱动是新的但固件烧的还是旧版本结果驱动的某个新特性和固件不兼容WiFi扫描结果一直为空蓝牙扫描能发现设备但无法连接。找来找去最后刷成配套固件才解决。具体要核对四样东西模组型号和驱动版本是否对应。同一个厂商的不同模组尽管管脚兼容但内部射频前端、PA可能不同驱动参数也不能混用。固件版本和驱动版本是否配套。厂商的Release Notes一定要看里边会明确写某个驱动版本依赖哪个固件版本。协议栈版本和主控SoC的SDK是否匹配。很多主控的SDK自带蓝牙协议栈版本升级后API有变化老应用代码直接编译会报错或者行为不一致。配置文件是否正确。WiFi/BT的配置文件里往往包含许多射频参数、功耗参数、共存参数别用默认值直接跑要对照硬件设计确认。2.3 工具清单必备与进阶调试工具直接决定排查效率。我自己的工具包里长期放着这些工具用途优先级串口终端SecureCRT/MobaXterm看内核日志、系统日志、交互命令行必备Iperf工具WiFi吞吐量测试TCP/UDP都支持必备频谱仪或带频谱功能的综测仪测发射功率、中心频率、谐波进阶必备Wireshark USB Dongle抓取蓝牙HCI日志和WiFi抓包强烈推荐逻辑分析仪或示波器看供电、枚举时序、中断信号必备蓝牙协议分析仪如Ellisys、Frontline分析BLE空口报文有预算就上这里多说一句频谱仪。很多人觉得射频测试是硬件工程师的事软件不用管。但如果你能自己拿频谱仪看一下WiFi的发射信号长什么样很多问题一眼就能判断出来。比如发射功率正常但距离还是近可能是天线问题发射信号的中心频率偏了那多半是晶振问题如果发射频谱出现异常的杂散那你可能需要关注是不是有其他信号干扰了射频前端。我在实际调试时还有一种“准频谱仪”——模组厂商提供的RF测试固件。很多模组有一种测试模式可以强制模组在指定信道持续发射单载波信号这时候用频谱仪去测就很方便。这种测试模式不仅方便验证硬件也是产线测试的标配。遇到驱动问题之前先用测试固件确认硬件链路OK这样排查方向就不会跑偏。3. WiFi调试的核心链路WiFi的调试链路我习惯分成四段驱动加载、射频验证、吞吐量、稳定性。每一段都有自己典型的坑。3.1 驱动跑起来的标志从dmesg到ifconfig驱动加载顺利的标志应该从三个层面确认缺一不可。第一层是内核层面的驱动注册。看dmesg输出出现类似wlan0: HW version 0x...、wlan0: Firmware loaded之类的日志说明SDIO接口枚举正常、固件加载成功。如果日志里有mmc_... error或者failed to load firmware那问题多半出在SDIO通信上。第二层是网络接口层。ifconfig -a能看到wlan0这个接口说明网络设备注册成功。如果只有接口名但状态一直是DOWN可能是驱动层面没有完成初始化。第三层是扫描和连接层。用iwlist wlan0 scan能看到周围的AP列表wpa_supplicant能正常关联到路由器拿到IP地址这才算驱动真正可用了。注意这中间每一层失败排查路径完全不同。SDIO枚举失败查硬件连接和供电固件加载失败查固件文件和驱动版本扫描不到AP查天线、射频和信道配置能扫描但连不上查认证方式、密钥和路由器的兼容性配置。调试驱动阶段我最常用的招儿是打开驱动的动态调试。很多厂商SDK里的驱动都带了DEBUG或者CONFIG_CFG80211_DEBUGFS这类配置把它们打开后驱动会把ASSOC、AUTH等关键事件都打出来。这在排查连接问题的时候非常有用能让你看到驱动在哪个状态机跳转阶段卡住了。3.2 RF射频参数验证频谱仪看什么射频这块我自己验证的参数主要有四个发射功率、中心频率、频谱模板Spectral Mask、接收灵敏度。发射功率是最直接的。用RF测试模式让模组在某个固定信道持续发包频谱仪上读到的功率要跟规格书上标称值接近一般差异在±1.5dBm以内可接受。如果功率偏低先查配置文件里是不是有限制再看是不是供电不足导致PA无法满功率输出。中心频率偏了是晶振问题前面已经说过。频谱模板不过在认证测试中也很重要但在日常调试里如果你发现频谱仪上看到的信号带宽或者形状不对比如带宽过宽或出现异常凸起要考虑是不是配置了错误的调制方式或者信号本身被其他信号叠加了。接收灵敏度不好直接测但有个间接办法用可调衰减器连接模组和测试仪器加大衰减值观察吞吐量从稳定到开始下降的点就能大致推断灵敏度。两个同样天线设计的产品到达同样吞吐量下降点时需要的衰减值越高灵敏度越好。3.3 吞吐量测试的坑别上来就怪驱动吞吐量上不去是WiFi调试里反馈最多的一个问题。但这里我想说至少一半的吞吐量问题根源不在WiFi驱动而在测试方法或整体链路。举个例子排查一个TCP吞吐量只有理论值一半的问题最后发现是因为iperf默认用了单线程而吞吐量瓶颈在CPU上——主控处理不过来网络包导致TCP窗口一直打不满。换用iperf -P 5多线程之后吞吐量就正常了。在正式定位之前一定要先把这几个变量控制住信号强度要尽量好确认不是天线覆盖问题路由器要支持你测的协议比如802.11ac或ax信道宽度要匹配20/40/80MHz确认没有同时跑蓝牙测试避免共存干扰吃掉吞吐用TCP和UDP各测一遍。UDP能跑满但TCP跑不满问题多半在CPU/内存瓶颈或者TCP窗口/丢包重传TCP能跑满但UDP有问题那才要怀疑驱动或射频距离要固定。最好在屏蔽箱里边测排除环境波动——我之前吃过大亏同一个模组工位上测300Mbps去隔一个工位就掉到100Mbps原因就是旁边一个无线鼠标接收器的干扰。实操心得我习惯在测试报告里固定三组数据近距离1米内TCP、UDP吞吐量远距离隔一道墙TCP吞吐量以及重传率。这三组数据配合起来比单一数字更能说明无线链路的质量。3.4 连接稳定性问题排查从扫描到掉线的完整路径连接稳定性问题大概是WiFi调试里最让人抓狂的。症状往往是“用着用着就断了过几秒又自己重连上了”或者“偶尔连不上但多试几次能连上”。排查思路我建议按照下面的顺序来第一步看信号覆盖。拿着模组在测试环境里走动记录RSSI变化。如果在临界位置信号很差比如RSSI低于-85dBm掉线是正常的物理规律不是bug。第二步看关联日志。排查掉线问题时wpa_supplicant的日志会明确告诉你掉线的原因比如CTRL-EVENT-DISCONNECTED reason3DEAUTH_LEAVING通常是远端踢掉了还是reason4DEAUTH_INACTIVE通常是AP端超时了。reason不同排查方向完全不同。被AP踢要去看AP端的日志和配置比如是不是开启了“弱信号踢下线”功能收不到Beacon导致超时要检查射频链路和天线。第三步检查是否进入了省电模式PS Mode。有些模组默认开着省电模式路由器端的Beacon配置又过于激进模组休眠后无法及时醒来接收数据就会出现“看起来连上了但客户端一直收不到数据”的情况。调试时先把省电模式关掉iwconfig wlan0 power off看问题是否消失。如果关掉省电就好了再回头优化省电参数。第四步确认路由器兼容性。有些老旧路由器对802.11n的某些特性支持不好会出现“连接速率协商到很高但实际数据传不出去”的情况。这种情况下可以把速率集固定到802.11g或者关掉短GIGuard Interval重测。如果固定之后稳定了说明是兼容性问题需要在驱动配置里做兼容性适配。第五步查供电和地弹。前面提过WiFi传输电流波动大时如果电源的瞬态响应不好模组的射频前端会工作异常。我在调试中遇到过一个非常隐蔽的问题模组一发射大包就重启拿示波器一看供电电压在发射瞬间跌了400mV——这已经不是“掉线”了是直接“掉电”。最后把供电电容加大、走线加宽才解决。4. BT调试的核心链路蓝牙的调试思路跟WiFi有相通之处但又有自己的特点。BLE和经典蓝牙的调试侧重点很不一样我分开讲。4.1 从HCI到应用层日志怎么分蓝牙协议栈我习惯分成三段看待控制器Controller、主机Host、应用Application。Controller负责射频收发、跳频、链路层状态机。通常由模组内部的MCU射频前端实现。Host负责逻辑链路控制、属性协议、安全管理等。通常在主控SoC的协议栈里实现比如Linux的BlueZ、Android的Bluedroid或者各芯片厂商的私有协议栈。Application你的业务代码通过GATT读写、配对请求、音频通路等跟蓝牙交互。调试这段链路时我的习惯是“抓两头、看中间”。抓两头是抓应用层的表现和HCI层的日志看中间是针对Host和Controller的行为差异做对比。HCI日志怎么抓Linux下可以直接用btmon或hcidump把主机和控制器之间交互的HCI命令和事件全部打出来。打开HCI日志看一次完整的连接过程你能清楚地看到扫描请求、连接请求、连接完成事件、Feature协商、加密协商等。几乎所有连接问题在HCI日志里都有蛛丝马迹。注意HCI层的状态机非常严谨该先发送什么命令、该在哪个事件之后发协议栈都定死了。如果日志显示某个命令的回复是Status: 0x03如Unsupported Feature / Invalid LMP参数那多半是主从双方不兼容或者控制器的固件版本太老不认识主机的某个命令。4.2 BLE调试的常见卡点BLE低功耗蓝牙在物联网设备里用得最多调试的卡点也最典型。扫描不到设备。先确认广播是否在跑。如果有可能用一台手机装个BLE调试工具如nRF Connect扫一下设备能不能看到。手机能看到但你的主控看不到多半是主控侧的扫描参数如扫描窗口、扫描间隔配置不合理。扫描间隔设得太长漏掉广播包的概率就大。如果主控和手机都看不到那就要检查广播参数是否合法广播间隔不能太短信道是否被禁用以及天线和射频是否正常。能扫描到但连不上。这里最常见的原因是连接参数Connection Interval不匹配。主设备发起连接时会带上期望的连接间隔从设备如果觉得不合适可以拒绝或协商。如果从设备不管因为什么原因拒绝了连接参数连接就建立不起来。用HCI日志看你会发现连接请求已经发出去了但从设备返回了Connection Rejected。连上以后老掉线。多半有三种原因连接超时参数Supervision Timeout太短。如果从设备的连接事件间隔很长比如到了几百毫秒而连接超时时间又很短主从之间的连接很容易因为一个连接事件没赶上就断掉。从设备的系统进入了睡眠而无线没准备好唤醒。这是嵌入式设备上的经典坑。应用代码以为蓝牙还在正常工作但系统已经休眠蓝牙的链路层没能及时唤醒收发导致看门狗超时断开。射频干扰。BLE用的是2.4GHz ISM频段和WiFi、鼠标、微波炉全都挤在一起。如果设备周边干扰源多连接稳定性也会变差。这种问题通常需要换一个干净的环境验证排除了干扰再回头查协议栈。广播丢包导致扫描不到。有一个很隐蔽的坑BLE广播用的三个信道37/38/39如果被某些WiFi信道占用广播包可能会持续丢失。这时候可以用工具扫一下2.4GHz全频段的占用情况看看是不是恰好有强信号源占据了BLE的广播信道。如果有只能通过调整广播间隔在一个广播周期内多发几个广播包来增加冗余。4.3 经典蓝牙音频通路调试经典蓝牙在嵌入式里主要用在音频场景——蓝牙音箱、蓝牙耳机、车载免提。这类调试最大的特点就是“音质问题不好量化”主观性强所以证据链格外重要。音频通路的核心有三个profileA2DP高质量音乐播放、HFP免提通话、AVRCP媒体控制。调试A2DP问题第一步是确认数据通路。音频数据从主控通过I2S/PCM等接口送给蓝牙芯片蓝牙芯片编码后发给对端。如果声音断断续续先分清是播放端的问题还是传输端的问题——用手机直接连设备播放如果还有问题那是设备端到蓝牙芯片之间的问题如果手机播放正常只有你主控推送时有问题那就是你的主控侧音频通路存在问题。HFP的问题又不一样它涉及双向语音而且对延时敏感回声抵消和降噪通常需要在音频DSP里做。如果对端听到的声音有回声或者断续大概率不是蓝牙链路的问题而是音频处理链路的延迟和回声路径没有调好。实操经验音频类调试我坚持一个原则任何主观结论都要有客观数据支撑。建议用蓝牙协议分析仪抓空口报文确认A2DP的A2DP包是否按时到达、有没有重传同时在主控侧用音频分析仪测I2S的BCLK、LRCLK是否稳定有没有瞬间的时钟跳变。两头的数据对上就能精确定位问题和判断修复效果。4.4 配对绑定流程解析配对绑定是蓝牙里又一个容易出幺蛾子的环节尤其在要做产品的时候。BLE安全模型里配对过程涉及密钥生成、交换和存储。设备重启之后如果还要重新配对多半是绑定信息没有持久化存储。看协议栈API通常有类似bond device后把密钥写入NVM非易失存储的步骤。如果你的代码里只做了配对没做存储重启就“失忆”了。还有一个更隐蔽的问题——安全等级不匹配。比如你的设备要求LE Secure ConnectionsLESC但手机端只支持LE Legacy配对两边安全参数无法协商一致配对就会失败。这种情况HCI日志里会看到PIN or Key Missing或者Pairing Not Supported之类的错误码。经典蓝牙的配对涉及PIN码输入。有些嵌入式设备没有屏幕和键盘需要固定PIN码或者利用SSP安全简单配对的数字比较流程。如果一个设备不支持SSP而你又没有输入PIN的界面很多手机压根就不跟你配对。这也是为什么现在做产品基本都要求蓝牙芯片或协议栈支持SSP否则兼容性会很难看。5. 双模共存WiFi跟BT打架怎么判你手里的设备WiFi和BT往往是同一颗芯片Combo芯片或者分属两颗芯片但天线挨得很近。这就不可避免地要面对共存问题。5.1 共存问题的典型现象如果你遇到下面这些现象不要怀疑大概率是共存问题WiFi连着路由器蓝牙耳机声音断断续续蓝牙传文件时WiFi吞吐量直线下降蓝牙低功耗设备如手环连上后WiFi的ping延迟暴涨两个功能单独测都正常一起跑就不正常。这些都是2.4GHz频段内部的自干扰。WiFi和蓝牙都在这个频段里工作WiFi信道带宽大20MHz起步蓝牙是跳频79个1MHz信道或者40个2MHz信道两者难免在同一时刻跑到同一频率上。5.2 PTA仲裁机制解决共存问题的核心机制是PTAPacket Traffic Arbitration包流量仲裁。PTA是一个硬件级别的仲裁器同时连接WiFi和BT模块根据两者的优先级决定当前谁可以使用天线/射频通道。PTA通常需要结合具体的优先级策略配置。比如蓝牙 SCO/eSCO 链路语音对实时性要求极高一旦需要发射就没有商量的余地因此通常拥有最高优先级而WiFi的数据吞吐优先级则要低一些可以被蓝牙抢占。反之如果WiFi在传输关键的业务数据而蓝牙只是在传文件那WiFi的优先级就要提高。调试共存问题第一步是确认PTA有没有使能。如果你用的是Combo芯片一般驱动初始化时会有一个coex相关的使能开关打开之后还会生成一些coex log。第二步是查看PTA相关的GPIO有没有正确连接。如果WiFi和BT是分开的两颗芯片那么PTA信号WLAN_ACTIVE、BT_ACTIVE、BT_PRIORITY这类引脚必须接好否则仲裁就是空中楼阁。注意看共存问题是否解决的唯一标准是“同时跑两个业务两者的关键指标都达到可接受的范围”。比如蓝牙播放音乐不断续、WiFi ping延迟小于20ms。有些方案是通过“时间切片”给两边分时复用天线的这种方案在业务并发高的场景下可能两边都受限你要根据自己产品的业务模型取舍。5.3 天线设计的关联共存问题还有一个硬件层面的因素——天线隔离度。如果WiFi天线和蓝牙天线都做在同一个PCB上相互之间的距离如果太近隔离度不够WiFi发射时的强信号会把蓝牙接收机“堵死”导致蓝牙收不到任何信号。反过来也一样。天线隔离度不够的典型症状是两者距离很近比如都在板子顶部在某些角度下蓝牙会长时间收不到包但天线位置换一下就好了。这种问题软件层面只能缓解治本要靠调整天线布局、增加隔离或者干脆用单一Chip Antenna加上PTA做TDM时分复用。我自己调试这种问题时的经验是升到软件的共存配置之前先确认硬件隔离度。用网络分析仪测两个天线之间的S21如果在2.4GHz频段S21高于-20dB共存问题会非常难办软件再努力也白搭。6. 高频问题排查速查表根据我个人的经验把WiFi和BT调试中最高频的问题做成一个“症状-思路-解决方向”的速查表方便以后遇到类似问题直接对照。6.1 问题现象与排查方向对照表现象优先排查方向可能的根因扫描不到WiFi AP天线/射频、驱动扫描配置天线虚焊、配置文件disable了扫描、环境里真的没有信号能扫描到但连不上AP认证配置、路由器兼容性密码类型不匹配、路由器开启了MAC过滤或弱信号踢下线连接后频繁掉线省电模式、供电、信号覆盖PS Mode配置激进、供电不足、RSSI在临界值WiFi吞吐量远低于标称测试方法、CPU瓶颈、信道宽度iperf单线程、主控处理不过来、路由器配置了20MHz带宽距离稍远就没速度天线匹配、发射功率S11差、功率配置低或供电不足蓝牙扫描不到设备广播参数、天线、环境广播间隔太长、广播信道被干扰、天线灵敏度差蓝牙能扫到但连不上连接参数、安全参数Connection Interval不协商、配对方式不匹配蓝牙连上后频繁断连接参数、系统睡眠、干扰Supervision Timeout太短、系统休眠没有唤醒蓝牙、2.4G干扰蓝牙音频断断续续共存、音频通路、编码器PTA未使能、I2S时钟不稳、A2DP传输重传多WiFi和蓝牙同时跑就掉速共存、天线隔离PTA优先级配置不合理、天线隔离度不够设备重启后蓝牙需要重新配对绑定存储配对密钥没有持久化到NVM这个表只是一个起点真正的排查还是得靠“分层定位”那一套确认物理层/链路层是否正常再看协议栈和上层应用。6.2 三个我踩过的大坑第一坑SDIO接口的时序问题伪装成“固件加载失败”。有次调试一款WiFi模组dmesg里一直报failed to load firmware怎么刷固件都没用。最后查出来是SDIO接口的时钟线走线过长信号质量差导致固件传输过程中CRC校验失败。改短走线或者降SDIO时钟频率就好了。排查这个问题的思路是先降SDIO时钟频率重测如果能过去那就是信号完整性的问题。第二坑PMU电源管理单元把WiFi的供电偷偷切了。有个项目测试低功耗时发现系统进入睡眠后WiFi偶发丢失。查了很久发现是PMU在深度睡眠模式下把WiFi电源域给关掉了。这其实是在做系统级低功耗设计时的配置问题但当时我一直在WiFi驱动里找原因浪费了不少时间。后面养成了习惯遇到WiFi掉线问题先确认电源域有没有被其他模块误操作。第三坑BLE广播在靠近金属结构件时性能断崖式下跌。这是一个硬件设计问题但也影响了很多软件侧排查。产品的外壳用了金属中框正好把BLE天线部分包住导致整机灵敏度差了非常多。这类问题在实验室测试时不容易暴露等到了实际使用场景被用户握在手里问题就放大了。所以天线位置的设计评审一定要参与别等到样品出来了再纠结。6.3 排查方法论沉淀从这些年的调试经历里我沉淀了一套排查WiFi/BT问题的整体方法分享给大家。第一永远从“最近一次改动”开始找。如果你的设备昨天还是好的今天就不行了先列一下这两天代码、配置、硬件、环境有哪些变化。90%的概率问题就在这次改动里。不要把问题想复杂了。第二用排除法隔离变量。把问题相关的变量一个个拿出来固定其他变量逐个验证。比如前面提到的“关闭省电模式”、“固定速率集”、“换测试仪器”等等每做一次改动记录一次结果。我习惯把这个过程做成表格每一步记录“改了啥-结果如何-结论是什么”避免做无用功。第三日志永远要分级打。模块级日志、协议栈级日志、驱动级日志、应用级日志分别用不同TAG打出来。出问题时先把各级日志同时抓下来再说。很多问题事后分析比当时定位更省力。所以我调试的设备正式版本的日志开关也会保留只是默认关掉——这样量产设备出了问题还能远程打开日志抓现场。第四把开发环境的“脏”因素排除掉。我见过太多工程师拿着设备在工位上测试身边堆满了各种无线设备、金属杂物甚至还有人在旁边用微波炉热饭——这种环境测出来的数据波动范围极大根本没法判断问题是否解决。有条件就上屏蔽箱没条件就找一张空旷的桌子周围一两米之内不要放其他无线设备地板也要没有金属隔层。射频测试的环境一致性甚至比测试仪器本身更重要。说到这再分享一个我在实际调试中一直在用的技巧每次只改一个变量除非你确认这次改动不影响判断否则不要同时改两个参数。这个道理很简单但人一着急就容易忘。我有一次为了“提高连接稳定性”同时改了省电模式、重连间隔、扫描参数三个配置结果问题解决了但根本不知道是哪个配置起了作用。后面要优化别的特性时三个配置互相牵扯搞得自己也很被动。老老实实一次只动一个效率反而更高。WiFi和BT的调试说到底没有太多玄学。先把环境变量控制住再沿着协议栈的层次一层层往下剖大多数问题都能在几个小时之内定位到“软件配置、硬件设计、射频链路、环境干扰”这四个方向之一。希望这篇分享能帮你少走点弯路。真到了现场别慌按层次的节奏来。