📚 课程目录第3章软件开发环境搭建

3. 软件开发环境搭建：STM32CubeIDE工程创建、链接脚本配置、多核工程模板建立

好，咱们进入第三章。这一章说白了就是“搭台子”。你想想看，多核项目要是连工程模板都没弄对，后面调试低功耗的时候，光找编译错误就能把你逼疯。我这些年带团队，见过太多人上来就写代码，结果链接脚本配错了，两个核抢同一块内存，查了三天才发现——嗯，这种坑咱们今天一次性填平。

3.1 STM32CubeIDE 工程创建——别小看这一步

我个人习惯用 STM32CubeIDE 1.13 以上版本。为什么？因为对 H7 双核的支持更稳定，调试器配置也更顺手。你如果还在用 1.10 以下的版本，我建议先升级，不然有些模板选项都出不来。

创建工程的步骤其实不复杂，但有几个关键点我单独拎出来说：

选择芯片型号：比如 STM32H745XIH6，注意后缀带“H”的才是双核。我遇到过有人选了单核型号，折腾半天发现没有 CM4 的选项。
工程类型：选“STM32 Project”，不要选“Empty Project”。模板里会帮你生成初始的链接脚本和启动文件，省很多事。
TrustZone 设置：如果做低功耗项目，我建议先关掉 TrustZone。不是它不好，而是调试阶段多一层安全隔离，功耗分析会多很多干扰因素。等产品定型了再开也不迟。
双核选择：在“Pinout & Configuration”界面，你会看到两个标签页——CM7 和 CM4。每个核都要单独配置时钟、外设和中断。记住：外设归属必须在初始化阶段就定死，不能两个核同时操作同一个外设的寄存器，否则总线仲裁会把你性能拖垮。

我的小技巧：创建工程时，把 CM7 和 CM4 的工程放在同一个 Workspace 下，但用不同的文件夹命名，比如 Project_CM7 和 Project_CM4。这样调试时切换方便，链接脚本也不会互相覆盖。

3.2 链接脚本配置——多核的“交通规则”

链接脚本，说白了就是告诉编译器：你的代码放哪，数据放哪，堆栈放哪。单核项目还好说，多核项目就复杂了——两个核共享同一片物理内存，但各自有各自的地盘。

我拿 STM32H745 举个例子。它的内部 SRAM 分成好几块：

内存区域	起始地址	大小	建议归属
DTCM-RAM	0x20000000	128KB	CM7 专用（低延迟）
ITCM-RAM	0x00000000	64KB	CM7 指令缓存
SRAM1	0x30000000	256KB	CM4 主内存
SRAM2	0x30040000	128KB	共享内存（双核通信）
SRAM3	0x30060000	64KB	CM7 数据缓存

你看这个表，每个区域都有明确的归属。我曾经在一个项目里，把 CM7 的堆栈放在了 SRAM1 上，结果 CM4 跑着跑着就把堆栈踩了——那叫一个惨，复位都救不回来。后来我学乖了，每个核的链接脚本里，只声明自己该用的内存区域。

具体怎么配？以 CM7 的链接脚本为例，你需要在 .icf 文件（IAR）或 .ld 文件（GCC）里这样定义：

/* CM7 链接脚本片段 */
MEMORY
{
  DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
  ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
  SRAM3 (xrw)   : ORIGIN = 0x30060000, LENGTH = 64K
  SRAM2 (xrw)   : ORIGIN = 0x30040000, LENGTH = 128K  /* 共享区域，只声明不独占 */
}

SECTIONS
{
  .text : { *(.text*) } > ITCMRAM
  .data : { *(.data*) } > DTCMRAM
  .bss  : { *(.bss*) }  > DTCMRAM
  .shared : { *(.shared*) } > SRAM2  /* 双核通信数据段 */
}

注意：共享内存区域（SRAM2）在两个核的链接脚本里都要声明，但不要放任何自动初始化的数据。否则两个核的启动代码会互相覆盖对方的数据。我一般用 __attribute__((section(".shared"))) 手动指定变量存放位置。

3.3 多核工程模板建立——一次配好，到处复用

模板这东西，我建议你花半天时间认真搞一个。为什么？因为后面 27 章都要基于这个模板来调试。模板建得好，后面省一半时间。

我的模板结构是这样的：

根目录：存放 README、版本说明、编译脚本。
CM7_Core：CM7 的工程文件、链接脚本、启动文件、主程序。
CM4_Core：CM4 的工程文件、链接脚本、启动文件、主程序。
Common：双核共享的头文件、通信协议定义、内存映射表。
Drivers：HAL 库和 BSP 驱动，两个核共用一份。

你可能会问：为什么要分两个独立的工程文件夹？直接在一个工程里建两个 target 不行吗？嗯，我试过。调试的时候，CubeIDE 对多 target 的支持还不够成熟，经常出现断点不同步、变量监视混乱的问题。分开两个工程，每个核独立编译、独立调试，反而更清爽。

模板里还有一个关键文件——内存映射表。我把它放在 Common/memory_map.h 里：

#ifndef MEMORY_MAP_H
#define MEMORY_MAP_H

/* 双核通信邮箱地址 */
#define MAILBOX_BASE      0x30040000
#define MAILBOX_CM7_TO_CM4 (MAILBOX_BASE + 0x000)
#define MAILBOX_CM4_TO_CM7 (MAILBOX_BASE + 0x100)

/* 共享状态标志 */
#define SHARED_FLAG_BASE  0x30040200
#define FLAG_CM7_READY    (*(volatile uint32_t *)(SHARED_FLAG_BASE + 0x00))
#define FLAG_CM4_READY    (*(volatile uint32_t *)(SHARED_FLAG_BASE + 0x04))

/* 低功耗状态共享区 */
#define LP_STATE_BASE     0x30040400

#endif

这个头文件两个核都包含，保证了地址定义完全一致。我在项目里吃过亏——CM7 和 CM4 各写各的头文件，结果邮箱地址差了 4 个字节，数据死活传不过去。从那以后，共享地址必须统一管理，这是铁律。

3.4 多核启动流程与模板验证

模板建好之后，怎么验证它能不能用？我一般写一个最简单的“双核点灯”程序：

CM7 初始化后，通过邮箱发一个“启动”命令给 CM4。
CM4 收到命令后，开始闪烁 LED1。
CM7 检测到 CM4 的闪烁状态后，开始闪烁 LED2。
两个核通过共享内存互相报告自己的功耗状态。

这个流程跑通了，说明链接脚本、启动文件、通信机制都没问题。如果灯不亮，别急着查硬件——先看调试器输出，八成是链接脚本里某个段地址配错了。

下面这张图是我自己总结的多核工程模板的核心结构，你照着搭就行：

模板建立后的第一件事：把两个核的工程都编译一遍，确保零警告。然后下载到开发板，用调试器分别连接 CM7 和 CM4，观察复位顺序是否正确。CM7 先启动，然后通过硬件信号（比如 HSEM）释放 CM4 的复位——这个顺序错了，CM4 可能永远跑不起来。

嗯，这一章的内容差不多就这些。环境搭建看着琐碎，但它是后面所有调试工作的地基。你花半天把模板弄扎实了，后面遇到低功耗模式切换、核间通信延迟这些问题时，至少不会怀疑是工程配置的锅。好，咱们继续往下走。