📚 课程目录第3章存储器映射与分区设计

3、存储器映射与分区设计：Flash、RAM、EEPROM的地址映射，Boot区与App区的划分策略

存储器映射与分区设计是Bootloader工程化的第一块基石。无论是STM32、GD32、NXP S32K还是瑞萨RH850，MCU上电后第一条指令从哪个地址取回、中断向量表如何重定位、App升级时写Flash会不会覆盖Boot区，全部取决于芯片手册中的存储器映射表以及我们在链接脚本（Linker Script）中定义的分区边界。本章从地址映射的本质出发，深入讲解Flash、RAM、EEPROM在系统启动与运行时的角色差异，并给出Boot区与App区划分的完整策略、参数计算方法和实战案例。

3.1 存储器映射的核心原理：从芯片手册到链接脚本

MCU的存储器映射本质上是芯片设计者将CPU的地址总线空间划分为若干区域，每个区域对应一种物理存储介质或外设寄存器。以Cortex-M内核为例，4GB的地址空间被固定划分为代码区（0x0000_0000~0x1FFF_FFFF）、SRAM区（0x2000_0000~0x3FFF_FFFF）、外设区（0x4000_0000~0x5FFF_FFFF）以及系统区等。Flash通常被映射到代码区起始位置，RAM映射到SRAM区，而EEPROM可能映射到独立地址段或通过I2C/SPI外挂。理解这一映射关系是进行分区设计的前提，因为Bootloader和App本质上就是两个独立的可执行映像，它们各自拥有独立的向量表、代码段、数据段和堆栈，必须被放置在互不重叠的物理地址上。

在实际工程中，存储器映射的落地是通过链接脚本完成的。以STM32的GCC工具链为例，stm32f407_flash.ld中会定义FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K和RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K。当我们需要设计Bootloader时，不能直接修改这个原始脚本，而是要为Boot和App分别创建独立的链接脚本。Boot的Flash起始地址保持0x0800_0000不变，但长度缩减为16KB或32KB；App的Flash起始地址则变为0x0800_4000（假设Boot占16KB），长度相应减少。同时，RAM也需要划分：Boot使用低地址段（如0x2000_0000~0x2000_3FFF），App使用高地址段（0x2000_4000~0x2000_FFFF），中间预留共享区域用于传递升级标志。

核心原理总结：存储器映射是硬件层面的地址分配规则，链接脚本是软件层面的实现工具。Bootloader设计的第一步就是根据芯片Flash扇区大小、RAM容量和应用需求，在链接脚本中精确划定Boot区、App区、共享RAM区和参数存储区的边界。任何越界访问都可能导致系统崩溃或Flash内容被意外擦除。

3.2 Boot区与App区的划分策略：扇区对齐与地址偏移

划分Boot区与App区时，首要原则是扇区对齐。绝大多数MCU的Flash擦除操作以扇区（Sector）为最小单位，例如STM32F4系列的小扇区为16KB，大扇区为128KB。如果Boot区长度为20KB，但扇区大小为16KB，那么Boot实际占用两个扇区（32KB），App起始地址必须从0x0800_8000开始，而不是0x0800_5000。否则，当Boot升级自身或擦除App时，可能会误擦除Boot代码。因此，推荐的做法是：先查阅芯片参考手册中的Flash扇区表，然后选择一个合适的Boot大小（通常为16KB、32KB或64KB），确保它是扇区大小的整数倍。

第二个关键策略是中断向量表的偏移。Cortex-M内核上电后从0x0000_0000读取初始堆栈指针（MSP），从0x0000_0004读取复位向量。当Boot跳转到App时，需要将向量表重定位到App的起始地址。这通过设置SCB->VTOR = APP_START_ADDR实现。但要注意，VTOR寄存器要求偏移量按64字节对齐（部分MCU要求更高）。因此，App起始地址不仅要满足扇区对齐，还要满足VTOR对齐要求。例如，如果App起始地址为0x0801_0000，那么VTOR应设置为0x0801_0000，且该地址必须能被64整除。

分区项	起始地址	大小	内容说明
Boot区	0x0800_0000	32KB（2×16KB扇区）	Bootloader固件、固定向量表、升级驱动
App区	0x0800_8000	960KB	用户应用程序、App向量表（偏移0x8000）
参数区	0x080F_8000	16KB	升级标志、固件版本、CRC校验值
备份区（可选）	0x080F_C000	16KB	App备份，用于失败回滚
共享RAM	0x2000_3F00	256B	Boot与App通信的握手标志、命令字

除了地址划分，还需要考虑Flash写保护。在量产产品中，建议将Boot区设置为写保护，防止App在运行过程中由于指针错误或恶意攻击擦除Boot代码。STM32提供了Flash Option Bytes的WRP（Write Protection）功能，可以按扇区设置写保护。一旦使能，只有在解除保护后才能修改Boot区内容，这为系统提供了最底层的安全防线。

3.3 案例拆解：基于STM32F407的Boot/App分区实战

