STM32WB55RG双核架构下BLE与FreeRTOS集成实战指南

搞嵌入式这几年，只要项目里同时出现“BLE”和“RTOS”这两个词，基本就告别“打开CubeMX生成代码直接跑”的省心模式了。尤其当你拿到的芯片是STM32WB55RG这颗双核MCU时，很多人第一反应是“这不就是带BLE的STM32嘛”，结果一动手就发现，事情远没有这么简单——因为它的BLE协议栈根本不在你写应用代码的那个核上跑。

这个标题问的是“如何在已有工程里把BLE集成到FreeRTOS中”，但我实际做下来，真正卡的往往不是“怎么调用BLE API”，而是“BLE协议栈和FreeRTOS到底谁听谁的”。这枚芯片是Cortex-M4主核 + Cortex-M0+射频核的双核架构，你的FreeRTOS跑在M4上，BLE协议栈跑在M0+上，两边通过共享内存和核间通信机制配合。所以整个集成过程本质是在解决“两个核之间怎么高效、安全地传递事件和命令”的问题。

这篇文章我就拿一个真实的工程改造过程来讲，从架构认知、CubeMX配置、协议栈初始化，到任务划分、事件回调处理、常见坑排查，把一条能直接复用的集成路径完整走一遍。不管你是第一次在STM32WB上碰BLE，还是已经在M4核上调过FreeRTOS但没搞过双核协作，这篇文章都能给你省下不少折腾时间。

1. 先吃透STM32WB55RG的双核架构，再谈集成

1.1 为什么说“双核”是理解整个集成的钥匙

很多从单核MCU（比如STM32F103、STM32F407）迁移过来的朋友，第一个不适应的点就是：以前一个核既跑逻辑又跑通信，顶多是中断优先级分一分；到了STM32WB55RG这里，芯片里有两个完全独立的Cortex核心，职责被强行拆开了。

• Cortex-M4内核：最高主频64MHz，负责跑你的应用逻辑、FreeRTOS调度、外设驱动、算法，以及所有跟“业务”相关的事情。
• Cortex-M0+内核：最高主频32MHz，专门跑蓝牙协议栈和802.15.4协议栈（这颗芯片同时支持BLE和Zigbee/Thread），以及射频相关的底层调度。

这个分工带来的好处很明显：BLE协议栈的时序要求极高，尤其是广播间隔、连接事件、加密握手这些实时性很强的操作，如果和你的业务代码抢占同一个CPU，很容易出问题。现在单独划一个核来跑协议栈，应用核这边怎么卡顿、怎么调度，都不会直接影响射频时序。

但代价就是——应用核和射频核之间必须有一套高效的通信机制。这套机制在STM32WB上叫IPCC（Inter-Processor Communication Controller，核间通信控制器），配合硬件信号量HSEM（Hardware Semaphore）来管理共享资源的访问。M4核向M0+核发命令、M0+核向M4核发事件，都是走这个通道。

提示：IPCC不是一个“可选项”，而是BLE在STM32WB上跑起来的基础设施。如果它没配好，你调用BLE API时可能卡死、可能返回错误，甚至直接HardFault。所以集成FreeRTOS前，先接受“双核协作”这个前提，后面很多奇怪的Bug都能从这条主线上找到原因。

1.2 FreeRTOS在该项目中扮演的真实角色

回到标题的问题：FreeRTOS在这个项目里到底负责什么？用一句话概括——它负责让M4核上的所有“非BLE协议栈”的事情变得有序。具体来说，主要管三件事：

• 任务调度：你的业务逻辑拆成多个任务，比如按键扫描任务、传感器采集任务、数据处理任务、显示刷新任务，由FreeRTOS统一调度。
• 资源同步：多个任务之间共享数据缓冲区，需要互斥锁（Mutex）防止竞争；一个任务等待另一个任务的数据，需要队列（Queue）或信号量（Semaphore）来通信。
• 与BLE事件对接：M0+核通过IPCC把BLE事件（连接建立、断开、收到数据、广播完成等）抛给M4核，M4核这边需要一个事件处理任务来响应。这个任务由FreeRTOS管理，事件到来时唤醒它，事件处理完它就睡下，不占用CPU。

