STM32WB55 USBDongle不广播？从硬件到协议栈的完整排查指南

遇到过“板子插上去，灯也亮了，手机就是扫不到广播包”这种情况的朋友，应该能秒懂标题里的这个痛点。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）要对外广播，需要满足这些条件：

1. 射频收发器（Radio）已经被协议栈初始化：在STM32WB上，这意味着M0+内核（负责跑RF协议栈）已经启动，并且M4内核（用户应用）和M0+之间的核间通信（IPCC）已经建立。
2. GAP层被配置为可发现/可连接模式：也就是说，调用了类似aci_gap_set_discoverable()或者aci_gap_set_non_connectable()这样的API，把广播数据、广播间隔这些参数写到了协议栈里。
3. 广播使能没有被关闭：在ST的BLE协议栈里，广播使能有很多种开关，包括可连接广播、不可连接广播、定向广播等，这些开关是独立控制的。
4. 射频前端正常：天线的频偏不能太大。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）或者lsusb（Linux）。如果固件带USB描述符，系统会枚举出一个复合设备；如果固件里压根没初始化USB，那系统只会提示“未知USB设备”或“设备描述符请求失败”，这时候反而说明USB物理层是通的（因为D+上拉电阻起了作用），芯片在上电后至少跑了一部分代码。

但要注意，USB枚举成功和芯片的射频子系统启动没有直接关系。很多Dongle出厂预烧的固件（比如ST的“自举程序”bootloader）本身就能完成USB枚举，让你能进入DFU模式，但如果你没有跳转到用户App，或者用户App压根没写射频相关的初始化，那它当然不会广播。

所以，USB枚举这块，我的建议是：

• 在Windows设备管理器里确认枚举出的VID/PID是不是0x0483 / 0x5740（ST的标准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可能在别的引脚上“默默发光”，你看不到，就会误以为板子没跑起来。

正确做法是：

1. 去ST官网下载Dongle的原理图（文件名叫mb1355或者类似命名）。
2. 打开原理图，找到LED网络标签对应的MCU引脚。
3. 在你的工程里用这个GPIO做翻转测试，比如每500ms翻转一次LED。
4. 烧进去看灯光是否闪烁。

如果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地址范围。我们在排查不广播之前，必须确认这些配置没有被改乱。

操作步骤：

1. 用ST-Link连接Dongle的SWD触点。
2. 打开STM32CubeProgrammer，选择ST-Link，连接。
3. 在左侧“Option Bytes”页面，检查RDP级别是否为Level 0（无读保护）。如果Level 1，读保护会禁止调试器读取Flash内容，也就没法确认固件是否完好；如果Level 2，那基本无法通过SWD恢复，只能扔掉或者用ST的特殊恢复流程。
4. 读取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+到底跑没跑？有几个办法：

1. 读IPCC状态寄存器：如果M4发送命令给M0+，对方却没有响应，多半是协议栈没起来。在调试器里可以看hci接口函数的返回值，是不是返回超时或者错误码。
2. 检查SYS_CMD/ 协议栈状态：ST的BLE例子代码里通常会有一个MX_APPE_Init()流程，里面会初始化BLE协议栈。如果初始化失败，代码一般会卡在HAL_BLE_Init()或者aci_gap_init()附近，你可以在这些函数调用处打断点，看第一次失败发生在哪个调用。
3. 看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上这个引脚悬空或者被用于其他功能，初始化时可能读回随机电平，导致外设状态机卡死。

解决办法很简单，但需要多一步操作：

1. 在STM32CubeMX里新建工程时，直接选“NUCLEO-WB55RG / USBDongle”对应的板卡模板，让CubeMX自动匹配正确的引脚和时钟树。
2. 如果你手上已有的工程是从NUCLEO拷过来的，请打开ioc文件，重新选择板卡类型，让CubeMX重新生成引脚配置。
3. 对比两个板子的原理图，把差异部分的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.625ms，160就是100ms广播间隔，有些人习惯写20（12.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持续爬升的过程中，DCDC（DC-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-RF：ST自家工具，能看到更多细节

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不广播的几类典型原因和对应排查手段汇总成一张表，方便你对照自己的现象快速定位。

关于其中几条，我再展开说说：

第一条，程序逻辑压根没走到广播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改成160（100ms），并在扫描器界面停留超过10秒再观察，设备名称终于出现了。

这个案例的教训是：广播间隔太长、广播包丢了一两包，用户体验起来就是“不广播”。做演示或者抓包时，先把广播间隔调短，确认链路通，再改回合适的省电参数。

8.3 场景三：多个Dongle同时工作，只有固定的一个没广播

实验室里三块Dongle同时插USB，有两块正常，中间那块不广播。第一反应是“那块板子坏了”。后来把三块板子调换USB口，还是同一块板子不广播，说明问题在板子本身。用放大镜仔细看天线附近的走线，发现疑似有一条微小的划痕，可能伤到了PCB天线根部。

因为没有频谱仪，就先用万用表量天线馈点到地是否有短路，结果是正常的；然后换了一个焊盘重新用飞线焊了一个外置天线，板子立刻能广播了。说明原板载天线确实已经损坏。

复盘：Dongle这种小尺寸的PCB天线板，机械强度真的不高。反复插拔、磕碰、甚至天气变化导致的应力，都可能让天线性能劣化。如果你有两块一样的板子，直接用对比法就能快速锁定问题在硬件还是软件。

9. 最后再分享几个小技巧

排查Dongle不广播的过程，本质就是“分层剥离”的过程：先硬件，再固件，再射频。很多人一上来就去看GAP代码，或者怀疑天线，其实都是跳步操作，最后只会浪费一整天。

我的习惯是，遇到“不广播”的问题，先花5分钟做三件事：

1. 在Dongle上电的瞬间，用CubeMonitor-RF或者手机扫描，确定到底是“完全没信号”还是“有信号但很不稳定”。
2. 查一遍你的广播初始化代码，确认每一条API的返回值都是0。
3. 手动把低功耗相关的代码临时屏蔽，排除“芯片在睡觉”的可能。

如果这三步都做完了还没找到问题，再回到硬件用仪器测试。说实话，我调试过的“不广播”问题里，至少有三分之一最后发现是天线或供电问题，而不是代码问题。所以别小看硬件检查。

另外一个小技巧，利用ST的STM32CubeProgrammer也可以在命令行下读取RSSI相关的寄存器信息，虽然不如专门的射频工具直观，但聊胜于无。如果你是Linux环境，还可以用bluetoothctl直接扫描BLE设备，有时候比手机更方便快速。

希望这套排查流程能帮你把Dongle的广播“救”回来。如果你手头的板子情况比较特殊，不妨试着对照表格里的现象逐条排查，并且把每一步的实验结果记录下来——这种问题往往一到两轮定位就能找到根因。