📚 课程目录第4章 AURIX Flash与内存布局规划

4. AURIX Flash与内存布局规划

AURIX TC3xx 的片上非易失存储并不是一整块“Flash”，而是由 PFlash、DFlash、UCB、HSM 专属区以及若干受保护配置区共同构成的层级化存储体系。OTA 升级能否安全落地，首先取决于这些区域是否被正确划分，以及链接脚本是否把代码、常量、升级缓存和 HSM 数据放到正确的物理地址上。本节以 TC375（1 MB PFlash、128 KB DFlash 的典型配置）为例，说明地址划分思路与链接脚本配置方法。

一、PFlash 与 DFlash 的物理分工

PFlash（Program Flash）用于存放可执行的代码和只读常量，按 PF0～PF5 划分为多个 Bank，每个 Bank 内部以 Sector（通常 16 KB 或 8 KB）为最小擦除单位。DFlash（Data Flash）用于存放需要频繁更新、掉电保持的数据，例如标定参数、升级状态标志、版本号、回滚计数等，其擦写寿命远高于 PFlash，适合做小粒度写入。

OTA 场景下，PFlash 通常被划分为三个逻辑区：Bootloader 区、Application 区（当前运行固件）、升级缓存区（新固件暂存）。DFlash 则承载升级元数据，例如当前激活分区、待激活分区、CRC 校验值、升级进度和回滚标志。这种“代码在 PFlash、状态在 DFlash”的分工，是后续所有地址规划的基础。

二、UCB 与 HSM 专属区的约束

UCB（User Configuration Block）是 AURIX 中用于存放芯片配置的受保护区域，包含 BMHD（Boot Mode Header）、HSM 配置、Flash 保护配置等。UCB 的写入必须通过“擦除—写入—校验”的完整流程，且每个 UCB 都有多个副本（通常 2～4 份），只有全部副本一致时配置才生效。OTA 中若需要修改启动模式或 Flash 保护策略，必须谨慎操作 UCB，否则可能导致芯片无法启动。

HSM（Hardware Security Module）专属区是独立于主核的存储与执行区域，用于存放 HSM 固件、密钥和可信根。该区域对主核不可见或仅可受限访问，OTA 升级包中的 HSM 固件更新必须通过 HSM 自身的接口完成，不能由主核直接擦写。因此，地址规划时必须为 HSM 预留固定区间，并在链接脚本中避免主核代码误入该区域。

三、链接脚本中的地址映射

在 AURIX 开发中，链接脚本（.ld 或 .lsl）负责把各个段（section）映射到物理地址。OTA 场景下，最关键的是把 Bootloader、Application 和升级缓存分别放到独立地址区间，并确保 Application 的入口地址与 Bootloader 中的跳转目标一致。

以下是一个简化的链接脚本片段示例，展示 PFlash 三个分区的映射方式：

MEMORY
{
  pflash_boot  (rx) : ORIGIN = 0xA0000000, LENGTH = 128K
  pflash_app   (rx) : ORIGIN = 0xA0020000, LENGTH = 384K
  pflash_cache (rw) : ORIGIN = 0xA0080000, LENGTH = 384K
  dflash_meta  (rw) : ORIGIN = 0xAF000000, LENGTH = 64K
}

SECTIONS
{
  .bootloader : { *(.bootloader) } > pflash_boot
  .text_app   : { *(.text*) *(.rodata*) } > pflash_app
  .upgrade_cache : { *(.upgrade_cache) } > pflash_cache
  .meta_data  : { *(.meta_data) } > dflash_meta
}

这里需要注意：升级缓存区在链接脚本中标记为 rw，因为它在运行期需要被写入新固件数据；而 Application 区标记为 rx，只读可执行。Bootloader 区独立映射，确保升级过程中不会被覆盖。

四、分区跳转与升级状态机

Bootloader 启动后，首先读取 DFlash 中的升级元数据，判断当前应跳转到 Application 区还是升级缓存区。若元数据中的“待激活标志”为有效，且升级缓存区的 CRC 校验通过，则 Bootloader 将升级缓存区的内容搬运到 Application 区，或直接跳转到缓存区执行（取决于是否支持原地执行）。搬运完成后，更新元数据，清除待激活标志，并复位重启。

这一过程的关键判断条件包括：升级缓存区首部是否有有效的固件头（包含长度、版本、CRC）、DFlash 中的激活分区索引是否指向正确、以及 Application 区的入口地址是否与链接脚本一致。任何一项不满足，Bootloader 都应回退到当前 Application 区，保证系统可启动。

建议在 DFlash 中为升级元数据保留至少两个副本，并采用“先写副本、再写主本”的顺序，避免掉电导致元数据损坏。同时，升级缓存区的大小应不小于 Application 区，以便完整暂存新固件。

五、地址规划检查要点

Bootloader 区、Application 区、升级缓存区三者地址不重叠，且均按 Sector 边界对齐。
Application 区入口地址与 Bootloader 中的跳转目标一致，通常为 Application 区起始地址 + 向量表偏移。
HSM 专属区在链接脚本中不被主核代码占用，必要时通过 MPU 设置访问权限。
UCB 操作独立于普通 Flash 擦写流程，修改前必须确认多副本一致性策略。
DFlash 元数据区预留足够空间，并考虑磨损均衡或双副本机制。

完成地址划分后，建议用调试器读取各分区起始地址的实际内容，确认 Bootloader 向量表、Application 入口和升级缓存头均位于预期位置。只有地址规划与链接脚本、Bootloader 跳转逻辑三者一致，OTA 升级才能在 AURIX 上稳定运行。