而CMSIS-RTOS2在这里的作用就比较特殊了——它不是一套“新的操作系统”，而是一个统一的操作系统抽象层。你写的代码调用的是osThreadNew、osMessageQueuePut这类API，底层具体是FreeRTOS还是别的RTOS实现，由CMSIS-RTOS2适配层去翻译。换句话说，你打开CubeMX生成代码时，选中的“FreeRTOS CMSIS-RTOS2”这个选项，本质上就是帮你在FreeRTOS之上套了一层标准接口。

为什么要多套这一层？因为STM32的BLE中间件（ST官方提供的无线协议栈接口代码）内部就是基于CMSIS-RTOS2写的。它需要创建线程、需要挂起/恢复调度器、需要获取当前tick计数。如果直接用原生FreeRTOS API，中间件的代码就得跟FreeRTOS强耦合，以后ST想支持其他RTOS就麻烦了。所以你先接受这套“间接层”，后面看ble_hl、tl_if这些模块的源码时，就不会觉得它们写得绕了。

1.3 已有工程集成前需要先做的三个判断

标题特别强调了“in an Existing Project”，也就是说很多人的场景不是从零新建工程，而是手里已经有一个在跑的FreeRTOS工程，现在想把BLE加进去。这种场景下，我建议你先做三个判断，能省掉后面一大半的返工：

第一，工程里的时钟树和CubeMX配置是否保留了默认的HSE/HSI分配。STM32WB的M4核和M0+核共用一个时钟源，但各自的分频独立。如果你的工程是手工改过时钟树的老工程，而射频核那边跑在错误的时钟频率上，最典型的症状是BLE能初始化但搜不到设备，或者广播信号极弱。

第二，是否已经能把M0+核的固件烧进去。STM32WB的射频核有自己的独立Firmware，需要单独烧录。很多人拿到开发板，M4核程序下载进去了，但M0+核还是白片，结果BLE初始化永远卡在等待固件响应这一步。这一点在“已有工程”里特别容易被忽略——因为你之前跑得好好的是纯FreeRTOS工程，根本不涉及射频核。

第三，你是否清楚原有工程的中断优先级配置。FreeRTOS对中断优先级分组有硬性要求，而BLE中间件对IPCC中断优先级也有要求。如果原来的工程为了某个裸机外设把中断优先级分组设置得很随意，那接下来在后续章节里，你会看到这个配置会如何深刻影响BLE和FreeRTOS的共存。

2. 集成前的环境准备与工程配置要点

2.1 芯片型号与射频核固件版本匹配问题

先单独说说“软硬件版本匹配”这件事，因为这个坑我见过太多人踩了。STM32WB55RG这颗料属于STM32WB55系列，内置1MB Flash、256KB SRAM，BLE 5.0和802.15.4双模。它的射频核固件分两类：

• FUS固件（Firmware Upgrade Services）：负责管理射频核固件的升级和安全服务，相当于射频核的“Bootloader”。
• 协议栈固件（比如stm32wb5x_BLE_Stack_full_fw.bin）：真正的BLE协议栈二进制，由FUS负责加载到M0+核里运行。

FUS和协议栈固件的版本必须匹配。我遇到过一种情况：开发板出厂FUS是较老版本，我拿最新的CubeMX生成工程，里面带的协议栈固件要求新版本FUS支持，结果烧录后BLE初始化一直超时。最后查了一圈，不是代码问题，是固件版本匹配问题。

所以准备工作里，我强烈建议你使用STM32CubeProgrammer先读一下芯片里现有FUS和协议栈固件的版本，然后打开CubeMX生成工程时，注意看中间件版本和射频核固件包版本是否一致。如果你在生成代码时选择了“STM32WB55RG”并勾选了BLE，CubeMX会自动把匹配的无线协议栈固件列出来，这时你只需要用CubeProgrammer把它烧到射频核即可，不需要手动找版本对应关系。

