第2章 STM32WB双核架构深度解析：M4内核与M0+内核分工、核间通信与共享资源管理

做低功耗蓝牙项目，选STM32WB是个很自然的选择。但说实话，我第一次拿到这颗芯片的数据手册时，也被它的双核架构搞得有点懵——一个M4跑应用，一个M0+跑蓝牙协议栈，两个核怎么配合？谁管谁？

这一章，我就把STM32WB的双核架构掰开揉碎了讲清楚。你搞懂了这些，后面做性能调优才能有的放矢。

2.1 双核分工：M4与M0+各管一摊

STM32WB内部有两个ARM内核：一个Cortex-M4，一个Cortex-M0+。它们不是主从关系，而是各司其职的搭档。

内核	主频	主要职责	我常用的场景
Cortex-M4	64 MHz	应用代码、传感器驱动、数据处理、用户交互	跑FreeRTOS、处理传感器数据、控制外设
Cortex-M0+	32 MHz	BLE协议栈、射频控制、链路层管理	跑ST的蓝牙协议栈，用户基本不用碰

M4是主角，负责你的业务逻辑。M0+是配角，专职处理蓝牙通信。我习惯把M0+看作一个“蓝牙协处理器”——你给它指令，它帮你把数据发出去，收回来。

2.2 核间通信：IPCC与Mailbox

两个核各干各的，但总得有个沟通渠道。STM32WB提供了两套机制：IPCC（核间通信外设）和Mailbox（邮箱）。

IPCC是硬件层面的中断通道。一个核写寄存器，另一个核收到中断。说白了就是“你拍我一下，我有事跟你说”。

Mailbox是共享内存区，用来传递实际数据。IPCC负责通知，Mailbox负责内容。

通信流程大致是这样的：

1. M4把命令写入Mailbox（共享内存区）
2. M4通过IPCC发中断给M0+
3. M0+收到中断，从Mailbox读取命令
4. M0+执行命令（比如开启广播、建立连接）
5. M0+把结果写回Mailbox，再通过IPCC通知M4

你看，整个过程是异步的。M4发完命令就可以干别的，不用死等M0+回复。

2.3 内存映射与共享资源管理

双核架构最头疼的就是内存怎么分。STM32WB的SRAM分成了几个区域：

内存区域	大小	归属	用途
SRAM1	192 KB	M4独占	应用堆栈、全局变量、FreeRTOS堆
SRAM2	64 KB	M0+独占	蓝牙协议栈、GATT数据库
SRAM3	16 KB	共享	Mailbox、核间数据交换

SRAM1和SRAM2是各自私有的，互不干扰。SRAM3是共享的，两个核都能读写。Mailbox就放在SRAM3里。

这里有个坑：共享资源的访问冲突。两个核同时写SRAM3的同一个地址，数据就乱了。ST提供了硬件信号量（HSEM）来解决这个问题。

HSEM的使用很简单：

// M4侧：获取信号量
while (LL_HSEM_1StepLock(HSEM, 0) != HSEM_LOCK_OK);
// 访问共享内存
shared_data->flag = 1;
// 释放信号量
LL_HSEM_ReleaseLock(HSEM, 0, 0);

M0+侧的操作类似，只是信号量ID要一致。

2.4 双核架构知识图谱

下面这张图把整个双核架构的关系梳理清楚了。我建议你把它存下来，做项目时对照着看。

2.5 实际项目中的注意事项

说了这么多理论，我总结几个实际项目中容易踩的坑：

• M4不要直接访问M0+的私有外设——比如RF寄存器、BLE定时器。我见过有人试图在M4里配置蓝牙广播参数，结果M0+那边直接崩溃。
• Mailbox数据格式要固定——M4和M0+对同一块内存的理解必须一致。我习惯用结构体定义，两边包含同一个头文件。
• IPCC中断服务要快——M0+的IPCC中断优先级很高，处理时间长了会影响蓝牙收发包。我一般只在中断里设置标志位，具体处理放到任务里。
• 共享内存不要放大量数据——SRAM3只有16 KB，而且两个核都要访问。大数据传输建议用DMA + 乒乓缓冲，别直接往Mailbox里塞。