企业官网建设流程全解析

第一次用NUCLEO-WB55RG开发板做BLE项目，烧完官方示例，手机nRF Connect扫了半天一片空白——这个场景应该有不少人遇到过。标题里那句"No advertisments from NUCLEO-WB55RG"，英文虽然把advertisements拼错了，但问题描述得很直白：开发板压根没发BLE广播包。如果你搜索相关资料时一直没找到对症的解法，大概率也是被这个拼写带偏了方向。

这篇文章不是教你从零写BLE协议栈，而是围绕"STM32WB55系列为什么会出现静默无广播"这件事，把我自己排查这类问题时的完整思路、踩过的坑、验证过的方法全部摊开。从硬件层面的供电和时钟，到CubeMX里的工程配置，再到M0+核心的协议栈固件状态，最后落到手机端扫描不到的隐蔽原因，一条链路全部过一遍。无论你是刚接触STM32WB的新手，还是已经在项目里被广播问题折磨了几天的老手，这篇文章都能提供一个可以直接照做的排查顺序。

1. 先弄清"没广播"和"扫描不到"是两回事：排查起点必须对齐

很多人看到手机扫不到设备，第一反应就是代码配置错了，于是反复去改广播间隔、广播数据、扫描响应包，改了一整天也没解决。我先说一个之前项目里最戏剧化的案例：我们的硬件工程师拿到的板子天线焊反了，射频信号根本出不去，但软件这边每个人都坚信是代码问题，因为在逻辑上代码确实能跑。后来用频谱仪一测，射频输出端完全是平的，大家才反应过来问题根本不在软件层。

所以排查BLE广播问题，第一件事不是看代码，而是先定义清楚：你是哪种"没广播"？

情况A：代码执行了，但射频层没有任何信号出来。这属于物理层或者协议栈固件的问题，手边的频谱仪、专用BLE抓包器甚至第二块开发板都能测出来，但手机大概率扫不到。

情况B：射频信号是有的，但手机/上位机扫不到。这属于广播参数、广播内容、连接白名单、手机蓝牙缓存等"上层"问题，此时你用nRF Connect扫描器和BLE sniffer能看到设备，但手机自带蓝牙设置页或某些App就是扫不到。

情况C：程序压根没执行到广播启动的代码。这属于工程配置、初始化流程、断言死循环之类的问题。

排错最忌讳的就是不区分这三种情况直接开干。我自己现在固定的一套做法是：先拿一个最简单的官方示例（比如STM32Cube_FW_WB里的BLE_HeartRate或BLE_p2pServer）烧录进去，如果官方示例都发不出广播，那就是硬件或工具链的问题；如果官方示例能扫到，再回头查自己工程改了什么。这一步能在十分钟内帮你排除掉一半的干扰项。

还有一个看似废话但实际经常翻车的点：你用哪台手机、哪个App去扫描？不同手机对BLE广播的过滤策略差异极大。iPhone的CoreBluetooth在后台状态下扫描机制比较特殊，Android从Android 6.0开始扫描需要动态定位权限，Android 12及以上还有BLUETOOTH_SCAN运行时权限。如果你不检查App配置，很容易出现"明明有广播但手机就是不显示"的误判。所以排查初期，建议直接备一台Android手机，装上nRF Connect（Nordic官方出的那个），把位置权限和蓝牙权限都给足，这台设备作为"参考扫描仪"。

在进入后面的具体排查之前，先记住一个基本概念：BLE广播发生在GAP层（Generic Access Profile）。STM32WB的架构里，GAP层以及更底层的链路层、物理层，都是跑在Cortex-M0+核心上的预编译协议栈固件里，不归你写的Cortex-M4应用代码管。所以广播是否发出，取决于两件事：一是M0+核上的协议栈固件是否正确加载并运行，二是M4核通过IPC（跨核心通信）给协议栈下达了正确的广播命令。搞明白这个架构，很多排查思路就清晰了。