2.2 CubeMX工程配置的逐项解读

现在到关键一部分：CubeMX里的具体配置。我不准备把所有选项都列一遍，那就成操作手册了。我只挑几个直接影响“BLE+FreeRTOS能否正常集成”的选项，说说它们背后是什么逻辑。

时钟配置：STM32WB55RG的RF核要求射频时钟非常精确。标准做法是使用外部高速晶振（HSE，通常为32MHz），M4核跑到64MHz，M0+核跑到32MHz。如果你用内部HSI，频率精度虽然也能跑，但蓝牙射频指标会明显变差，实测广播距离会缩短。所以建议硬件上保留HSE晶振位置，软件里确认HSE被正确使能。

RCC和电源配置：STM32WB有专门的SMPS（开关电源）和LDO两种供电模式。CubeMX里默认的配置通常没问题，但有一项要注意——RF核的唤醒源和低功耗配置不要随便改动。BLE本身有功耗管理，如果SMPS配置不对，可能导致射频核无法正常进入低功耗状态，继而影响BLE连接事件调度。

中间件配置：在Middleware and Software Packs里勾选BLE后，会有几个子选项：

• Task number：BLE中间件需要一个专用的FreeRTOS任务来处理协议栈事件。这个任务的数量通常填1到2就够了，CubeMX会根据你的配置自动生成对应的osThreadNew调用。
• 最大连接数量、服务数量、属性数量：这些参数直接决定了BLE协议栈申请的内存大小。如果你只是做一个单连接从机，保持默认即可；如果做多连接Central，就需要调大。
• GATT缓存和ATT MTU：默认256字节的MTU对于普通数据透传够用，但如果你要传大数据包，建议提前规划好。

FreeRTOS配置：启用FreeRTOS并选择CMSIS-RTOS2后，在“Advanced settings”里有个USE_TIMERS、USE_COUNTING_SEMAPHORES等选项，默认勾选即可。真正需要关注的是TOTAL_HEAP_SIZE。BLE中间件本身会通过CMSIS-RTOS2动态创建任务、队列和互斥锁，而C库的malloc在FreeRTOS里默认不一定安全，所以CubeMX生成的BLE代码会使用RTOS Heap。如果你原本的工程Heap只有8KB，加了BLE后一般不够，我建议直接给到16KB以上，具体大小取决于你的任务数量和队列深度。

生成代码后，你打开main.c，会看到CubeMX自动做了两件很重要的事：一是初始化了IPCC和HSEM，二是调用了MX_APPE_Init()或类似函数来启动BLE中间件。这说明BLE的“骨架”已经被搭好了，剩下的任务是往这个骨架上填业务逻辑。

2.3 FreeRTOS优先级与BLE任务优先级的取舍

很多人在这个环节开始纠结：BLE协议栈任务该设多高的优先级？我的业务任务该设多少？这里给一个我自己反复验证过的参考基准，并解释为什么这样分配。

STM32WB的BLE中间件在M4核上会创建几个内部任务（比如管理协议栈事件的任务），这些任务通过CMSIS-RTOS2接口创建。任务优先级的高低，直接影响的是“M0+核抛上来的事件能被多快地处理”。如果你的BLE任务优先级太低，而业务任务里有大循环占着CPU，BLE事件的响应会被延迟，严重时可能出现连接断开或数据丢包。

我常用的做法是：把BLE相关任务优先级设为“正常偏上”（比如7~8），业务中的耗时操作任务（比如传感器采集、图片处理）优先级设为正常（5~6），UI或按键这种非实时任务设为较低（3~4）。同时要注意，FreeRTOS中configMAX_PRIORITIES默认是56，CMSIS-RTOS2里也有对应的配置，把优先级数值设成个位数就好，不用把它撑满。核心思想是：BLE事件不必达到中断级响应，但要保证它在绝大多数情况下都能在几个毫秒内被取走。

