遇到过“板子插上去灯也亮了手机就是扫不到广播包”这种情况的朋友应该能秒懂标题里的这个痛点。NUCLEO-WB55.USBDongle这块ST官方的USB小适配器本质就是一块以STM32WB55为核心的BLE接收/调试工具但很多人拿到手后照着网上的教程烧了个例程却发现它像个“哑巴”一样完全不发广播。尤其是习惯了NUCLEO开发板“开箱即用”的朋友第一次折腾Dongle往往会被整得怀疑人生。这篇文章不绕弯子我会把我自己调试STM32WB55 USBDongle广播问题时的完整排查思路、实验记录和踩坑心得整理出来从硬件检查、固件配置、协议栈运行状态到射频信号实测一条线走下来保证你看完能照着步骤自己定位问题。这篇文章适合正在用STM32WB系列做BLE开发、或者手里正好有这块Dongle但广播不出来的工程师朋友尤其是刚接触WB双核架构、对BLE协议栈不熟的开发者可以重点看GAP配置和低功耗那两节。1. 别急着改代码先把Dongle和NUCLEO的差别搞清楚做STM32WB开发很多人手上的第一块板子是NUCLEO-WB55RG带ST-Link、带排针、带usb虚拟串口用起来非常顺手。但USBDongle这块板子看着像是NUCLEO的“精简版”实际上它的硬件形态和使用逻辑跟NUCLEO差别很大很多广播问题恰恰是栽在这上面。1.1 同为WB55核心板级设计完全不同NUCLEO-WB55RG和USBDongle虽然都用的STM32WB55系列芯片但两者的定位是不一样的。NUCLEO是“开发板”它的使命是让你方便地接线、调试、看日志而USBDongle是“成品形态的适配器”它的使命是插在电脑上当一个低功耗蓝牙接收器或者配合ST的演示工具做无线通信测试。这就带来几个直接影响广播排查的硬件差异供电方式不同NUCLEO可以通过ST-Link的USB口供电也可以从排针外部供电供电很干净USBDongle只能通过它自己的USB口取电。USB口的供电质量跟电脑主板、USB Hub有很大关系有些劣质Hub的5V纹波很大会导致射频前端工作异常。天线设计不同NUCLEO上有UFL接头可以外接天线也可以用板载PCB天线USBDongle是板载的蛇形PCB天线没有外接选项。天线附近的净空区、外壳的遮挡都会影响辐射功率。调试接口方式不同NUCLEO自带ST-Link插上USB就能连上调试器USBDongle板上也有SWD触点但需要外接ST-Link或者ST-Link/V2的转接线才能调试和烧录这点特别容易被忽略。LED和按键的GPIO定义不同两者的用户按键、LED接的引脚完全不一样如果你直接把NUCLEO的例程烧进Dongle那LED可能亮在别的引脚上按键触发也可能失效你会误以为程序没跑起来。1.2 Dongle的“哑巴”问题往往从硬件供电就开始了我在排查Dongle不广播时第一步不是打开IDE而是先插上USB用手摸一下板子上的芯片和天线区域看看有没有异常发热。如果芯片烫手多半是3.3V稳压或某个外设短路了这类硬件损伤会导致射频前端起振失败广播自然发不出去。更常见的情况是USB口的D / D-接触不良或者USB线本身质量不行。Dongle是即插即用的USB设备如果它内部固件没有实现USB CDC/HID枚举Windows上可能只是提示“无法识别的USB设备”但很多人想当然地以为“能枚举能正常工作”实际上USB枚举和BLE射频是两条完全独立的链路USB正常只能说明电源和USB PHY是通的不等于射频通路没问题。所以排查的第一条铁律就是先把供电、接触、天线这些物理层面的东西排除干净再进软件调试。很多“不广播”的案子最后查出来其实是一根USB延长线压降太大或者天线引脚虚焊。2. BLE广播的基本机制它不广播可能不是程序问题在排查具体代码之前需要先对齐一个概念BLE设备“广播”这件事到底包含了哪些环节每个环节故障会出现什么现象。很多人在调试时眉毛胡子一把抓就是因为对这个流程没有一个整体认知。2.1 广播包是怎么发出去的一个BLE外设Peripheral要对外广播需要满足这些条件射频收发器Radio已经被协议栈初始化在STM32WB上这意味着M0内核负责跑RF协议栈已经启动并且M4内核用户应用和M0之间的核间通信IPCC已经建立。GAP层被配置为可发现/可连接模式也就是说调用了类似aci_gap_set_discoverable()或者aci_gap_set_non_connectable()这样的API把广播数据、广播间隔这些参数写到了协议栈里。广播使能没有被关闭在ST的BLE协议栈里广播使能有很多种开关包括可连接广播、不可连接广播、定向广播等这些开关是独立控制的。射频前端正常天线的频偏不能太大。STM32WB55内部有32MHz晶振的校准机制如果你的外部32MHz晶振精度不够或者匹配电容不对发射出去的信号会偏到BLE信道以外接收端自然“看”不到。只要以上任意一环有问题现象可能都是“手机扫描不到广播包”。但是仅仅“扫描不到”这一个现象可能是“没广播”也可能是“广播了但接收端收不到”。这两种故障的排查路径完全不同。2.2 广播了但收不到和压根没广播是两码事我举一个典型的例子你把Dongle插上电脑用ST的CubeMonitor-RF工具或者手机上的nRF Connect去扫描如果能看到设备列表里出现一个叫“SimpleBLEPeripheral”之类的广播包但连接不上那说明广播链路是通的问题出在连接参数或者协议栈连接状态上如果设备列表里空空如也那才叫“不广播”。别小看这个区分。我自己犯过很傻的错误因为天线的匹配电容焊错了一颗Dongle在1米内用手机能扫到广播但隔开3米就完全消失了。我当时以为是广播配置的问题改了一整天的GAP参数结果问题根本不在软件上。后来拿频谱仪一看发射功率比正常的板子低了差不多10个dBm这才意识到是天线匹配的问题。所以接下来的排查步骤我会分层次进行先确认硬件和射频通路再确认协议栈和GAP配置最后用专业工具做定性和定量分析。跟着这个顺序走你能少走很多弯路。3. 第一步排查Dongle的硬件层面是不是真的“活”了软件工程师的习惯是拿到问题先看代码这是最常见的坑。对于Dongle这种紧凑型的板子硬件层面的问题导致的“不广播”比例非常高尤其是在经历过多次插拔、焊接、甚至摔落之后。所以我强烈建议先做这一套硬件检查总共不超过10分钟但能排除掉一大半的故障源。3.1 USB枚举确认电源和基础时钟没问题把Dongle插到电脑的USB口观察系统设备管理器Windows或者lsusbLinux。如果固件带USB描述符系统会枚举出一个复合设备如果固件里压根没初始化USB那系统只会提示“未知USB设备”或“设备描述符请求失败”这时候反而说明USB物理层是通的因为D上拉电阻起了作用芯片在上电后至少跑了一部分代码。但要注意USB枚举成功和芯片的射频子系统启动没有直接关系。很多Dongle出厂预烧的固件比如ST的“自举程序”bootloader本身就能完成USB枚举让你能进入DFU模式但如果你没有跳转到用户App或者用户App压根没写射频相关的初始化那它当然不会广播。所以USB枚举这块我的建议是在Windows设备管理器里确认枚举出的VID/PID是不是0x0483 / 0x5740ST的标准USB转串口或者你工程里自定义的VID/PID。用ST官方工具STM32CubeProgrammer通过USB连接Dongle看能不能读到芯片的UID和Flash内容。如果能连上说明芯片在运行并且至少USB底层是好的。如果CubeProgrammer连不上优先检查USB线和USB口换一根线再试一次。3.2 指示灯和GPIO状态的初步确认Dongle板上通常有一颗LED具体引脚查原理图不同版本可能有差异。如果你烧录的是ST官方的BLE示例工程LED一般会在广播或者连接后变化状态。但这里有个容易踩的坑NUCLEO的例程和Dongle的例程LED引脚定义不一样。我记得NUCLEO-WB55RG上的用户LED接在PB13不同版本可能不一样以官网原理图为准而USBDongle上的LED可能接在其他引脚。如果你把NUCLEO的编译产物直接烧到Dongle里LED可能在别的引脚上“默默发光”你看不到就会误以为板子没跑起来。正确做法是去ST官网下载Dongle的原理图文件名叫mb1355或者类似命名。打开原理图找到LED网络标签对应的MCU引脚。在你的工程里用这个GPIO做翻转测试比如每500ms翻转一次LED。烧进去看灯光是否闪烁。如果LED能正常闪烁说明MCU内核在跑、时钟在跑、GPIO控制正常那“不广播”的原因基本可以锁定在射频/协议栈环节如果LED压根不亮问题可能出在芯片没启动、电源异常、或者Flash里根本没有有效程序。3.3 天线和焊接问题Dongle特有的“隐形杀手”USBDongle使用板载陶瓷天线或PCB天线这类天线对焊接工艺和机械应力比较敏感。如果Dongle曾经受过磕碰天线馈点附近的焊盘可能已经松脱形成“似断非断”的状态。这种故障在视觉上很难看出来而且万用表测量可能也测不出来因为松脱发生在微米级别的接触面上。遇到这类问题有几个实用办法用频谱仪或者带近场探头的设备贴近天线区域扫描2.4GHz频段看有没有能量辐射。有频谱仪最好没有的话可以用一个RTL-SDR加2.4GHz下变频器凑合或者借用实验室的频谱仪。如果完全没有测试仪器就只能用手机在不同距离下反复扫描。如果一个Dongle在20cm以内偶尔能扫到、远了就丢很可能就是天线问题。补焊天线馈点用热风枪340度左右少量助焊剂把天线馈点重新焊一遍注意不要吹跑旁边的电容电阻。此外晶振32MHz也是射频发射的关键。STM32WB55内部RF子系统依赖外部32MHz晶振作为参考时钟如果晶振虚焊、损坏、或者匹配电容不对RF就不能正常工作。排查方法是看系统启动后LSI/HSE时钟是否起振或者在代码里读RF相关的错误状态寄存器。但最直接的办法是对比一块正常的Dongle用示波器测晶振两个脚的波形正常的应该是干净的正弦波幅度在几百mV到1V上下。4. 第二步排查固件到底有没有在“干活”硬件检查没有发现明显问题后就可以正式进入固件层面的排查看了。但这里的“固件”不只是你写的用户代码还包括STM32WB55上那套跑在M0内核里的BLE协议栈。这套双核架构跟普通单核MCU完全不同很多人第一次接触时容易栽跟头。4.1 用CubeProgrammer读取芯片状态STM32WB55内部有一个“用户选项字节Fuse/OB”控制着芯片的启动模式、读保护级别、以及无线协议栈占用的Flash地址范围。我们在排查不广播之前必须确认这些配置没有被改乱。操作步骤用ST-Link连接Dongle的SWD触点。打开STM32CubeProgrammer选择ST-Link连接。在左侧“Option Bytes”页面检查RDP级别是否为Level 0无读保护。如果Level 1读保护会禁止调试器读取Flash内容也就没法确认固件是否完好如果Level 2那基本无法通过SWD恢复只能扔掉或者用ST的特殊恢复流程。读取Flash的前几个扇区确认里面烧录的二进制是不是你预期的工程。尤其要注意STM32WB的Flash里除了用户代码还有一段“无线协议栈固件”FUS和BLE Stack这段固件位于高地址区域由ST提供不是你自己编译出来的。如果这段协议栈被误擦除或者损坏M0内核的RF功能就无法启动。4.2 双核调试M4和M0都要“跑起来”STM32WB55有两个内核Cortex-M4用户应用。你写的main()、while(1)、GAP配置都在这里。Cortex-M0无线协议栈。BLE协议栈的物理层和链路层由ST预编译的固件放在这里运行。两个内核之间通过IPCC硬件模块通信。用户代码调用hci_init()、aci_gap_init()之类接口时实际上是往M0发命令M0再去操作Radio。如果M0不工作你M4这边调什么API都白搭。那怎么判断M0到底跑没跑有几个办法读IPCC状态寄存器如果M4发送命令给M0对方却没有响应多半是协议栈没起来。在调试器里可以看hci接口函数的返回值是不是返回超时或者错误码。检查SYS_CMD/ 协议栈状态ST的BLE例子代码里通常会有一个MX_APPE_Init()流程里面会初始化BLE协议栈。如果初始化失败代码一般会卡在HAL_BLE_Init()或者aci_gap_init()附近你可以在这些函数调用处打断点看第一次失败发生在哪个调用。看M0的内存如果你通过STM32CubeProgrammer看到了Flash高地址区的BLE Stack固件还在但M0就是不动可以尝试重新烧录ST官方打包好的“整体镜像”也就是包含用户App协议栈的单个hex文件用最原始的方法把两块内容都恢复到正常状态。提示如果之前用STM32CubeProgrammer默认配置擦除过整个Flash很可能把高地址的BLE Stack擦掉了。这时候烧录任何用户App都不会广播因为M0根本没有协议栈可跑。这种情况重新烧录ST官方提供带协议栈的工程镜像即可解决。4.3 最容易犯的错把NUCLEO工程直接编译后烧进Dongle这里我要单独开一节说因为实在太常见了。NUCLEO-WB55RG和USBDongle虽然主控芯片都是WB55但它们的ST-Link电路、晶振配置、以及引脚分配都不完全相同。大多数NUCLEO例程在生成时默认选择了“NUCLEO-WB55RG”开发板它的串口、按键、LED引脚都是按NUCLEO来的。你把这样的工程烧进Dongle轻则LED不闪、按键不灵重则因为某些外设初始化失败导致系统跑飞或者卡死。更隐蔽的是如果NUCLEO工程初始化了某个没有连接到Dongle内部的外设比如外部Flash、SPI屏幕而Dongle上这个引脚悬空或者被用于其他功能初始化时可能读回随机电平导致外设状态机卡死。解决办法很简单但需要多一步操作在STM32CubeMX里新建工程时直接选“NUCLEO-WB55RG / USBDongle”对应的板卡模板让CubeMX自动匹配正确的引脚和时钟树。如果你手上已有的工程是从NUCLEO拷过来的请打开ioc文件重新选择板卡类型让CubeMX重新生成引脚配置。对比两个板子的原理图把差异部分的GPIO配置改成一致。我自己第一次调试这块Dongle时就是把NUCLEO的官方例程改了改直接烧进去结果板子毫无反应LED也不亮。查了半天才发现是引脚映射问题。所以**“先确定板卡类型再改代码”**这步跳过了后面全是麻烦。5. 第三步排查GAP层配置与广播参数到底对不对如果硬件和固件基础都正常那就需要回到应用层审视一下你的广播配置代码。这里我见过太多“看起来对实际没有广播”的写法。5.1 广播使能不是配置了参数就算数很多ST的BLE示例代码分为两步第一步是初始化GAP设置设备名称和IO能力第二步是调用“set discoverable”之类的函数启动广播。问题往往出在第二步。注意ST协议栈的广播启动API不是一个通用的“start broadcasting”函数而是区分了连接模式aci_gap_set_discoverable()用于可连接的可发现广播连接方可以来连接。aci_gap_set_non_connectable()用于不可连接的广播只发数据不允许连接。aci_gap_set_directed_connectable()定向广播指定对端地址。如果你调用的API和预期不符或者广播参数不合法比如广播间隔设成了一个超出范围的值协议栈会返回错误但M4端未必会实时打印日志。所以最直接的办法是检查每一次API调用的返回值只要不是BLE_STATUS_SUCCESS立刻停下来查。这里给一个参考的常用初始化序列基于ST的BLE Stack API风格实际以你的SDK版本为准// 1. 初始化BLE协议栈 MX_APPE_Init(); // 2. GAP初始化 aci_gap_init( /* Role */ 0x01, // GAP_PERIPHERAL_ROLE /* privacy */ 0x00, /* name */ MyDevice, /* name_len */ sizeof(MyDevice), /* appearance */ 0x0040 ); // 3. 广播数据配置可选把服务UUID放进去 aci_gap_set_advertising_data( adv_data_size, adv_data ); // 4. 扫描响应数据配置 aci_gap_set_scan_response_data( scan_resp_size, scan_resp_data ); // 5. 真正开始广播 ret aci_gap_set_discoverable( /* adv_type */ 0x00, // ADV_IND /* adv_interval */160, // 100ms单位625us /* channel_map */ 0x07, // 37/38/39三个信道都发 /* filter */ 0x00, // 不过滤扫描请求 /* local_name */ MyDevice, /* name_len */ sizeof(MyDevice) ); if (ret ! BLE_STATUS_SUCCESS) { // 一定要在这里停下来看看返回什么错误 Error_Handler(); }这个序列里比较容易错的是第5步的参数adv_interval的单位是0.625ms160就是100ms广播间隔有些人习惯写2012.5ms更激进但功耗会高很多。另外如果adv_type用了ADV_NONCONN_IND不可连接广播手机虽然能扫到但没法连接如果你打算后续做连接这里就要用ADV_IND。5.2 低功耗模式把RF给“睡了”STM32WB55是一个典型的低功耗MCU工程里可能使能了STOP或STANDBY低功耗模式。如果你在广播还没启动时进入了某种深度休眠RF子系统的时钟可能被关掉或者M0内核休眠后无法及时响应M4发出的HCI命令结果就是广播压根没起来。最常见的情况是你在main()里配置了GPIO、初始化了BLE然后进入一个等待队列但等待的条件一直不满足系统误判为“无事可做”调用了HAL_PWR_EnterSTOPMode()。从调试器的视角看M4其实还活着但没有在执行任何有用的逻辑手机根本扫不到广播。排查低功耗问题有几个技巧在调用低功耗进入函数之前手动禁用它。比如把HAL_PWR_EnterSTOPMode这一行注释掉看广播是否恢复正常。如果恢复正常说明问题就在功耗管理代码的时序上。用调试器看一眼PWR-CR1或者DBGMCU-CR寄存器确认芯片当前处于哪种电源状态。看M0的运行状态。ST的BLE协议栈会通过HW_TS_等机制管理RF的唤醒但前提是M0的systick不能停。你可以检查CFG_HW_*的宏定义确认低功耗配置是否与BLE共存。5.3 射频唤醒机制Dongle上更敏感USBDongle因为是USB供电没有电池续航压力很多厂家示例默认不会启用深度低功耗。但如果你修改过工程进入了STOP模式这就很尴尬——USB插着芯片却睡着了广播没了。更要命的是有些开发者在调试时会短接Dongle上的复位等触点导致它反复复位看起来像“一直不广播”。我在实际项目里遇到过一种很隐蔽的情况Dongle在USB插入瞬间5V还没稳定芯片已经开始跑代码了5V持续爬升的过程中DCDCDC-DC转换器的输出还没建立好RF的电源域电压不够后面的电台反复初始化失败。这种上电时序问题不会每次必现但确实让板子“时好时坏”。解决思路是加一个上电延时或者在main函数最前面加一段延时等USB 5V稳定后再初始化BLE。6. 第四步排查用信号工具确认“空气里到底有什么”软件改了一轮硬件也查了广播还是不出现这时候不要继续盲调了直接上专业工具看看空中到底有没有信号。这里的工具不是示波器而是专门针对2.4GHz/蓝牙的抓包工具。6.1 手机上的nRF Connect最快速的定性工具手机装一个Nordic官方的nRF Connect或者LightBlue打开扫描页面。如果你能看到设备列表里出现一个名字说明广播确实在发。此时即使连接不上也说明RF通路基本是通的。但注意一个细节手机扫描覆盖的广播信道是有限的。BLE广播在37/38/39三个信道上轮流发手机只扫描其中一个或两个。如果你广播时把channel_map设成了只发37信道手机刚好在扫描38信道那就“看不到”。这个参数0x07表示三个信道都发但如果你之前改过配置只留了某一个信道那手机就会间歇性发现设备甚至完全看不到。6.2 CubeMonitor-RFST自家工具能看到更多细节ST有个工具叫STM32CubeMonitor-RF作用是让另一块STM32WB开发板扮演“嗅探器”抓取空中的BLE数据包。它比手机扫描的优势在于可以看到广播包的内容广播地址、数据段、厂商自定义数据。可以看到RSSI值如果同一个Dongle在正常板子旁边RSSI为-40dBm而你的故障板RSSI是-80dBm那肯定是天线链路有问题。可以看到丢包率如果广播间隔100ms你观察10秒理论上应该有约300个广播包3个信道如果只有10个说明RF链路极不稳定。使用CubeMonitor-RF需要另一块STM32WB板子当接收端。如果你手上只有一块Dongle且它还坏了那这个方法用不了。但如果你有NUCLEO-WB55可以把它刷成“RF sniffer”的例程ST官方有专门的BLE sniffer固件配合Wireshark抓包。6.3 逻辑分析仪和协议分析仪更底层的验证手段如果怀疑固件压根没走到广播API可以用逻辑分析仪抓SPI或UART日志。STM32WB的BLE协议栈支持HCI接口如果你通过UART把HCI trace打出来就能看到M4发给M0的命令序列。具体做法在代码里使能HCI_TRACE相关的宏ST的示例工程里通常有。把Dongle的UART TX/RX引出来接到USB转TTL上。打开串口终端复位Dongle观察是否有HCI_COMMAND和HCI_EVENT日志。正常的启动序列里应该能看到LE_Set_Scan_Enable、LE_Set_Advertise_Enable之类的命令。如果连这些命令都没出现那问题100%在M4的用户代码逻辑上比如根本没有调用到启动广播的API。如果命令出现了但无响应那就要回到M0或协议栈固件的排查。7. 常见问题速查表与独家避坑经验这里把Dongle不广播的几类典型原因和对应排查手段汇总成一张表方便你对照自己的现象快速定位。现象可能原因首选排查手段LED闪烁但手机扫不到任何广播GAP层未调用广播使能API检查代码逻辑确认aci_gap_set_discoverable()被调用且返回值正常手机偶尔能扫到但很快又消失天线虚焊/损坏或RSSI过低打开nRF Connect看RSSI或用CubeMonitor-RF统计丢包率在某台电脑上不广播换电脑就正常USB口供电不足换一个USB口或加一个有源Hub测5V电压广播数据里没有设备名称广播数据配置未含名称字段检查aci_gap_set_advertising_data和set_discoverable的name参数烧录后LED完全不亮工程板型选错GPIO引脚不对用CubeMX重新生成Dongle对应工程烧录过一次后什么都不跑了误擦除了BLE Stack固件重新烧录ST官方带BLE Stack的完整镜像代码里已经调用了广播API但返回值报错协议栈未初始化或参数不合法在API前后打印日志确认HCI初始化是否成功板子需要按一下复位才会广播低功耗模式逻辑或上电时序问题在main开头加延时或关闭STOP模式关于其中几条我再展开说说第一条程序逻辑压根没走到广播API。这种问题在小白手里特别多。有人喜欢在初始化之前加一堆HAL_Delay()结果延时时间过长其实什么都没干也有人把广播代码放在某个外设中断回调里结果中断永远没触发。我的建议是按“main函数从头到尾走一遍”的思路把HAL_Delay和一些无关外设初始化先注释掉只保留BLE最小初始化一步一步加回来总会找到是哪一步把流程卡住的。第二条天线问题。如果你手头有频谱仪直接看2.4GHz频段有没有峰。如果没有频谱仪就拿两个Dongle做对比测试——一个是你确认正常的一个是故障的用手机分别扫对比RSSI。正常板子在30cm左右的距离RSSI通常在-40-60dBm如果故障板是-80甚至更低那基本就是天线/匹配网络的问题。第三条USB口供电。这个我真的遇到过把Dongle插在台式机前面的USB口广播间隔是100ms但手机扫到的广播包数量很不稳定换到机箱后面的直连USB口问题立刻消失。原因就是前面板的USB延长线电压降太大Dongle内部的3.3V LDO在某些瞬间不够给RF前端用。解决方案是换合适的USB口或者自己改造一下用外部3.3V电源供电测试。8. 最像“翻车现场”的三种复盘记录为了让你有更直观的体感我再写三个我实际调试中遇到过的“魔幻场景”都是能对应上“Dongle不广播”的具体案例你不妨对号入座。8.1 场景一NUCLEO工程直接烧录LED不亮朋友的板子拿到手先用ST官网下载的BLE_HeartRate例程直接在IAR里选择“NUCELO-WB55RG”目标烧录到Dongle。结果LED不亮手机也扫不到。后来帮他查了一遍发现CubeMX生成工程时默认把LED初始化放在PB13但Dongle上LED在另一个引脚而且这个引脚还被初始化成了其他功能导致整个GPIO初始化函数执行到一半就报错退出了。最后操作在CubeMX里把板卡型号改过来重新生成代码再编译烧录。一分钟解决。复盘千万别拿NUCLEO工程硬套Dongle。这种板型不匹配的错误表面症状和“芯片坏了”一模一样非常迷惑人。8.2 场景二能连接但永远扫不到广播包一度怀疑是Dongle天线坏了用频谱仪一看37/38/39三个信道确实有周期性信号出来频谱形状也正常。但手机上就是扫不到。后来发现这个工程烧的是“beacon信标”类型的广播广播间隔设成了1000ms算下来adv interval是1600再加上低功耗策略它每隔好几秒才发一包。手机扫描器刚好错过了一两包导致在UI上看起来就像是“没有广播”。解决方案把广播间隔从1600改成160100ms并在扫描器界面停留超过10秒再观察设备名称终于出现了。这个案例的教训是广播间隔太长、广播包丢了一两包用户体验起来就是“不广播”。做演示或者抓包时先把广播间隔调短确认链路通再改回合适的省电参数。8.3 场景三多个Dongle同时工作只有固定的一个没广播实验室里三块Dongle同时插USB有两块正常中间那块不广播。第一反应是“那块板子坏了”。后来把三块板子调换USB口还是同一块板子不广播说明问题在板子本身。用放大镜仔细看天线附近的走线发现疑似有一条微小的划痕可能伤到了PCB天线根部。因为没有频谱仪就先用万用表量天线馈点到地是否有短路结果是正常的然后换了一个焊盘重新用飞线焊了一个外置天线板子立刻能广播了。说明原板载天线确实已经损坏。复盘Dongle这种小尺寸的PCB天线板机械强度真的不高。反复插拔、磕碰、甚至天气变化导致的应力都可能让天线性能劣化。如果你有两块一样的板子直接用对比法就能快速锁定问题在硬件还是软件。9. 最后再分享几个小技巧排查Dongle不广播的过程本质就是“分层剥离”的过程先硬件再固件再射频。很多人一上来就去看GAP代码或者怀疑天线其实都是跳步操作最后只会浪费一整天。我的习惯是遇到“不广播”的问题先花5分钟做三件事在Dongle上电的瞬间用CubeMonitor-RF或者手机扫描确定到底是“完全没信号”还是“有信号但很不稳定”。查一遍你的广播初始化代码确认每一条API的返回值都是0。手动把低功耗相关的代码临时屏蔽排除“芯片在睡觉”的可能。如果这三步都做完了还没找到问题再回到硬件用仪器测试。说实话我调试过的“不广播”问题里至少有三分之一最后发现是天线或供电问题而不是代码问题。所以别小看硬件检查。另外一个小技巧利用ST的STM32CubeProgrammer也可以在命令行下读取RSSI相关的寄存器信息虽然不如专门的射频工具直观但聊胜于无。如果你是Linux环境还可以用bluetoothctl直接扫描BLE设备有时候比手机更方便快速。希望这套排查流程能帮你把Dongle的广播“救”回来。如果你手头的板子情况比较特殊不妨试着对照表格里的现象逐条排查并且把每一步的实验结果记录下来——这种问题往往一到两轮定位就能找到根因。