STM32H7双核通信必须依赖HSEM硬件信号量和共享内存，不能用C++多线程机制；因无OS调度、无虚拟内存、两核物理独立，std::thread/atomic在裸机下无效且未定义。
STM32H7 的双核通信不能靠 C++ 语言特性实现，必须依赖硬件外设（HSEM 或 IPCC）和共享内存机制；C++ 只负责封装逻辑，不参与底层同步。
为什么不能直接用 C++ 多线程那一套
单片机没有操作系统调度器、没有虚拟内存、没有线程栈自动管理。Cortex-M7 和 M4 是两个物理上完全独立的 CPU，各自有独立的 PC、寄存器组、中断向量表和私有内存空间。你写一个 std::thread 或 std::atomic，编译器根本不会生成跨核同步指令——这些类在裸机环境下通常不可用或行为未定义。
常见错误现象包括：
- 变量值在 M4 上改了，M7 读出来还是旧值（Cache 不一致 + 没禁用 Cache）
- 两个核同时往同一块 SRAM 写数据，结果部分字节被覆盖（没加硬件信号量保护）
- M7 调用
printf后卡死（串口外设默认归属 M7，M4 直接访问会触发总线错误）
必须用 HSEM 硬件信号量保护共享内存
STM32H7 提供了 HSEM（Hardware Semaphore）外设，32 个独立位，每个位可被任意一核“抢占”或“释放”。这是唯一能原子级协调双核访问的硬件机制。
立即学习“C++免费学习笔记（深入）”；
实操要点：
- 共享数据必须放在明确标记为
Shareable且Non-cacheable的内存区（如SRAM4，起始地址0x38000000） - 两个核都需开启 HSEM 时钟：
__HAL_RCC_HSEM_CLK_ENABLE() - 访问前必须调用
HAL_HSEM_FastTake(HSEM_ID_0)，成功才继续；失败应重试或超时退出 - 操作完立即调用
HAL_HSEM_Release(HSEM_ID_0)，否则另一核永远等不到 - 不要在中断服务程序里长时间持有信号量——M4 的 SysTick 或 ADC 中断若占着不放，M7 可能饿死
IPCC 是 STM32MP157 的方案，H7 系列不用它
很多搜索会把 STM32MP157（A7+M4 异构）的 IPCC 教程误套到 STM32H7 上。H7 系列（H745/H747/H757）**没有 IPCC 外设**，它的核间通知靠的是 HSEM 中断 + 手动轮询标志位，或者用 OpenAMP 框架封装后的 rpmsg 接口。
如果你看到代码里有 IPCC_ClearFlag()、IPCC_RegisterNotification()，那基本是 MP157 工程，不能直接迁移到 H7。H7 上对应功能由以下组合实现：
-
HAL_HSEM_ActivateNotification()：让 M4 在收到 HSEM 释放通知时进中断 -
HAL_HSEM_FreeCallback()：M4 的回调函数，里面处理共享内存中的新数据 - 共享内存中预置一个结构体，含消息类型、长度、有效载荷指针（避免拷贝）
OpenAMP 是最省心的 C++ 封装路径
ST 官方 OpenAMP 移植（基于 libmetal + open-amp）已支持 H7 系列，它把 HSEM、共享内存布局、资源表（resource_table）初始化全包了。你可以用 C++ 封装一个 RPMsgEndpoint 类，对外暴露 send() / recv() 接口。
关键注意点：
- 资源表（
resource_table）必须放在 SRAM4 开头，并由 M7 初始化后显式告知 M4（通过HAL_HSEM_FastTake()触发） - M4 的启动镜像不能从 Flash 直接运行，必须由 M7 拷贝到
SRAM2并跳转（否则 M4 无法访问 D3 域的 SRAM4） - 所有 RPMsg 缓冲区必须分配在
Non-cacheable Shareable区域，否则 M7 写完 M4 看不到更新 - CubeMX 生成的 OpenAMP 配置默认用
FreeRTOS，若你用裸机，得手动删掉xTaskCreate相关调用，改用主循环轮询rpmsg_poll()
真正容易被忽略的是 Cache 和 MPU 配置——哪怕代码逻辑全对，只要共享内存区域没设成 Non-cacheable，数据就永远不同步。这不是 bug，是硬件行为。每次改完 MPU 设置，务必用 SCB_CleanInvalidateDCache() 清一次 D-Cache，再验证。