注意：不要试图把BLE相关任务设成最高优先级来“一劳永逸”。因为BLE任务一旦持续占用CPU，低优先级任务会饿死，反而导致看门狗超时或者业务逻辑卡住。好的做法是让BLE任务做完一件事就挂起等待下一个事件，把CPU让出来。

3. 核心细节解析：BLE协议栈与FreeRTOS的协作机制

3.1 从“事件驱动”角度看FreeRTOS里的BLE任务

如果你翻过ST提供的BLE示例代码，会发现主流程基本长这样：

void ble_app_task(void *argument) { /* 初始化BLE协议栈 */ BLE_Init(); /* 任务主循环 */ for(;;) { /* 处理IPCC消息，让协议栈事件得到响应 */ Ble_Hci_Gap_Gatt_Listener(); /* 处理用户队列/信号量，执行实际业务 */ ... } }

这段代码看起来像轮询，但背后其实是事件驱动的：Ble_Hci_Gap_Gatt_Listener()函数会检查IPCC是否有新事件，如果没有，任务可以进入阻塞等待状态，直到被信号量或队列唤醒。在CubeMX生成的FreeRTOS工程里，这个等待动作对应一个osMessageQueueGet或osSemaphoreAcquire，调用后任务会挂起，不占CPU。

关键点在于：等待的“信号来源”是两个核之间的中断。当M0+核收到BLE事件（比如手机连上了、手机发了数据过来），它会通过IPCC产生一个中断通知M4核；M4核的中断服务函数里再通过osSemaphoreRelease或osMessageQueuePut把事件交给BLE任务。这样整个链条就是“射频核硬件事件 → IPCC中断 → RTOS信号量 → BLE任务被唤醒”，清晰且高效。

我第一次做这个集成时犯过一个错误：在M4核的IPCC中断里放了很长的处理逻辑，导致BLE事件被处理得太慢，连接事件错过，最后被对端断开。后来改成“中断里只做信号量通知，复杂处理全部丢给任务”，问题立刻消失了。这也是FreeRTOS项目里最常见的“中断里干活太多”的教训。

3.2 BLE协议栈回调机制：不要在回调里睡大觉

BLE协议栈在M4核这边通过“回调函数”把上层事件（GAP事件、GATT事件）告诉你的应用代码。最典型的是连接事件、断开事件、数据读写事件。很多人第一次对接时会觉得自己写的回调函数跑在协议栈任务里，所以想在回调里做很多操作。这是个大坑。

原因在于，回调函数本质上是在BLE协议栈任务的上下文里执行的，它占用的就是那个任务的时间片。如果你在回调里调用HAL_Delay(100)去等待某个外设，或者调用osMessageQueuePut往已经被占满的队列里塞数据而阻塞，整个BLE协议栈事件处理都会被拖慢，甚至导致IPCC消息积压。

我的习惯是：在回调里只做“记录数据+发送信号量/消息”，具体业务逻辑放到专门的业务任务里处理。举个实际场景——收到手机写过来的数据，需要解析后去控制电机：

void on_ble_write(uint16_t handle, uint8_t *data, uint16_t len) { /* 快速拷贝数据到全局缓冲区 */ memcpy(rx_buffer, data, len); rx_len = len; /* 通知业务任务去处理，不要在这里做电机控制 */ osMessageQueuePut(motor_control_queue, rx_buffer, 0, 0); }

这样BLE协议栈任务能立刻返回去处理下一个事件，不会因为一个耗时操作阻塞整个链路。业务任务拿到消息后再去控制电机，哪怕电机控制逻辑再复杂，也不影响BLE连接的稳定性。

3.3 内存布局与共享缓冲区：双核协作的隐形难题