2. 硬件层面的关键检查项：供电、时钟与射频通路

很多人在软件里翻来覆去找问题，最后发现是硬件板子本身没给够工作条件。NUCLEO-WB55RG本身是ST官方的评估板，按理说板级硬件是标准的，但它在某些场景下依然暗藏陷阱。

2.1 供电不足：一个能解释所有玄学问题的原因

NUCLEO-WB55RG有两种供电方式：通过ST-LINK的USB口供电（5V来自USB，经板载稳压器转出3.3V），或者通过Arduino排针上的VIN/3.3V引脚外部供电。

大部分时候用USB供电是没问题的，但要注意：如果你同时给板子上的其他外设供电，比如接了LED灯带、舵机、射频扩展板，电流就可能超出板载稳压器的承受范围。STM32WB55RG跑BLE广播时，峰值电流本身就能到十几毫安，加上射频功放瞬间抽流，如果供电电压跌落超过一定幅度，射频核心就可能复位或无法正常工作，表现就是时好时坏、有时候上电能广播有时候不能。

我自己的排查方法是把万用表打到直流电压挡，直接测板子上的3.3V和VBAT引脚，在反复按复位键和触发广播的瞬间观察电压有没有明显跌落。如果发现电压波动超过100mV，先拔掉所有外设再测一次。很多"诡异"的广播失败，最后都是供电不干净导致的。

2.2 32MHz和32.768kHz晶振：BLE的命脉

STM32WB55RG需要两颗晶振：一颗32MHz主晶振（用于系统时钟和射频），一颗32.768kHz低速晶振（用于RTC和低功耗模式下的唤醒）。BLE射频对时钟精度要求很高，BLE规范要求广播信道上的频率误差在正负50kHz以内，而STM32WB内部射频核心的本地振荡器是靠32MHz晶振作为参考的。

NUCLEO-WB55RG板载了这两颗晶振，出厂焊接通常是合格的。但如果你用过国产兼容板，或者自己画的板子，就要特别注意32MHz晶振的负载电容匹配。我曾经在一块自绘板子上遇到的场景是：晶振能起振，但频率偏了30多ppm，结果协议栈起来后广播时断时续，连接经常掉线。这种问题你用逻辑分析仪、用调试器看代码都发现不了，必须用频谱仪或者高精度频率计去量。官方的NUCLEO板基本不会出这种问题，但如果你把代码搬到自绘板上就出现"官方板能广播、自己板不广播"，晶振匹配是第一嫌疑。

另外还要检查HSE就绪标志。如果在SystemClock_Config里HSE起振超时，代码可能会卡死在HAL_RCC_ClockConfig的错误处理里，程序根本没跑到BLE初始化的地方。这种问题临床表现就是"完全没广播"，但DEBUG单步又能跑过去，因为调试器连接时时钟行为会发生变化。建议在初始化代码里加上HSE超时后的错误指示，比如点个LED或者打印日志，不要傻傻地等死循环。

2.3 天线匹配与射频通路：看不见的物理层瓶颈

NUCLEO-WB55RG板载PCB天线，ST官方设计的天线匹配电路是经过验证的。但这里有一个容易被忽略的点：板子角落的SMA连接器（如果有的话）和天线选择跳线。部分NUCLEO-WB55RG板型上，射频输出可以通过0欧电阻或跳线在天线和SMA座之间切换。如果跳线帽位置不对，射频信号全跑到了SMA座上而没有接天线，辐射效率会急剧下降，近在咫尺的手机也收不到。

判断射频通路是否正常，最直接的办法是用STM32CubeMonitor-RF（ST官方出的一款射频测试工具）连接开发板，它可以读取射频核心的寄存器状态并触发连续载波或调制信号。如果能正常发出单载波信号，说明射频链路和协议栈状态基本健康，问题更可能出在广播参数的配置层。