下面以一个实际的工业控制器项目为例，展示完整的存储器分区设计过程。该控制器使用STM32F407VET6，Flash容量512KB，RAM 128KB，需要支持通过UART进行固件升级。初始现象是：工程师直接在一个工程中编写了Boot和App代码，但跳转后系统总是进入HardFault。经过分析，发现App的链接脚本中Flash起始地址仍为0x0800_0000，导致App的向量表覆盖了Boot区，且Boot跳转时未设置VTOR。

解决过程分为四步：第一步，查阅STM32F407的Flash扇区表，确认前4个扇区各16KB，第5~12扇区各128KB。决定Boot占用前2个扇区（32KB），App从第3个扇区（0x0800_8000）开始。第二步，为Boot和App分别创建链接脚本。Boot的Flash长度设为32KB，RAM使用0x2000_0000~0x2000_3FFF（16KB）；App的Flash起始地址设为0x0800_8000，长度480KB，RAM使用0x2000_4000~0x2000_FFFF（48KB）。第三步，在Boot的跳转代码中设置VTOR并切换MSP：

/* Boot跳转App的关键代码 */
#define APP_START_ADDR  0x08008000U

void jump_to_app(void)
{
    uint32_t app_msp = *(volatile uint32_t *)APP_START_ADDR;
    void (*app_reset)(void) = (void (*)(void))(*(volatile uint32_t *)(APP_START_ADDR + 4));

    /* 关闭全局中断，防止跳转过程中断 */
    __disable_irq();

    /* 设置主堆栈指针为App的初始MSP */
    __set_MSP(app_msp);

    /* 重定位中断向量表到App区 */
    SCB->VTOR = APP_START_ADDR;

    /* 跳转到App的复位向量 */
    app_reset();

    /* 不应返回 */
    while(1);
}

第四步，在App工程中，通过__attribute__((section(".isr_vector")))确保向量表放在Flash起始位置，并在系统初始化时确认VTOR已正确设置。经过上述修改，系统跳转成功，升级功能正常。复盘时发现，最初HardFault的根因是App的向量表被放置在0x0800_0000，而该地址实际是Boot的代码区，App的堆栈指针和复位向量读取的是Boot的字节序，导致CPU执行了非法指令。

风险提示：在划分Boot与App时，务必确认App的编译链接脚本中FLASH ORIGIN已修改为App起始地址，同时检查启动文件中的__initial_sp和Reset_Handler是否被正确放置。此外，跳转前应关闭所有外设中断、停止SysTick，并将系统时钟恢复到默认状态，避免App初始化时因外设状态不一致而异常。

3.4 EEPROM与数据存储区的映射设计

EEPROM在Bootloader方案中承担着保存升级元数据、设备序列号、校准参数等关键任务。硬件上，EEPROM有两种实现方式：独立EEPROM芯片（如AT24C02，通过I2C接口访问）和Flash模拟EEPROM（利用Flash的P/E特性，通过软件算法实现字节级读写）。独立EEPROM的地址映射不占用MCU内部地址空间，而是通过I2C从机地址访问，例如AT24C02的从机地址为0xA0。这种方式的优点是读写简单、无需考虑磨损均衡，缺点是增加BOM成本和PCB面积。

Flash模拟EEPROM则是在MCU内部Flash中划出一个专用区域（例如最后16KB），通过扇区擦除和页编程实现数据更新。由于Flash擦写寿命通常为1万次（部分型号10万次），而EEPROM可达100万次，因此必须设计磨损均衡算法。一种常见策略是：将16KB区域划分为64个256字节的页，每次写入时顺序使用下一页，写满后整体擦除并重新开始。同时，在页头记录序列号和CRC，以便掉电恢复时找到最新数据。在Bootloader中，升级标志（如0xA5A5表示“有固件待升级”）和固件版本号应存放在EEPROM或Flash模拟EEPROM中，这样即使App崩溃，Boot仍能读取标志并进入恢复模式。

经验建议：对于Bootloader自身需要频繁更新的参数（如升级计数、日志），优先使用Flash模拟EEPROM并配合双备份机制。对于出厂后不再修改的校准数据，使用独立EEPROM更稳妥。无论哪种方式，都要在写入前进行CRC校验，并在写入后回读验证，防止写入过程中掉电导致数据损坏。

3.5 常见误区与总结复盘

在存储器映射与分区设计中，最常见的误区有三个。第一个误区是忽略扇区对齐，导致Boot或App的起始地址落在扇区中间，升级时擦除操作破坏相邻区域。第二个误区是RAM分区不彻底，Boot和App共用同一段RAM，跳转后App的初始化会覆盖Boot的堆栈数据，虽然通常不影响运行，但在调试时容易造成变量值异常。第三个误区是未设置Flash写保护，导致App的野指针可能擦除Boot区，使设备变砖。

总结复盘时，建议建立一张存储器映射清单，明确每个区域的起始地址、大小、用途、访问权限和擦写策略。在代码评审时，重点检查链接脚本中的ORIGIN和LENGTH是否与芯片手册一致，检查VTOR设置是否在App启动的最早期完成，检查Boot跳转前是否关闭了所有中断。此外，建议在Boot和App的编译输出中生成.map文件，并编写脚本自动检查代码段、数据段是否超出分区边界。通过这些措施，可以显著降低因存储器配置错误导致的固件升级失败率。