STM32WB的M4核和M0+核共享同一块SRAM，但它们的访问权限是有区分的。CubeMX生成的工程里会自动有一个“核间通信内存区域”的定义，通常是通过MEMORY区域划分或链接脚本来保证的。如果你在已有工程里集成BLE，而原来手工改过链接脚本（比如为了把某个数据放到指定RAM地址），这就要特别小心了——别把共享内存区域的地址给覆盖了。

具体表现可能是：BLE能跑但偶发数据错误、协议栈初始化成功但连接后收发异常。排查起来非常隐蔽。我的做法是在集成分支上先检查链接脚本里RAM和RAM_SHARED区域的地址、大小是否和CubeMX生成的一致，确保没有重叠。

另外，FreeRTOS的堆（Heap）默认是从M4核可用的SRAM里分配的，这块内存不能被共享给M0+核。如果你在M4核上申请了一块缓冲区，然后试图直接让M0+核通过IPCC消息访问它的指针，这在STM32WB上是行不通的。正确的做法是：需要跨核传输的数据，必须放在专门划分的共享内存区域里，再通过IPCC传递“指向共享内存的指针”。这也是为什么ST的BLE中间件代码里大量使用__attribute__((section(".shared")))或类似的属性来说明变量所在区域。

4. 实操全过程：把一个FreeRTOS工程改造成“BLE+FreeRTOS”

4.1 从“已有工程”生成可复现的改造步骤

以下是我在真实项目中从零把BLE集成到一个已有FreeRTOS工程里的完整流程，整个过程按顺序做下来，基本能一次跑通。

第一步：用CubeMX重新生成一个带BLE的FreERTOS基础工程。虽然你手里是“已有工程”，但我建议不要直接在老工程文件里手动加代码。正确做法是在CubeMX里新建一个同型号芯片的配置，把外设和中间件配好，生成一个新工程，然后把老工程的应用代码逐步移植过来。原因是BLE中间件涉及的文件关联很复杂，手动添加容易漏文件或版本不匹配。

第二步：确认射频核固件已经烧录。用STM32CubeProgrammer连接芯片，点击“Firmware Upgrade Services”标签，查看当前射频核的固件状态。如果显示“No stack”或者版本过低，先把CubeMX生成的stm32wb5x_BLE_Stack_full_fw.bin烧进去。烧录时注意选择正确的地址（一般是0x080EC000，具体以CubeMX生成的readme.md为准）。

第三步：生成工程后，先编译一次原始代码，确认RF核和M4核的代码能同时工作。CubeMX生成的工程默认会有一个app_ble.c，里面包含了BLE初始化和事件处理的模板代码。你可以在MX_APPE_Init()之后，在任务循环里加一句printf("BLE init done\n")，验证串口能打印、系统不崩溃。

第四步：把老工程的任务逐个迁移过来。迁移时注意，原有任务如果用了vTaskDelay、xQueueSend这类原生FreeRTOS API，可以直接保留；如果你想让代码风格统一，也可以换成CMSIS-RTOS2的osDelay、osMessageQueuePut。功能上两者等价，但CMSIS-RTOS2的接口更通用。如果老任务里使用了HAL_Delay，建议替换成osDelay或vTaskDelay，因为HAL_Delay是忙等待，会占着CPU空转，削弱FreeRTOS调度的意义。

第五步：添加你的BLE业务逻辑。在app_ble.c里，你会看到ST用“任务+事件循环”的方式组织代码。你可以在APP_BLE_Init里注册自己的服务，在事件回调里处理GATT读写。如果需要自定义服务，一般在app_ble里创建一个service初始化函数，例如：

static void APP_BLE_Add_Custom_Service(void) { /* 添加自定义UUID的Service */ aci_gatt_add_service(...); /* 添加Characteristic */ aci_gatt_add_char(...); }

这里要注意，aci_gatt_add_service等函数返回的Service Handle要保存下来，后续收发数据都会用到。对应的Handle可以放在全局变量里，但要注意跨文件访问时的命名规范，避免和ST内部变量冲突。