提示：如果你没有频谱仪也没有ST官方射频工具，还有一个土办法——把开发板贴近一个带RTL-SDR芯片的软件无线电接收棒，把频率调到2.4GHz频段，如果能看到2.402/2.426/2.480GHz附近出现周期性短脉冲，说明射频通路至少是在工作的。这个方法不算精确，但做初步判断够用。

3. CubeMX工程配置中的隐形地雷：参数没配对，广播就是出不来

如果你确认硬件没问题，官方例程能正常广播，那问题就锁定在自己的工程工程里。STM32WB的开发流程比普通STM32多了一个关键步骤：不仅要配置M4内核的外设，还要配置RF协议栈的加载和IPC通信。这两个环节任何一个没配对，广播都会失败。

3.1 用CubeMX生成工程时最容易忽略的步骤

先用ST官方推荐的流程理一遍。在STM32CubeMX里选择NUCLEO-WB55RG，然后：

1. 在Categories里找到Middleware and Software Packs，点开RF。
2. 打开RF协议栈配置，选择你要用的协议：BLE、802.15.4或者Thread。如果只需要BLE，就只勾BLE，不要同时勾选多个协议栈。
3. 在BLE配置界面里，需要设置Device Name、Advertising Interval等参数，这些参数最后会生成到代码里。
4. 关键一步：在Toolchain设置里选择正确的IDE版本，生成代码后，还需要手动将协议栈固件（比如stm32wb5x_BLE_Stack_full_fw.bin）烧录到芯片的FUS（Firmware Upgrade Services）区域。

第二步里有一个隐形坑：如果你选择的是"Full"协议栈还是"Light"协议栈，会影响M0+核的固件大小和功能集合。对于NUCLEO-WB55RG自带的STM32WB55RG芯片，Flash有1MB，Full协议栈足够放下。但如果用的是WB55CE之类的低容量型号，要注意Flash空间是否足够。

第三步里最关键的隐藏参数是Advertising Table相关内容。CubeMX的BLE配置界面里有一个"Payload"列表，你没往里面添加任何Advertisment Data的话，生成的代码可能只配置了广播参数但没有实际设置广播内容。部分协议栈版本在广播数据为空时，不会真正开启广播。所以有一个经验：在CubeMX里至少往ADV Data里塞一个Flags字段或者Complete Local Name字段，让广播内容非空。

3.2 IPC中断与核间通信的配置状态

STM32WB双核架构的核间通信依赖一组共享内存和IPC中断。CubeMX在生成BLE工程时会自动配置好IPC中断的向量和优先级，但如果你后续手动修改过NVIC配置，比如把某些中断优先级调了，极端情况下会导致M4核下发命令给M0+核的消息得不到及时处理，广播启动命令一直卡在队列里。

一个直观的检查方式：初始化BLE协议栈时通常会调用hci_init()函数，这会通过IPC通知M0+核的协议栈准备就绪。如果在调用后你等待某个事件标志位（比如CFG_HCI_CB_EVT_INIT），但这个标志位永远等不到，十有八九是IPC中断被屏蔽了或者优先级配置错乱。

这个坑的隐蔽之处在于：不开DEBUG单步跑的时候完全无感，一旦你在调试器里手动改了某些寄存器或者中断优先级，行为就会变得很随机。所以我自己定了一个规矩：CubeMX生成的NVIC配置尽量别手改，尤其是RCC_IRQn、IPC_IRQn、HSEM_IRQn这几个和双核通信紧密相关的中断源。

3.3 烧录方式不对：只烧了M4代码，没烧协议栈固件

这个坑在STM32WB开发里太常见了。NUCLEO-WB55RG出厂时芯片里预置了FUS固件，但BLE协议栈固件不一定预置。如果你用IDE直接烧录M4核心的应用程序，烧完发现跑不起来、或者压根没有广播，先去检查一下协议栈固件是否烧进去了。

判断方法很直接：用STM32CubeProgrammer连接开发板，在Firmware Upgrade Services选项卡里查看当前芯片的FUS版本和已安装的无线栈版本。如果无线栈区域是空的，说明协议栈固件没装。这时需要先将stm32wb5x_BLE_Stack_full_fw.bin通过FUS接口烧入。

