企业官网建设流程全解析

在调试 NUCLEO-WB55 USBDongle 时，"上电不广播"这个问题，我前前后后碰到过三次。每次原因都不一样，一次是出厂固件里压根没烧 BLE 程序，一次是 SWD 引脚被代码占用了导致烧录失败，还有一次是 USB 供电电流不够，Dongle 插上去之后射频部分根本没起来。这篇文章就把这三类问题、排查过程和最终解决办法一次性讲清楚，给正在被这个"不广播"搞得头疼的朋友一条完整的排障路线。

NUCLEO-WB55 USBDongle 是 ST 推出的基于 STM32WB55RG 的 USB 样式开发板，官方定位是配合 BLE 调试工具做演示和抓包，但在实际项目中，很多人拿它做自定义 Beacon、透传网关、甚至 OTA 测试工具。它的核心是双核 MCU：Cortex-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）和用户应用固件是分开烧录的，FUS（Firmware 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 自建工程，注意选择正确的 Board：P-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 广播间隔不是一个固定数值，而是一个区间，实际广播间隔由协议栈在这个区间内随机选取，这是蓝牙规范用来减少同频干扰的机制。所以如果你配置的 min=100ms、max=100ms，实际广播串间隔也不会完全是 100.000ms，而是在 100ms 附近抖动。用手机 App 观察时，别因为"每次广播间隔有几毫秒偏差"就觉得有问题。

广播数据里除了用户自定义的 Manufacturer Specific Data，还有必要的 Flags 字段，表示这个设备支持"LE General Discoverable Mode"。如果 Flags 缺失，很多手机 App 会直接过滤掉这个广播包，表现为"设备可见但不显示"。所以自建广播数据时，Flags（0x02 0x01 0x06）这 3 个字节一定不要省。

3.2 编译烧录和串口日志验证

BLE_Beacon 例程默认不开串口日志，但 NUCLEO-WB55 USBDongle 的虚拟串口是通过 ST-LINK 的 CDC 实现的，Dongle 本身并没有独立的 USB-UART 桥接芯片。所以如果你用的是外接 ST-LINK，它是没有虚拟串口的，你只能在 STM32CubeProgrammer 的 Serial Wire Viewer（SWV）里看 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 Connect，Android 上我用的是 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 线接触不良，浪费时间。

我的排障顺序是固定的：

1. 万用表量 USB 5V 电压，插上 Dongle 后看压降是否超过 0.3V
2. 确认 STM32CubeProgrammer 能正常连接并读出 Flash 内容
3. 确认 Flash 里存在的固件类型和地址是否符合预期
4. 烧官方 BLE_Beacon 例程验证射频通路
5. 手机 nRF Connect 扫描，看 RSSI 和广播名
6. 如果还不行，用抓包器看协议栈行为

这套顺序能覆盖我遇到过的所有"不广播"场景。不需要每次都走完，但遇到玄学问题时，从头走一遍往往能发现前面遗漏的细节。

5.2 工具搭配建议

• 调试器：ST-LINK/V2 或 V3，建议用原版或者质量好的兼容版，劣质克隆版在 SWD 高速模式下容易不稳定。
• 烧录工具：STM32CubeProgrammer，版本尽量新，注意它和 STM32CubeWB 固件包版本的配套关系。
• 抓包工具：另一块 NUCLEO-WB55 开发板 + STM32WB BLE Sniffer 固件 + Wireshark，成本低效果好。
• 手机 App：nRF Connect（Android/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 是常用的自定义载体。它由公司 ID（Company ID，2 字节）和自定义数据组成。普通开发者没有购买 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 三个版本。很多难啃的问题，最后发现只是某个组件被更新后引入了不兼容。调试记录写清楚，能省下大量的重复排查时间。

希望这篇基于实际踩坑经验整理的内容能帮你少走弯路。如果你也遇到类似的广播问题，不妨按照上面的顺序排查一遍，大概率能在半小时内定位到根因。