第六步：验证BLE扫描、连接、收发。这个阶段我的测试顺序是：先拿手机上的nRF Connect或LightBlue扫描到设备广播，然后连接，再尝试读写自定义Characteristic。如果广播都看不到，优先检查射频核固件是否烧录、双核时钟是否正常；如果连得上但读写有问题，优先检查GATT属性的事件回调有没有正确注册。

4.2 关键代码解析：初始化、事件轮询与业务分发

这段代码直接决定整个集成的骨架。以下是我项目中使用过的精简版结构，注释解释了每段代码的作用，方便你对照自己的工程。

/* 在FreeRTOS任务里启动整个BLE应用 */ void BLE_App_Task(void *argument) { /* 1. 初始化BLE协议栈。 这一步会请求M0+核加载/启动BLE栈，并完成GATT、GAP等基础参数设置。 */ if (BLE_Init() != BLE_STATUS_SUCCESS) { Error_Handler(); } /* 2. 注册GAP/GATT事件回调。 */ hci_gap_event_handler = My_GAP_EventHandler; hci_gatt_event_handler = My_GATT_EventHandler; /* 3. 添加服务，设置广播数据，启动广播。 */ APP_BLE_Add_Custom_Service(); APP_BLE_Set_Advertise_Data(); aci_gap_set_discoverable(...); /* 4. 进入事件处理循环。 */ for (;;) { /* 处理IPCC中来自M0+核的BLE事件。 没有事件时，内部会等待信号量/消息，任务挂起不占CPU。 */ BLE_Protocol_Stack_Event_Handler(); /* 处理我们自己的业务消息队列。 */ Process_App_Message(); } }

注意第4步里的“事件处理”和“业务消息”是分两层的：BLE_Protocol_Stack_Event_Handler()负责把M0+核抛上来的协议栈事件交给ST中间件内部处理，最终会回调到你的My_GAP_EventHandler和My_GATT_EventHandler；而Process_App_Message()则是处理你自己业务层通过队列发来的消息。这种分离的好处是，不管你业务层有多少种消息，协议栈事件始终能被及时处理。

在实际项目里，我会再定义一个专门的消息结构体，把BLE收到原始数据的指针、长度、连接Handle一并打包进消息队列：

typedef struct { uint16_t conn_handle; uint8_t *data; uint16_t len; } Ble_Rx_Message_t;

业务任务收到这个消息后，再决定是解析成指令、存到Flash还是转发给其他外设。这套模式在中小型BLE项目里非常通用，也符合FreeRTOS“事件驱动+任务隔离”的推荐用法。

4.3 双核启动顺序与RF核固件加载的注意事项

STM32WB上电后的启动顺序也值得单独讲一下，因为这直接影响“为什么有时代码能跑但BLE起不来”。

• M4核先运行：芯片上电后M4核从Flash取出向量表开始执行，初始化时钟、GPIO、外围设备。
• M4核通过FUS或直接加载的方式启动M0+核固件：在CubeMX生成的代码里，MX_APPE_Init()会调用底层的SHCI_C2_BLE_Init，此函数会通过IPCC向M0+核发送启动命令，M0+核被唤醒后开始执行BLE协议栈固件。
• 双方通过IPCC握手：一旦M0+核的协议栈就绪，会发送一个“Ready”事件给M4核，此时应用层才能安全地调用BLE API。

这里最容易犯的错误是：在FreeRTOS调度器启动前就调用BLE初始化。我看到过一些人的代码在main()里、在osKernelStart()之前就调用了MX_APPE_Init()，导致BLE中间件内部想创建任务、使用信号量时，RTOS还没跑起来，轻则卡在初始化，重则直接HardFault。

正确做法是：在main()里只初始化硬件相关（时钟、GPIO、串口等），把MX_APPE_Init()放到一个FreeRTOS任务里去执行。CubeMX默认生成的代码就是这样做的——它会在defaultTask或专门的BLE任务里调用MX_APPE_Init()。如果因为某种原因想在调度器启动前初始化BLE，那你必须在osKernelStart()之前手动确保RTOS Heap已经可用，但我不建议这样绕，直接顺着CubeMX的默认流程走最稳。