有一个细节：烧录协议栈固件和烧录应用固件的顺序有讲究。ST官方推荐先通过FUS烧协议栈，再烧M4应用代码。如果你先烧了应用代码再去烧协议栈，有些版本组合会出现应用代码校验失败的情况。保险起见，我每次拿到新板子都会先做一次完整流程：Erase整个芯片 -> 烧FUS -> 烧无线栈 -> 烧M4应用。不要嫌烦，这一步能消除大量兼容性隐患。

4. 代码层逐行排查：从协议栈初始化到广播启动的完整调用链

如果硬件、协议栈固件都正常，下一步就要仔细审查自己的代码了。STM32WB的BLE应用代码层级清晰，广播相关的调用主要集中在app_ble.c（或者你自定义的BLE任务文件）里。我建议按从底向上的顺序排查。

4.1 协议栈初始化序列：差一步都不行

一个标准的BLE广播初始化序列大致如下（以STM32CubeFW_WB的BLE_HeartRate例程为蓝本）：

/* 1. 初始化HCI传输层 */ hci_init(); /* 2. 等待HCI初始化完成事件 */ while (!hci_cmd_resp_event_received) { /* 通常用的是信号量或事件标志组 */ } /* 3. 重置BLE协议栈 */ hci_reset(); /* 4. 初始化GATT接口 */ aci_gatt_init(); /* 5. 初始化GAP，设置设备名称和IO能力 */ aci_gap_init( GAP_DEVICE_NAME_LENGTH, // 设备名长度 "WB55_BLE_Peripheral", // 设备名 &gap_service_handle, // 返回的GAP服务句柄 &gap_dev_name_char_handle, // 设备名特征句柄 GAP_IO_CAP_NONE, // IO能力 GAP_DISCOVERABLE_MODE_GENERAL, // 可发现模式 GAP_ACCEPT_CONNECTION_MODE_UNDIRECTED // 接受连接模式 ); /* 6. 设置广播数据 */ aci_gap_update_adv_data( ADV_DATA_SIZE, adv_data // 一个包含Flags和LocalName的数组 ); /* 7. 设置扫描响应数据 */ aci_gap_update_scan_response_data( SCAN_RESP_DATA_SIZE, scan_resp_data ); /* 8. 正式开启广播 */ aci_gap_set_discoverable( GAP_DISCOVERABLE_MODE_GENERAL, (uint16_t)ADV_INTERVAL_MS, (uint16_t)ADV_INTERVAL_MS );

每一步都有一个返回值，而很多人写代码时忽略了对这些返回值的检查。排查时建议在每一步之后都加上错误判断和日志输出。我曾经遇到过一次aci_gap_set_discoverable返回0x40（未知HCI命令错误），查了老半天才发现是前面aci_gap_init里传的设备名长度超过了协议栈允许的最大值，导致GAP初始化实际失败，后续命令全部报错。

4.2 广播数据内容：空数据、超长数据和不符合规范的TLV

BLE广播数据是典型的TLV结构（Type-Length-Value），比如：

static const uint8_t adv_data[] = { 0x02, 0x01, 0x06, // Flags, 指示LE General Discoverable Mode 0x09, 0x09, 'W', 'B', '5', '5', // Complete Local Name };

第一项是长度（0x02），第二项是类型（0x01 = Flags），第三项是值（0x06）。第二组同理：长度0x09（9字节），类型0x09（Complete Local Name），后面9个字节是名字。

常见的坑是：长度字段算错。比如名字是"WB55"，你写着0x09其实应该是0x06。协议栈不会校验你的TLV内容是否正确，它就原样发出去。但手机端的解析器遇到格式错误的广播数据可能直接丢弃整个广播包，表现就是"明明有广播波彤但手机就是扫不到"。所以广播数据一定要用nRF Connect这类工具里的Raw视图检查，确认TLV格式正确。

另一个坑是广播数据超长。传统广播通道（Advertising Channels）上的广播包最大有效载荷是31字节（PDU里已经包含了6字节的广播地址和2字节的头部）。如果你的adv_data数组超过31字节，aci_gap_update_adv_data会直接返回错误。有些新手把设备名、服务UUID、厂商自定义数据全塞进去，一数发现超过31字节，然后广播就静默失败了。

4.3 事件回调与信号量等待：死锁导致广播永远不启动

STM32WB的BLE协议栈是异步事件驱动的。M4核下发命令后，协议栈处理完会产生事件回调，比如hci_le_advertising_report、aci_gap_procedure_complete_event等。很多开发者为了同步逻辑，会在广播启动后阻塞等待某个事件信号量，但忘了初始化信号量对应的队列/任务。

我遇到过的具体场景是：在一个RTOS工程里，BLE任务初始化时创建了一个osSemaphoreNew，然后调用aci_gap_set_discoverable，紧接着osSemaphoreAcquire等待一个ACK事件。但由于事件回调里osSemaphoreRelease执行在另一个中断上下文，信号量优先级配置不当导致事件丢失，结果就是任务永远挂在同步等待上，广播启动代码后面的部分（比如GATT服务的注册）永远执行不到。从外面看，设备确实没广播，但不是广播本身失败，而是流程被卡住了。

排查这类问题的方法是在关键节点加日志：HCI init done、GAP init done、ADV data set、Discoverable set，每走一步打一条。不用逻辑分析仪都能很快定位卡在哪一层。

4.4 若考虑用C#/WinForms做上位机扫描：不要忽略PC蓝牙栈的差异

标题相关的热搜词里出现了"C#实现BLE蓝牙通信"、"WinForms项目对于net framework 4.7.2实现BLE蓝牙通信可以用的第三方库"这类话题。这也是一种常见场景：开发板广播正常，但你用PC作为扫描端扫不到。如果你是在Windows上做BLE上位机开发，有几个特点跟手机不同：

第一，Windows自带的蓝牙栈对BLE广播的暴露很有限。UWP的Windows.Devices.Bluetooth.AdvertisementAPI可以接收广播，但你需要在项目清单里声明蓝牙功能。传统WinForms（.NET Framework 4.7.2）没有官方UWP API，所以必须借助第三方库。

目前可用的方案大概有这几种：一是BluetoothLEExplorer之类的开源库，封装了WinRT API供.NET Framework调用；二是转向.NET Core / .NET 5+，直接用Windows.Devices.Bluetooth；三是使用InTheHand.Net.Bluetooth这类纯托管库，但它对BLE广播的接收支持不完整。我自己实际项目里比较推荐的是用.NET 5或更高版本，直接引用WinRT的Windows.Devices.Bluetooth.Advertisement，这样能获取原始广播包。

另一个关键点：Windows的蓝牙驱动如果被第三方蓝牙适配器（比如低劣的USB蓝牙棒）接管，可能导致广播检测极不稳定。排错时换一个品牌蓝牙适配器（CSR或Intel的芯片）往往能解释掉一堆"代码没问题但收不到"的现象。

还有一点容易被坑到死：Windows的蓝牙广播接收和手机有个重要区别——Windows默认不监听所有广播。在BluetoothLEAdvertisementWatcher里，ScanningMode有两个选项：Passive和Active。默认的Passive模式表示只监听广播包，不发送扫描请求；而主动扫描模式（Active）会发送扫描请求以获取扫描响应数据。某些设备配置的广播数据很少，主要信息放在扫描响应里。如果你用Passive模式扫描，看到的设备名可能是空的，你会误以为广播不正常。这个坑在排查上位机收不到广播数据时非常常见。

4.5 另一个网络热词"esp32-s3 wifi与ble协议"：对照调试的思路

热搜词里有"esp32-s3 wifi与ble协议"，说明不少人是带着ESP32的开发经验来上手STM32WB的。这两个平台的BLE开发方式差异很大，但恰好可以互相参照调试。

ESP32的BLE例程通常在app_main里直接调用esp_ble_gap_start_advertising()，跑的是完整开源协议栈（ESP-IDF内置了Bluedroid或NimBLE），烧录一个固件就能完成所有事情。而STM32WB是双核架构，协议栈是闭源预编译库，跑在M0+核上，你还得管理FUS升级、核间通信这些ESP32上不存在的概念。

但两者的底层标准是一样的。如果你手头有ESP32-S3开发板，可以做一个很有意思的实验：让ESP32-G5也发同样的广播参数，然后看两台手机/同一台手机扫描这两个设备的行为差异。这能帮你判断问题出在广播参数配置层面还是STM32WB特定的协议栈层面。比如，如果ESP32用同样的广播间隔和功率发广播，手机能扫到，而STM32WB扫不到，那问题基本锁定在STM32WB的协议栈状态配置上。这种"对照组"排查法在嵌入式开发里非常有效。

5. 手机端扫描不到的隐蔽原因与"假广播"问题

有时候射频信号有、协议栈状态也正确，但你的手机就是扫不到。这一节专门讲那些"把代码从头检查到尾都找不到问题，结果发现冤枉了代码"的场景。

5.1 手机蓝牙缓存与系统过滤机制

手机在扫描到BLE设备后，系统层和App层都有缓存。最常见的情况：你之前成功连接过某个设备，手机里已经存了它的配对信息。当你修改了广播数据里的设备名，或者广播地址发生了变化，手机可能会因为缓存中的链路信息不匹配而选择不显示该设备。

iPhone的操作路径是：设置 -> 蓝牙 -> 找到设备 -> 点击"忽略此设备"，然后重启蓝牙。Android则要复杂一些，需要在蓝牙设置里清空"已保存的设备"，或者直接清除App的存储数据。排查时建议换一台从未连接过该设备的手机做交叉验证，如果新手机能扫到而旧手机扫不到，那就是缓存问题。

还有一个容易被忽视的机制：Android的"附近设备"权限（NEARBY_DEVICES）或iOS的定位服务权限没给够。Android 12以上的App如果没申请BLUETOOTH_SCAN权限，扫描的时候会静默失败。iOS则在后台扫描时要求开启定位权限，否则广播接收会被系统切到极低频。

5.2 广播类型、定向广播与白名单

BLE广播有几种类型，最常见的两种：

• 无定向广播（Undirected）：任何人都可以扫描到，也可以发起连接。
• 定向广播（Directed）：只针对特定设备，广播包内有特定的目标设备地址，非目标设备不会在扫描报告里展示。

如果你把广播模式设成了定向广播（例如GAP_DISCOVERABLE_MODE_LIMITED配了特定的绑定设备地址），手机上的nRF Connect会扫不到它，或者只在极少情况下看到。STM32WB的aci_gap_set_discoverable接口里有一个参数控制广播模式，排查时确认一下没有误设成定向模式。

另一个相关的机制是白名单（White List）。如果你在协议栈里配置了白名单过滤，只有白名单内的设备才能收到广播或者发起到你的连接。开发初期，我强烈建议把白名单功能关掉，除非你明确知道自己在做什么。

5.3 广播间隔和广播功率：手机扫描不是即时的

很多开发者在调试时，把广播间隔设得特别大以省电，比如1000ms甚至更久。手机端扫描BLE设备时，通常是周期性扫描每个广播信道，每次扫描窗口可能只有几十毫秒。如果广播间隔是1000ms，而广播包在每个周期内只出现在三个广播信道中的一个信道上，手机可能需要好几秒甚至十几秒才能偶然捕获到一个广播包。这个体验跟"扫不到"几乎一样。

快排的做法是把广播间隔临时降到20ms~100ms，同时把广播功率调到最大，然后观察是否能扫到。能扫到，就说明逻辑链路是通的，再把间隔调大去平衡功耗。我自己的标准调试参数是：广播间隔40ms，发射功率0dBm，扫描响应使能。等调试结束再根据实际需求优化。

广播功率在STM32WB里由aci_hal_set_tx_power_level()函数控制，默认不一定是最大功率。如果之前有人为了过认证把功率调到了-20dBm，那近场扫描不到也是正常的。

5.4 协议栈事件上报频率与扫描响应缺失

BLE广播分为广播事件（Advertising Event）和扫描响应（Scan Response）。广播事件是设备主动发出的，扫描响应是手机在收到广播后发送扫描请求（SCAN_REQ），设备再回复的。如果你的广播数据里只放了少量信息（比如只放了一个Flags字段），那么手机可能在扫描结果里看到一个没有设备名的"未知设备"。

nRF Connect的扫描列表里如果出现一个没有名字的设备，很多新手会直接忽略它，以为那不是自己的板子。这是典型的"假广播"确认偏误：广播确实有，但显示得太不明显。解决方法是把设备名放到广播数据里，而不是扫描响应数据里，或者检查nRF Connect的Raw字段，根据MAC地址确认是不是自己的设备。

MAC地址也是排查时一个有用的信息点。STM32WB的公共MAC地址来源于出厂时烧录的唯一ID，但开发板有时候会出现MAC地址全零或者固定值的情况。如果手机端看到的MAC地址和你预期不符，说明协议栈在读取设备地址时出了问题，可能是FUS区域里的UID没有被正确读取。这种情况下，你可以通过aci_gap_set_public_address手动设置一个公共地址来验证。

6. 排查链路完整复盘：一套可以复用到其他无线项目的思路

到这里，关于NUCLEO-WB55RG广播不出去的问题，我已经把硬件、固件、代码、上位机各个层面的常见原因都过了一遍。最后把这套排查思路提炼成一套步骤，下次遇到类似问题（不仅限于STM32WB，也可以是ESP32、nRF52等任何BLE平台的"广播异常"），你可以直接用这个框架：

这五个层面按顺序排，从上到下排查，每层都有快速验证手段。我的经验是，80%的"完全没广播"问题出在前两层（物理层和协议栈固件），而80%的"信号有但手机扫不到"问题出在后两层（GAP配置和手机端）。

关于STM32WB这个平台，我最后还想额外提两个很多人在项目后期才会发现的细节：

第一个是关于功耗优化和广播的冲突。如果你在工程里启用了低功耗模式（PWR_EnterSTOPMode之类），但BLE协议栈的CFG_BLE_NUM_LINK、CFG_BLE_ATT_MTU等配置和低功耗唤醒周期配合不好，会导致射频核心在唤醒后没有及时同步广播调度，出现"进入低功耗后广播漂移甚至消失"的问题。开发阶段我通常先禁用低功耗，把广播调通后再逐步加入低功耗策略，否则低功耗和广播交织在一起，排查难度翻倍。

第二个是关于FUS版本的兼容性。STM32WB的无线协议栈固件和FUS是分开升级的，FUS版本过低会导致某些新的BLE功能（比如PAwR，这是网络热词里提到的一个较新特性periodic advertising with responses）不受支持。如果你印象中明明配置了周期广播相关参数，但设备行为完全不对，可以考虑先升级FUS和无线协议栈到互相兼容的版本。ST的Release Notes里会有每个版本对应的兼容性矩阵，升级前一定要看那个表。

真正把这一整套流程走完，大多数NUCLEO-WB55RG的"静默"问题都能水落石出。我自己后来遇到"广播没了"的情况，已经可以做到十分钟内定位到具体层级：先看CubeProgrammer确认协议栈固件在不在，再用频谱仪或第二块板子确认射频通不通，最后才去看自己的应用代码。这套顺序下来，既不会在代码层面瞎折腾，也不需要一上来就怀疑硬件设计，效率比乱打乱撞高得多。