在调试 NUCLEO-WB55 USBDongle 时上电不广播这个问题我前前后后碰到过三次。每次原因都不一样一次是出厂固件里压根没烧 BLE 程序一次是 SWD 引脚被代码占用了导致烧录失败还有一次是 USB 供电电流不够Dongle 插上去之后射频部分根本没起来。这篇文章就把这三类问题、排查过程和最终解决办法一次性讲清楚给正在被这个不广播搞得头疼的朋友一条完整的排障路线。NUCLEO-WB55 USBDongle 是 ST 推出的基于 STM32WB55RG 的 USB 样式开发板官方定位是配合 BLE 调试工具做演示和抓包但在实际项目中很多人拿它做自定义 Beacon、透传网关、甚至 OTA 测试工具。它的核心是双核 MCUCortex-M4 负责应用Cortex-M0 只跑蓝牙协议栈相当于一个独立协处理器所以 BLE 协议栈运行和应用逻辑是隔离的。这既是它的优势也是很多人调试时懵圈的地方——你在 M4 上写的代码未必能把广播跑起来因为广播服务的真正调度在 M0 那边。提示标题里的advertizing是 advertising 的常见拼写错误搜索引擎里这个拼法搜出来的讨论反而不少。不过不影响下面所有内容围绕BLE 广播不工作来展开。1. 先搞清楚硬件和固件的匹配关系1.1 NUCLEO-WB55 USBDongle 到底是个什么板子STM32WB55RG 是一个双核无线 MCU主核 Cortex-M4 跑应用代码协同核 Cortex-M0 运行 ST 预编译好的蓝牙协议栈二进制文件称为 FUS / BLE Stack 固件。NUCLEO-WB55 USBDongle 只是把这块芯片做成 USB Stick 形态板上引出了 USB-C 接口、RGB LED、两个按键、SWD 调试接口和天线。它和常见的 NUCLEO-WB55RG 开发板最大的区别是Dongle 版本没有板载 ST-LINK不能直接插 USB 线就调试必须外接一个 ST-LINK 或者借助另一块 NUCLEO-WB55RG 板载的 ST-LINK 通过 SWD 来烧录调试。很多朋友拿到 Dongle 的第一反应是拿 USB 线插电脑然后打开手机蓝牙搜设备结果什么都搜不到。这是正常的因为出厂固件默认烧的是ST HID或者BLE Sensor相关的演示程序而且这取决于你买到的批次和出厂烧录内容。它不是一块插上就能广播 Beacon的板子。USB 枚举成功只代表芯片的 USB 外设在跑不代表 BLE 射频在上电后就启动广播了。USB Dongle 的板载天线是 PCB 天线走的是 2.4G 频段官方标称输出功率可以调到 6 dBm 左右。板子没有电池供电电路必须靠 USB 口取电这也是后面供电问题的根源。调试时建议先看板子上的 LED默认程序里 LED 会闪烁或常亮如果 LED 完全没反应先怀疑供电和枚举问题如果 LED 正常但无广播再往固件方向排查。1.2 默认出厂固件不是 Beacon别指望上电就广播为了确认出厂固件内容最直接的办法是用 STM32CubeProgrammer 读一下芯片的 Flash。连接好 ST-LINK 后打开 STM32CubeProgrammer选择 ST-LINK 接口点击 Connect。如果连接正常在 Memory 视图里看一眼地址 0x08000000 开始的区域或者直接读取 Option Bytes。值得注意的是Dongle 版本的 ST-LINK 连接方式不是板载虚拟串口而是 SWD 四线SWDIO、SWCLK、GND、3.3V。我建议第一次拿到 Dongle 的朋友不要急着写自己的应用先 STM32CubeProgrammer 全片擦除然后烧录官方 BLE_Beacon 例程验证射频通路是否正常。这一步能隔离硬件坏了还是固件不对两个问题。官方例程在 STM32CubeWB 固件包里Projects/P-NUCLEO-WB55.USBDongle/Applications/BLE/BLE_Beacon。需要注意的是BLE 协议栈固件stm32wb5x_BLE_Stack_full_fw.bin和用户应用固件是分开烧录的FUSFirmware Upgrade Service固件也要提前烧好。出厂时芯片内部一般已经烧好了 FUS 和 BLE Stack但如果你执行过全片擦除或者拿到了不带协议栈的芯片就必须按顺序重新烧录先烧 FUS再烧 BLE Stack最后烧应用。顺序错了M0 就起不了协议栈广播自然跑不起来。具体的地址分配在 STM32CubeWB 包里的Projects/P-NUCLEO-WB55.USBDongle/Applications/BLE/BLE_Beacon/README.md写得非常清楚。1.3 硬件供电和 USB 枚举的坑USB Dongle 对供电品质很敏感。它的射频部分在广播瞬间会有比较大的电流尖峰如果插在劣质 USB HUB 或老旧电脑的前置 USB 口上电压跌落会导致 M0 协议栈异常复位表现就是偶尔广播一下然后消失或者完全没有广播。我第三次遇到不广播就是插在一个不带外部供电的 USB 3.0 HUB 上。Dongle 的 LED 正常亮USB 枚举也正常但手机始终搜不到。用万用表量 USB 的 5V空载时 5.05V插上 Dongle 后瞬间跌到 4.72V射频一开就掉到 4.5V 以下。换到电脑后置 USB 口或者带供电的 HUB 后问题直接消失。所以排查顺序里把供电放在前三位是必要的。另外提醒一点Dongle 的 USB-C 口不是所有线都能用。我遇到过一根只支持充电不支持数据传输的 USB-C 线导致 STM32CubeProgrammer 无法识别设备但 BLE 广播其实正常。这时候用手机能看到广播却以为板子挂了。遇到怎么都连不上的情况先换一根确认能传数据的线。2. 固件烧录这关过不去广播就是空中楼阁2.1 烧录用的是哪个工具链NUCLEO-WB55 USBDongle 没有板载调试器烧录前需要准备一个 ST-LINK/V2 或者 ST-LINK/V3。我用的是 ST-LINK/V2 的克隆版某宝几十块那种配合 STM32CubeProgrammer 完全够用。接线是标准 SWD 四线SWDIO、SWCLK、GND、3.3V。板上 SWD 引脚是印在背面的注意看丝印别焊反。如果你手头正好有一块 NUCLEO-WB55RG 开发板也可以把它板载的 ST-LINK 当作调试器给 Dongle 烧录只需要把 NUCLEO 板上的 CN2 跳线帽拔掉断开板载 ST-LINK 与目标 MCU 的 SWD 连接然后从 ST-LINK 输出引脚飞线到 Dongle 的 SWD 引脚。这样省一个调试器但操作麻烦一点我建议还是单独买个 ST-LINK几十块钱节省大量时间。连接好之后打开 STM32CubeProgrammer选择 ST-LINK 模式把 Mode 设为 Under reset 或者 Hot Plug一般 Hot Plug 就够用。点击 Connect 后软件会读出芯片型号 STM32WB55RG并在左下角显示当前保护级别Read Out Protection 应该是 Level 0如果显示 Level 1 会限制读取和烧录需要先解除保护。2.2 固件选择官方示例 vs 自建工程官方固件包 STM32CubeWB 里针对 USBDongle 的 BLE 应用主要放在Projects/P-NUCLEO-WB55.USBDongle/Applications/BLE/目录下包含 BLE_Beacon、BLE_HeartRate、BLE_Throughput 等。BLE_Beacon 是最小的工程逻辑最简单特别适合做验证射频通路这件事。如果你用的是 STM32CubeMX 自建工程注意选择正确的 BoardP-NUCLEO-WB55.USBDongle。在 CubeMX 里如果不选对板子引脚分配、射频匹配、天线开关控制这些配置就会对不上。STM32WB55 需要外部 32MHz 晶振HSE32作为射频参考时钟CubeMX 生成的时钟树如果配置错了BLE 协议栈初始化会直接卡在hci_init()或者干脆不广播。官方案例工程不需要手动配置时钟因为工程文件里已经写好了。这也是我建议新手先用官方案例跑通再改自己工程的原因。如果你用的不是 STM32CubeWB 里的工程而是网上找的第三方模板一定要核对三个关键点协议栈地址、FUS 地址和应用起始地址。这三个地址只要错一个下载后大概率是程序跑飞或协议栈起不来。ST 官方工程里这些地址是通过链接脚本预置好的不熟悉的朋友不要自己乱改。2.3 烧录后复位和连接器的问题烧录完成不是终点Dongle 需要断电重新上电或者按一下板上的复位按钮如果有才能正常进入广播状态。很多人烧完固件后不手动复位以为程序会自动运行结果一直没广播。实际上 STM32CubeProgrammer 烧录完成后默认会复位并运行但如果你用的是第三方烧录工具不一定有这个行为手动断电重插一次最稳。另外一个容易踩的坑是 SWD 引脚被复用了。有些 BLE 应用会把 PB3、PB4、PA15 这些 SWD 相关引脚配置成 GPIO 或者射频控制脚一旦代码运行调试接口就被切断了。这会导致你烧录完第一次程序后第二次再也连不上 ST-LINK。解决办法是烧录时把 BOOT0 拉高让芯片从系统存储器启动先中断用户程序然后用 STM32CubeProgrammer 重新连接并擦除 Flash。但我实际操作下来STM32WB55 的 BOOT0 引脚拉高有讲究Dongle 板上没有专门引出来得飞线。更省事的办法是使用 STM32CubeProgrammer 的 Connect under reset 模式把复位引脚也接上在复位释放的瞬间拉低 SWD 请求成功率更高。SWD 连接不上是一个高频问题。如果你确认接线正确、驱动正常但 STM32CubeProgrammer 始终报 No ST-LINK detected 或 Target connection failed优先检查 Option Bytes 里的 RDP 级别。我之前买过一批二手 Dongle里面 RDP 被设置成了 Level 1直接导致无法连接必须先用 STM32CubeProgrammer 的 Remove protection 功能解除。注意解除保护会全片擦除之后需要重新烧录 FUS 和 BLE Stack。3. 从 Beacon 示例开始一步一步让 Dongle 广播起来3.1 打开官方 Beacon 例程改参数前先理解参数STM32CubeWB 的 BLE_Beacon 例程位置我上面已经给了用 IAR、Keil 或者 STM32CubeIDE 打开都可以。我自己主要用 STM32CubeIDE开箱即用不需要额外配置工程链。打开之后先不要编译先在app_conf.h和hci_tl.h里确认协议栈相关配置再看app_ble.c。BLE_Beacon 例程的核心就是adv_data[]这个数组它定义了广播数据的内容。例程默认发的是一个简单的自定义 Beacon广播间隔默认参数通常是ADV_INTERVAL_MIN_MS和ADV_INTERVAL_MAX_MS单位换算成 BLE 的时间单位是 0.625ms。官方默认值看两个宏但最终的值会被aci_gap_set_discoverable()这个 HCI 命令的Advertising_Interval_Min、Advertising_Interval_Max参数覆盖。有一点很多新手会搞错BLE 广播间隔不是一个固定数值而是一个区间实际广播间隔由协议栈在这个区间内随机选取这是蓝牙规范用来减少同频干扰的机制。所以如果你配置的 min100ms、max100ms实际广播串间隔也不会完全是 100.000ms而是在 100ms 附近抖动。用手机 App 观察时别因为每次广播间隔有几毫秒偏差就觉得有问题。广播数据里除了用户自定义的 Manufacturer Specific Data还有必要的 Flags 字段表示这个设备支持LE General Discoverable Mode。如果 Flags 缺失很多手机 App 会直接过滤掉这个广播包表现为设备可见但不显示。所以自建广播数据时Flags0x02 0x01 0x06这 3 个字节一定不要省。3.2 编译烧录和串口日志验证BLE_Beacon 例程默认不开串口日志但 NUCLEO-WB55 USBDongle 的虚拟串口是通过 ST-LINK 的 CDC 实现的Dongle 本身并没有独立的 USB-UART 桥接芯片。所以如果你用的是外接 ST-LINK它是没有虚拟串口的你只能在 STM32CubeProgrammer 的 Serial Wire ViewerSWV里看 printf 输出或者直接忽略日志靠 LED 状态判断。这个板子有一个 RGB LED在 BLE_Beacon 例程里如果广播正常LED 会进入一个周期闪烁状态。具体颜色和频率在app_ble.c里可以通过BUTTON_LED相关 API 调整。我的判断方法是如果上电后 RGB LED 有周期性闪烁说明 M4 应用已经跑起来了再配合手机端看到广播包基本可以确认整个链路没问题。编译烧录这步要注意先用 STM32CubeProgrammer 确认 Flash 里已经烧好了 BLE Stack。检查方法是在 Memory 视图里读协议栈地址比如 0x08008000 或 0x08080000取决于工程配置如果全是 0xFF 说明协议栈没烧进去。BLE_Beacon 例程的链接脚本里定义了BLE_STACK_ADDRESS不同版本偏移不同所以直接用 .bin 烧的时候一定要按 README 里的偏移地址来。我犯过的错误是把 BLE_Stack 固件用默认 0x08000000 地址烧进去直接把应用固件覆盖了然后整板变砖重新烧了三次才搞对。3.3 用手机和抓包器确认广播包广播跑没跑起来最直观的手段是手机。iOS 上推荐用 LightBlue 或 nRF ConnectAndroid 上我用的是 nRF Connect 和BLE 调试助手这类 App。打开 App 扫描如果看到广播名比如ST Beacons或你自定义的设备名说明广播已经发出去了。但这只是第一步广播包的内容是否合法、功率是否达标单靠手机看不详细。深入排查时必须上抓包器。低成本方案是再拿一块 NUCLEO-WB55 开发板刷成 BLE Sniffer配合 Wireshark 抓包。ST 官方提供了STM32WB BLE Sniffer工具用起来比 nRF Sniffer 稍微麻烦一点但配置无误的话抓包结果很干净。抓包主要看三点广播事件是否周期性出现、广播通道37/38/39是否都能抓到、RSSI 是否符合预期。如果只有单个通道出现广播说明射频链路有问题如果三个通道都有但 RSSI 极低优先怀疑天线匹配或供电。手机能搜到广播但 RSSI 显示特别弱比如 -80 dBm 以下而且人靠近板子也只有 -60 左右这种一般不是软件问题而是射频硬件或天线问题。NUCLEO-WB55 USBDongle 的 PCB 天线区域务必保持干净不要用手大面积握住天线部分也不要用 USB 延长线把 Dongle 悬在金属桌面附近。金属物体对 2.4G 天线的吸收效应非常明显实测同一块板子放在金属底座上和放在塑料支架上RSSI 能差 15 到 20 个 dB。注意BLE 的广播通道固定在 2402MHz、2426MHz、2480MHz这三个频点旁边往往有 Wi-Fi 的 2.4G 信号。如果现场 Wi-Fi 信道恰好落在这些频点附近广播包碰撞概率会增大但不是广播消失的根因。只要广播间隔正常协议栈会在后续间隔里重试不会出现永久看不到的现象。4. 常见问题与排查技巧实录4.1 上电后完全没有广播手机和抓包器都找不到这是最典型的情况优先级最高的是确认协议栈是否起来了。可以在app_ble.c的APP_BLE_Init()里临时加一个 GPIO 翻转用示波器或者逻辑分析仪看 M0 初始化完成后有没有执行到。实际上更快的办法是检查hci_init()的返回值STM32WB55 的 HCI 层和 M0 通信是通过内部 IPC 完成的如果返回错误说明 M0 没有正常运行协议栈。常见的错误返回是HCI_UNSUPPORTED_FEATURE或者HCI_COMMAND_DISALLOWED这两种情况通常不是应用代码问题而是 FUS 和 BLE Stack 版本不匹配。去 ST 官网下载最新版 STM32CubeWB里面固件和 FUS 是配套的不建议混搭不同版本。版本不匹配的典型现象就是编译烧录都成功、LED 正常、就是不广播排查成本极高所以我开头就说先确认协议栈版本匹配。还有一个隐蔽问题FUS 的启动状态影响整个协议栈加载。在 STM32CubeProgrammer 的 FUS 页面操作时如果看到 FUS is not running说明 FUS 没有启动需要先发送 Start Wirestack 命令或者重新烧录 FUS。这个状态在出厂芯片里一般没问题但如果你对 Flash 做过擦除就得重新走一遍 FUS 启动流程。4.2 广播时有时无间隔一大就消失广播时有时无通常不是节点本身的问题而是环境干扰或供电跌落。我遇到过一种情况板子放在电脑旁边靠近 USB3.0 HUB 时广播正常但放到金属机箱上后广播消失拿起来悬空广播又回来了。这个属于天线阻抗受周围环境变化导致发射效率下降协议栈本身没有报错。解决办法很粗暴把 Dongle 放到干净的位置再测试。另一种可能是ENTER_LOW_POWER_MODE没有关闭导致 MCU 进入低功耗状态后射频子系统的时钟或供电被间歇性关断广播间隔被拉长到几秒甚至十几秒一次。在官方例程里CFG_LOW_POWER_MODE这个宏默认是启用的它在电池设备上很有用但在 USB 供电的 Dongle 上没意义。如果你发现广播间隔比配置值大很多看看这个宏是否被定义成了 1改成 0 后问题通常马上消失。低功耗设计本身没有错但在 USB Dongle 这种持续供电设备上省电逻辑只会引入不必要的复杂度。还有一次我的现象是手机扫到广播后不断重连连上就断开用抓包器看广播正常但连接请求CONNECT_REQ阶段设备没有回应。检查后发现是代码里没有正确处理连接事件回调M4 没有及时调用aci_gap_connection_complete_event之后的程序相当于只广播但不参与连接。这个属于应用层逻辑问题不是射频问题排查方向要分开。4.3 手机看不到但抓包器能正常抓到广播这种场景很有迷惑性抓包器确认广播在发手机却扫不到很多人会怀疑手机坏了。其实大概率是广播数据格式或广播参数不满足手机端过滤条件。如果广播包设置了ADV_TYPE为不可连接广播Non-connectable undirected advertising很多手机在扫码界面会直接忽略因为这种广播不可连接扫了也没用。Beacon 类应用常用这个类型但如果是想做连接类应用要选择可连接广播。另一种情况是广播周期太长。如果把广播间隔调到 1000ms 以上手机端扫描窗口通常是 10.24 秒为一个周期其中约 3.84 秒在扫描就有概率漏掉你表现为时有时无。蓝牙规范里若广播间隔小于等于 100ms扫描器几乎必能发现间隔大于 1s 时就要碰运气了。排查时把广播间隔临时调小到 50~100ms如果手机马上能看到问题就在广播参数上。手机上装了某些过滤类 App比如防广告拦截类的可能会屏蔽未知 BLE 设备。我自己的 Android 手机上装了个网络管控工具它会把厂商 ID 是 0xFFFF 的广播包当成可疑设备自动过滤掉。换个手机或者换 App 试试能避免被这种软件玄学带偏方向。4.4 RSSI 和天线布局为什么广播功率调了没效果官方例程里通常有aci_hal_set_tx_power_level()这个 API可以设置发射功率比如 0 dBm、3 dBm、6 dBm。很多人调大功率后发现手机 RSSI 没有明显提升就以为 API 没生效。实际上 STM32WB55 的发射功率有多个等级最大 6 dBm 时电流消耗明显增加但 RSSI 的提升不是线性的——从 0 dBm 调到 6 dBm理论上只增加 6 dB反映在手机上通常只有几个 dB 的改善而环境的反射、路径损耗、天线方向带来的影响远不止 6 dB。天线布局对 RSSI 的影响更大。NUCLEO-WB55 USBDongle 的天线区域在 PCB 一端距离 USB 接口较远。使用时要保证天线周围 1cm 以内没有金属遮挡。如果 Dongle 是插在电脑后面板或者显示器集线器上天线部分可能被金属壳包围信号衰减会非常明显。最好用一根 USB 延长线把 Dongle 拖出来让天线区域悬空实测 RSSI 能从 -70 dBm 提到 -55 dBm。RSSI 调试时还要注意测量环境的一致性。我会固定一个测试位置板子放在塑料泡沫支架上手机固定在 1 米外的同一地点然后把所有变量广播间隔、信道、发射功率、天线方向逐个调整每次只改一个变量。如果不控制变量连续测得 RSSI 波动能有 ±10 dB根本无法判断改动效果。5. 几个值得收藏的排查习惯和工具搭配5.1 遇到问题先做减法而不是做加法不广播这个问题的排查思路我建议遵循从底层往上的减法原则先确认供电和硬件再确认调试连接再确认协议栈是否运行最后才是应用代码逻辑。很多朋友一上来就怀疑自己写的广播数据有问题改了半天发现是 ST-LINK 线接触不良浪费时间。我的排障顺序是固定的万用表量 USB 5V 电压插上 Dongle 后看压降是否超过 0.3V确认 STM32CubeProgrammer 能正常连接并读出 Flash 内容确认 Flash 里存在的固件类型和地址是否符合预期烧官方 BLE_Beacon 例程验证射频通路手机 nRF Connect 扫描看 RSSI 和广播名如果还不行用抓包器看协议栈行为这套顺序能覆盖我遇到过的所有不广播场景。不需要每次都走完但遇到玄学问题时从头走一遍往往能发现前面遗漏的细节。5.2 工具搭配建议调试器ST-LINK/V2 或 V3建议用原版或者质量好的兼容版劣质克隆版在 SWD 高速模式下容易不稳定。烧录工具STM32CubeProgrammer版本尽量新注意它和 STM32CubeWB 固件包版本的配套关系。抓包工具另一块 NUCLEO-WB55 开发板 STM32WB BLE Sniffer 固件 Wireshark成本低效果好。手机 AppnRF ConnectAndroid/iOS 都有、LightBlue各装一个交叉验证扫描结果。万用表普通的 3 位半万用表就够主要量电压。逻辑分析仪排查低功耗模式问题时有用看 GPIO 翻转状态和时序。这套工具加起来成本不高但能把软件能看到和射频实际发出去这两件事同时覆盖排障时不用来回猜。5.3 现场环境对 BLE 广播的影响比想象中大最后提醒一点BLE 广播的现场环境因素非常容易被忽略。我曾在办公室里调试一块 Dongle手机就在旁边但始终搜不到广播抓包器一抓发现广播事件一直在发。反复排查后发现办公桌旁边有一个 USB 3.0 高速硬盘盒它的金属外壳和内部高速信号正好在 2.4G 频段产生强干扰。把硬盘盒挪远半米之后手机立即就搜到了。如果你在办公室或者测试台调试先把周围的大块金属物体、USB 3.0 设备、无线鼠标接收器都移开能排除一大批环境干扰。无线鼠标接收器这个很多人都没注意。2.4G 无线鼠标用的频段和 BLE 部分重叠而且无线鼠标是持续占信道发射的对 BLE 广播的干扰比 Wi-Fi 还明显。我实测过无线鼠标接收器离 Dongle 10cm 以内广播包丢包率能从 1% 涨到接近 10%手机扫描成功率明显下降。调试时把这些设备拿远一点能省很多排查时间。6. 结合实际项目如果 Dongle 做自定义 Beacon建议怎么改6.1 广播数据的组织和注意事项如果确认板子能正常广播接下来就是把它改成自己想要的 Beacon。广播数据最大是 31 字节包括头字节、长度字节和数据内容。BLE_Beacon 例程里的adv_data[]是按 TLV 格式组织的第一个字节是长度Length第二个字节是类型Type后面是数据Value。例如0x02, 0x01, 0x06表示长度为 2、类型为 Flags、数据为 0x06。自建 Beacon 时Manufacturer Specific Data 是常用的自定义载体。它由公司 IDCompany ID2 字节和自定义数据组成。普通开发者没有购买 SIG 的公司 ID可以用 0xFFFF 作为测试用 ID。要注意的是广播数据总长不能超过 31 字节如果超了协议栈会直接返回错误广播可能不启动。我把一个 28 字节的 UID 放进去之后忘了算长度结果广播完全没发出来排查了半天才发现是数组越界。广播名Device Name也占用广播数据的空间如果名字设得很长剩下的空间就少了。我的建议是广播数据里只放必要的信息名字尽量短比如 5 个字符以内把空间留给自己的数据。如果确实需要完整设备名可以把名字放到 Scan Response Data 里手机扫描时也能看到但广播包本身会更精简。6.2 广播事件类型和连接配置的选择Beacon 类应用一般用不可连接广播non-connectable这样可以减少功耗和协议开销但缺点是手机不能连上来做数据交互。如果 Dongle 后面要做数据透传或者 OTA就要改回可连接广播。STM32WB55 的 HCI 命令里aci_gap_set_discoverable()的 advertising type 参数不同对应行为也不同。调试时先用可连接广播跑通了再根据需求调整减少变量。连接间隔Connection Interval和从机延迟Slave Latency在连接场景下同样重要。这两个参数由主机在连接请求里指定但从机可以在aci_gap_set_peripheral_configuration()里设置可接受范围。如果从机设置的范围和主机请求的差异太大连接会失败或频繁断开。我遇到过一个问题Dongle 广播正常但手机连接后 3 秒就断实时排查发现是连接间隔冲突。把从机可接受范围放宽后连接就稳定了。这类问题在 Beacon 阶段不会暴露但后续要转成连接模式时一定会碰到。7. 最后分享一点个人体会NUCLEO-WB55 USBDongle 不广播这个问题说大不大说小不小但每一次排查下来我对 STM32WB55 的协议栈结构、FUS 机制、低功耗模式都有更深的理解。其实绝大多数不广播问题都不是板子坏了而是供电、协议栈版本、烧录地址、广播参数这几个环节里某个细节没对上。把这些环节逐个验证一遍花的时间不会太长。我个人在实际操作中的体会是调试这类双核无线芯片最好先建立M4 应用日志、BLE 协议栈状态、射频抓包三个视角同时看问题的习惯。M4 的日志能告诉你应用代码跑到哪一步协议栈状态能告诉你 M0 是否正常抓包能告诉你射频数据是否真的发到空中。三个视角对齐后问题定位基本就是时间问题。另外一个不算技巧的技巧每次烧录前先把要用的固件版本记下来包括 FUS、BLE Stack、App 三个版本。很多难啃的问题最后发现只是某个组件被更新后引入了不兼容。调试记录写清楚能省下大量的重复排查时间。希望这篇基于实际踩坑经验整理的内容能帮你少走弯路。如果你也遇到类似的广播问题不妨按照上面的顺序排查一遍大概率能在半小时内定位到根因。