5. 常见问题与排查技巧实录

5.1 我的“高频踩坑清单”及解决思路

以下这些问题，如果你在做BLE+FreeRTOS集成，大概率会遇到其中几个。我把排查思路一并列出来，方便你对照排查。

5.2 两个让我印象深刻的Debug实例

第一个是“BLE能连上但手机发数据后设备不响应”。我排查了很久，发现是GATT事件的回调函数没有注册到正确的Characteristic Handle上。因为我在添加服务的时候用了全局变量来保存handle，但中途改了UUID之后忘了同步handle，结果回调里拿到的handle和实际服务不匹配。最后还是用ST的“HCI事件日志”打出来，发现事件里的handle和我订阅的不一致才定位到。所以我的建议是：如果你改过服务定义，一定要回头确认handle变量的赋值是否同步。

第二个是“系统一加BLE就频繁HardFault”。后来把FreeRTOS的configCHECK_FOR_STACK_OVERFLOW打开，发现是BLE任务栈给太小了。ST中间件调用的某些函数调用链比较深，动辄需要800字节到1KB的栈空间。我之前给BLE任务只分配了512字（words）的空间，结果爆了。把栈加大到1024或1280字节后，问题消失。如果你不确定任务栈该给多大，折中方案是“先给大，稳定后再逐步调小”，用栈水位检测工具查看实际用量。

5.3 调试工具与日志策略：如何在双核环境里定位问题

BLE+FreeRTOS的调试比纯裸机复杂，因为问题可能出现在“应用逻辑层”“RTOS调度层”“双核通信层”甚至“射频协议栈层”。我的调试策略是分层打日志、逐层缩小范围，不要一上来就抓RF波形。

• 串口打印：最基础也最有效。建议在M4核的BLE任务入口打印“BLE init start”和“BLE init finish”，在事件回调里打印连接/断开事件，在业务任务里打印数据处理结果。这样你至少能判断是哪一层先出问题。
• HCI日志：ST的BLE中间件支持把M0+核和M4核之间的HCI指令/事件打印出来。这属于“协议栈内部视角”，能看到广播配置是否正确、连接事件是否成功。CubeMX里开启CFG_DEBUG_BLE或类似宏后，日志量会大幅增加，但排查问题非常有用。
• FreeRTOS系统视图（System view）或Tracealyzer：如果你需要分析任务调度、堆栈水位、优先级反转这两类问题，用这类工具比肉眼看强太多。我的经验是，把工程跑起来后先采集一段系统日志，找找有没有任务长期占着CPU不释放、有没有互斥锁长时间被持有。

6. 结尾补充一段个人体会

写到这里，我在实际项目里把BLE和FreeRTOS集成到STM32WB55RG上的经验已经基本说完了。最后想给正在折腾的朋友一个锦囊：当代码和配置都检查不出问题的时候，退回到“最小可运行工程”的状态，从最简单的“广播 + 连接 + 一读一写”开始逐步加功能。BLE协议栈和RTOS都是“状态机复杂度”很高的系统，一旦叠加，出了问题很难一眼看穿。很多我们以为的玄学Bug，最后都不是玄学，而是“某个细节配置和实际硬件状态不一致”。

再分享一个小技巧：做集成时，建议把CubeMX生成的工程单独建一个Git分支，每次改动前提交一次，每次出问题能回退到“能编译、能烧录、能跑”的状态。双核调试本身就增加了排查维度，良好的版本管理能帮你快速定位是哪一步改动引入了问题。

如果你没跑过STM32WB，也没在FreeRTOS里接过BLE中间件，第一次做不要急着直接梭哈到复杂业务。先让板子广播起来，再把你的设备和手机连上，再去动业务逻辑。这个从简到繁的过程，会帮你省下最多的调试时间。