2. TRAVEO存储架构与升级映射
TRAVEO系列MCU（以CYT4BF等典型型号为例）内部采用嵌入式Flash（eFlash）作为非易失程序存储器，并配合SRAM、eFuse/OTP区域共同构成完整的存储体系。理解这套存储架构，是设计固件升级方案、规划升级地址、实现双Bank切换的前提。本节从物理分区出发，逐步过渡到升级映射与地址规划，帮助读者建立"存储—分区—升级"的完整认知链条。
一、TRAVEO Flash的物理组织
TRAVEO的eFlash通常按"Bank—Sector—Page"三级组织。以CYT4BF为例，其代码Flash容量可达4MB以上，划分为多个物理Bank（如Bank0、Bank1、Bank2等），每个Bank内部再细分为若干Sector（扇区），Sector是擦除操作的最小单位，而Page（页）是编程写入的最小单位。典型参数为：Sector大小32KB或64KB，Page大小512字节。这意味着任何一次固件更新，都必须以Sector为单位擦除、以Page为单位写入，不能像RAM那样任意字节改写。
除主Flash外，TRAVEO还包含Work Flash（工作Flash）区域，用于存放需频繁更新的数据（如标定参数、故障码、里程信息等），其擦写寿命通常高于主Flash，适合作为数据区使用。此外，SFlash（Supervisory Flash）存放出厂校准、保护设置等关键信息，一般不允许应用层随意擦写。
二、逻辑分区：Bootloader区、Application区、数据区
在工程实践中，我们不会直接把整个Flash当作一块连续空间使用，而是按功能划分为若干逻辑分区：
- Bootloader区：位于Flash起始地址（如0x80000000），存放启动代码、升级协议解析、Flash驱动、跳转逻辑。该区域在量产时烧录，升级过程中通常不被擦除，保证"永远有一个可运行的引导程序"。
- Application区：存放用户应用固件，是升级的主要目标。其起始地址、大小必须与链接脚本（Linker Script）和升级地址规划严格一致。
- 数据区：存放配置参数、标定数据、升级标志位、版本信息等。可位于Work Flash，也可在主Flash中单独划出一个Sector。
- 元数据/标志区：记录当前有效Bank、升级状态、CRC校验值、版本号等，是双Bank切换的"决策依据"。
分区规划的核心原则是：Bootloader区不可被自身升级流程擦除；Application区与升级缓存区必须物理隔离；数据区与代码区分离，避免升级时误擦数据。
三、双Bank机制与升级映射
双Bank（Dual-Bank）机制是TRAVEO支持"不停机升级"和"回滚"的关键。其基本思想是：将Application区划分为两个等大的Bank——Bank A和Bank B，同一时刻只有一个Bank被标记为"有效"并由Bootloader跳转执行，另一个Bank作为升级目标。
升级流程可概括为：Bootloader接收新固件 → 写入非活动Bank → 校验CRC/签名 → 更新元数据标志 → 复位 → Bootloader读取标志 → 跳转到新Bank。若新固件校验失败或启动异常，元数据仍指向旧Bank，实现自动回滚。
地址映射上，两个Bank的起始地址不同，但应用固件在编译时通常按"相对偏移"链接，由Bootloader在跳转前完成地址重定位（或使用MMU/MPU映射）。对于不支持地址重映射的型号，则需在链接脚本中为两个Bank分别生成两份镜像，或使用位置无关代码（PIC）。
四、升级地址规划的关键约束
地址规划不是"随便划几块"，而是受多个硬约束共同决定：
- 对齐约束：每个分区的起始地址必须按Sector大小对齐（如32KB对齐），否则擦除操作会波及相邻分区。
- 容量约束：Bank A与Bank B必须等大，且能容纳最大可能的Application镜像。若镜像接近Bank容量上限，需预留元数据区空间。
- 中断向量约束：Cortex-M内核的中断向量表默认位于Flash起始处。若Application不在0x80000000起始，需在Bootloader中重映射向量表偏移（VTOR），或在链接脚本中将向量表放到Application起始地址。
- 链接脚本一致性：Bootloader、Application A、Application B三者的链接脚本必须严格对应各自分区地址，任何一处偏移错误都会导致跳转后HardFault。
- 元数据原子性：有效Bank标志的写入必须具备原子性（如使用双字写入+CRC保护），防止掉电导致标志损坏、系统无法启动。
五、一个可参考的地址规划示例
以下给出一个基于CYT4BF、4MB主Flash的示例规划（仅作教学参考，实际项目需根据芯片手册和镜像大小调整）：
| 分区 | 起始地址 | 结束地址 | 大小 | 用途 |
|---|---|---|---|---|
| Bootloader | 0x80000000 | 0x8001FFFF | 128KB | 启动、升级协议、Flash驱动 |
| Bank A | 0x80020000 | 0x8011FFFF | 1MB | Application 镜像 A |
| Bank B | 0x80120000 | 0x8021FFFF | 1MB | Application 镜像 B |
| 元数据区 | 0x80220000 | 0x8022FFFF | 64KB | 版本、CRC、有效Bank标志 |
| 数据区 | 0x80230000 | 0x8023FFFF | 64KB | 标定参数、故障码 |
该规划中，Bootloader区固定不动，Bank A/B等大且对齐，元数据区独立于两个Bank之外，避免升级时被误擦。实际项目中，若Application镜像超过1MB，需相应扩大Bank容量或压缩固件；若使用Work Flash存放数据，则数据区可移至Work Flash地址空间，进一步降低主Flash擦写压力。
总结来说，TRAVEO存储架构与升级映射的核心在于：物理上按Bank/Sector/Page组织，逻辑上按Bootloader/Application/Data分区，升级上按双Bank切换与元数据决策。只有把这三层关系理清，才能在后续的升级协议设计、Flash驱动实现和版本治理中做到地址不冲突、跳转不跑飞、回滚有依据。