[Flash] TC397_SWAP机制与刷写地址详解

TC397 SWAP 机制与刷写地址详解

一、TC397 刷写对区后，为什么下次启动的地址还是原来那个

这是由英飞凌 TC397 芯片中 AB SWAP（SOTA）机制的底层地址映射原理 决定的。简单来说，"物理存储区换了，但逻辑执行地址没变"。

具体原因可以归结为以下几个核心机制：

1. 统一的逻辑起始地址

无论是处于 Standard 模式（A Bank 激活）还是 Alternate 模式（B Bank 激活），程序的执行都是从同一个固定的逻辑地址（如 0x80000000 或 0xA0000000）开始的。

当你把新程序刷写到 B Bank 并配置 UCB 切换后，芯片在下次复位时，只是把底层物理 Flash 的映射关系进行了对调。新程序所在的物理 B Bank 被映射到了这个固定的逻辑起始地址上。因此，CPU 依然从原来的逻辑地址取指执行，但实际读取到的已经是 B Bank 里的新代码。

2. 地址映射的切换由 UCB 控制

TC397 的 SWAP 切换并不是通过修改启动引脚或改变复位后的绝对入口地址来实现的，而是通过配置 UCB（User Configuration Block） 中的 SWAP 寄存器来完成的。

在刷写完成后，系统会写入新的 UCB_SWAP 配置（例如修改 MARKERL0 和 CONFIRMATIONL0 的值）。MCU 在下一次复位时，硬件会读取这个 UCB 配置，自动激活 Alternate 地址映射模式。在这个模式下，逻辑地址 0xA0000000 实际上指向了物理上的 PF2/PF3 等 B Bank 区域。

3. 单份编译代码的优势

这种设计带来了极大的工程便利：开发者只需要编译一份应用程序（其链接地址始终基于 0x80000000 或 0xA0000000），就可以同时在 A Bank 和 B Bank 中运行。系统不需要在升级时去修改代码内部所有的绝对跳转地址，彻底避免了传统 A/B 分区方案需要重复编译或动态修改地址的痛点。

总结： 下次启动的地址"看起来"还是原来那个，是因为逻辑入口地址被硬件固定了。TC397 通过 UCB 配置在幕后完成了"偷梁换柱"，让 CPU 在访问这个不变的逻辑地址时，实际指向了刚刚刷写过新程序的物理 B Bank 区域。

---

二、"只需要编译一份应用程序"的含义

这句话的核心意思是：在硬件 SWAP 机制下，应用程序的"逻辑地址"和"物理存储地址"是解耦的。

1. 传统双分区（无 SWAP）的痛点

在没有硬件 SWAP 功能的普通单片机上，如果要在 Flash 里划分 A 区和 B 区，通常的做法是：

• A 区 的物理地址是 0x80000000。
• B 区 的物理地址是 0x80400000。
• 编译时 ：开发者必须编译两份程序。A 程序的链接脚本（Linker Script）告诉编译器："你的代码放在 0x80000000"；B 程序的链接脚本必须告诉编译器："你的代码放在 0x80400000"。
• 问题 ：如果代码里有一个绝对跳转指令（比如跳转到 0x80001000），当这个程序被放在 B 区运行时，CPU 就会跳错地方，导致程序崩溃。因此，必须用不同的地址编译两份独立的二进制文件（.bin），或者使用复杂且影响性能的"位置无关代码（PIC）"。

2. TC397 SWAP 机制的"魔法"

TC397 的 SWAP 机制通过硬件层面的"地址重映射"，彻底解决了上述问题：

• 永远不变的逻辑地址 ：无论是 A 区还是 B 区，芯片复位后，CPU 永远从固定的逻辑地址（例如 0x80000000）开始取指令。
• 统一的编译标准 ：因为 CPU 视角的起始地址永远是 0x80000000，开发者在写代码和配置链接脚本时，只需要基于 0x80000000 这一套地址进行编译。
• 硬件的"偷梁换柱" ：
  • 当 SWAP 处于 Standard 模式时，硬件将物理 A Bank 映射到 0x80000000。
  • 当 SWAP 处于 Alternate 模式时，硬件将物理 B Bank 映射到 0x80000000。
• 结果：你只需要编译一份程序（.bin）。这份程序既可以刷入 A Bank，也可以刷入 B Bank。当它运行在 B Bank 时，程序内部所有的绝对跳转、内存访问，硬件都会自动"翻译"到 B Bank 的真实物理地址上，程序本身完全不需要做任何修改。

3. 一个通俗的类比

想象一家酒店有两个完全相同的仓库（物理 A Bank 和 物理 B Bank ），用来存放货物（应用程序）。

• 传统做法 ：仓库 A 的门牌号是 101，仓库 B 的门牌号是 201。你要给仓库 B 进货，必须把货物包装上的地址标签全改成 201（重新编译）。
• SWAP 做法 ：走廊尽头只有一个取货口，门牌号永远叫 101（逻辑地址 0x80000000 ）。酒店管理员手里有一把扳手（SWAP 配置）。当需要启用仓库 B 时，管理员用扳手把 101 号门背后的通道指向了仓库 B。
• 最终效果 ：你只需要准备一份地址写着"101号"的货物（只编译一份程序）。不管管理员把通道指向 A 还是 B，只要货物贴着"101"，就能被准确送到对应的仓库里运行。

总结来说，这句话的意思是：因为 TC397 的硬件会在底层自动完成物理地址的切换，开发者在软件开发阶段就"解放"了，无需再为 A/B 两个分区维护两套代码或复杂的链接脚本，极大地降低了 OTA 升级的开发和维护成本。

---

三、刷写对区时的物理地址

这是一个非常关键且容易踩坑的底层细节。在 TC397 的 SWAP 机制下，刷写（编程/擦除）地址和 CPU 执行代码的地址是完全不同的。

简单来说：CPU 执行代码看的是"逻辑地址"，而刷写（NVM操作）必须使用"绝对物理地址"。

1. 核心原则：NVM 操作无视 SWAP 映射

无论当前 MCU 处于 Standard 模式还是 Alternate 模式，也无论你最终想让 CPU 从哪个区启动，所有的 Flash 擦除和编程操作（NVM操作）都必须通过 DMU（Data Management Unit）使用物理系统地址来执行。SWAP 机制只影响 CPU 取指令时的逻辑映射，不影响底层的物理写入。

2. 刷写对区的具体物理地址

假设当前系统正在运行 A Bank（Standard 模式），你需要把新程序刷写到 B Bank。根据 TC39x 的标准物理地址映射（Standard Address Map），你需要将数据写入以下物理地址：

物理 Flash 区	物理地址范围	大小
PF2 (Physical Flash 2)	0xA0400000 ~ 0xA05FFFFF	3MB
PF3 (Physical Flash 3)	0xA0600000 ~ 0xA07FFFFF	3MB
PF5 (Physical Flash 5)	0xA0F00000 ~ 0xA0FFFFFF	1MB

A Bank 对应的物理区 PF0、PF1、PF4 的地址分别是 0xA0000000、0xA0200000、0xA0C00000。

3. 为什么会有"地址偏移"的错觉？

在实际的 Bootloader 或 OTA 接收逻辑中，为了方便处理，开发者通常会采用**"地址偏移计算"**的方式：

• 上位机或服务器下发的升级包，其内部地址依然是基于逻辑地址（如 0xA0000000 开始）的。
• Bootloader 在接收到数据后，会判断当前处于哪种模式。如果当前在 A Bank，需要写入 B Bank，Bootloader 就会在底层给接收到的逻辑地址加上 4MB 的偏移量 （例如将 0xA0000000 加上偏移变成 0xA0400000），然后再调用底层 Flash 驱动进行实际的物理写入。

4. 总结

你编译出来的程序（.bin/.hex）内部记录的地址依然是 0x80000000 或 0xA0000000 这样的逻辑地址；但在真正执行"烧写"动作时，你的刷写程序必须把数据搬运到 B Bank 对应的**真实物理地址（如 0xA0400000 起）**中。等刷写完成并配置好 UCB 重启后，硬件会自动把 0xA0000000 这个逻辑地址指向刚刚写入的 0xA0400000 物理区，程序就能无缝跑起来了。

---

四、Lauterbach dump 看到的是物理地址还是逻辑地址

在使用 Lauterbach 进行 dump 或查看内存时，看到的地址是逻辑地址（Logical Address），而不是物理地址。

1. 调试器视角的"所见即所得"

Lauterbach 等调试器是模拟 CPU 的视角来读取内存的。当 MCU 处于 SOTA（SWAP）模式时，硬件会在底层自动完成逻辑地址到物理地址的映射。因此，调试器内存窗口中显示的数据，完全遵循当前的地址映射规则（Standard 或 Alternate）。

2. 具体表现

• 当处于 Standard 模式（A Bank 激活）时 ：你在 Lauterbach 中查看逻辑地址 0xA0000000 起始的内存，看到的就是当前正在运行的 A Bank 的程序数据。此时，B Bank 所在的物理地址段（如 0xA0400000 起）在逻辑上是被隐藏或保留的。
• 当处于 Alternate 模式（B Bank 激活）时 ：硬件将 B Bank 映射到了前台。此时你在 Lauterbach 中查看同样的逻辑地址 0xA0000000，看到的数据已经是刚刚刷写进去的 B Bank 的新程序了。

3. 为什么不会看到物理地址？

因为在 SWAP 模式下，底层的物理地址（如 0xA0400000）已经被硬件控制器"屏蔽"或重定向了。调试器无法直接越过这层硬件映射去读取物理地址。只有当 NVM 操作（如擦除、编程）发生时，Flash 控制器才会在幕后使用真实的物理地址进行工作，但这对于 CPU 和调试器的常规内存读取是不可见的。

总结： 你在 Lauterbach 中 dump 出来的地址和数据，都是经过硬件 SWAP 映射后的逻辑地址。这正是 SWAP 机制的精妙之处------它对外（包括对调试器）呈现出一个永远不变的逻辑内存空间，而把底层的物理切换完全隐藏了起来。

---

五、传统双分区与 TC397 SWAP 的刷写实现对比

这两种方案的核心差异在于：传统双分区（双映射）是"软件寻址"，而 TC397 SWAP 是"硬件寻址"。这直接决定了编译和刷写流程的根本不同。

1. 为什么传统双分区需要准备两份代码？

在传统的双分区方案中，MCU 没有硬件级别的地址映射翻转功能。Flash 被硬性划分为两个区域（例如 Bank A 在 0x80000000，Bank B 在 0x80400000）。

• 绝对地址绑定的痛点 ：MCU 运行的机器码中包含大量的"绝对跳转指令"和"绝对内存访问"。如果代码在 Bank A 中运行，它跳转的目标地址是 0x80001000。如果将这份代码原封不动地复制到 Bank B 中运行，CPU 依然会去 0x80001000 取指，这会导致程序直接跑飞或崩溃。
• 两份代码的由来 ：为了让代码在两个不同的物理地址都能正确运行，开发者必须准备两份代码：
  • 方案 A（双工程） ：使用两套链接脚本（Linker Script），分别将程序的起始地址配置为 0x80000000 和 0x80400000，编译出两份独立的 .bin 文件。
  • 方案 B（位置无关代码 PIC）：编译时强制使用 PIC（Position Independent Code）技术，所有跳转都通过相对偏移或寄存器间接寻址，避免硬编码绝对地址。但这种方式在车规 MCU 上往往支持有限，且会带来性能损耗和调试困难。

2. 为什么 TC397 SWAP 只需要一份代码？

TC397 的 SWAP 机制在硬件层面实现了"逻辑地址与物理地址的解耦"。

• 统一的逻辑视角 ：无论 SWAP 处于 Standard 模式还是 Alternate 模式，CPU 永远从同一个固定的逻辑地址（如 0xA0000000）开始取指。
• 硬件自动重映射 ：当 SWAP 翻转时，硬件底层会自动将逻辑地址 0xA0000000 指向物理上的 B Bank。因为 CPU 视角的起始地址永远不变，所以内部所有的绝对跳转、中断向量表地址都保持合法。
• 一份代码走天下 ：开发者只需要基于统一的逻辑地址（0xA0000000）编写一套链接脚本，编译出唯一的一份 .bin 文件。这份文件既可以刷入 A Bank，也可以刷入 B Bank。

3. 刷写时的具体实现差异

传统双分区的刷写实现

1. 接收与判断：Bootloader 收到升级包后，判断当前运行在 A 区，决定将新固件写入 B 区。
2. 地址匹配：Bootloader 必须确认接收到的升级包是专门为 B 区编译的（或者在运行时动态修改代码中的绝对地址，这极其复杂且容易出错）。
3. 写入与校验 ：Bootloader 将数据写入 B 区的物理地址 0x80400000，校验通过后，更新启动标志位。
4. 重启 ：下次启动时，Bootloader 读取标志位，跳转到 0x80400000 执行新程序。

TC397 SWAP 的刷写实现

1. 接收与物理偏移 ：当前运行在 A Bank。Bootloader 收到基于逻辑地址 0xA0000000 的升级包。在调用底层 Flash 驱动（DMU）进行擦写时，Bootloader 会在内存中给接收到的逻辑地址加上固定的物理偏移量 （例如加上 4MB 或 6MB 的偏移），将数据真实地写入 B Bank 所在的物理地址（如 0xA0400000）。
2. 写入与校验：新固件被写入非激活的物理 B Bank。此时 A Bank 仍在正常运行，互不干扰。
3. 修改 UCB 触发 SWAP ：写入并校验成功后，Bootloader 或 App 会修改 UCB（User Configuration Block）中的 SWAP 配置（例如将 MARKERL0 从 0x55 改为 0xAA，并写入确认码 0x57B5327F）。
4. 复位与无缝切换 ：MCU 复位。硬件读取 UCB 配置，自动将逻辑地址 0xA0000000 映射到物理 B Bank。CPU 启动，直接从 0xA0000000 取指，运行的已经是 B Bank 里的新程序。整个过程无需修改任何代码内部的跳转地址。

总结：传统双分区是在"物理地址空间"里做文章，因此必须为不同的物理地址准备不同的代码；而 TC397 SWAP 是在"虚拟映射空间"里做文章，通过硬件的"偷梁换柱"，让同一份代码在不同时刻对应不同的物理存储，从而极大地简化了软件架构和刷写流程。

---

六、传统双分区中 Bootloader 的地址匹配机制

在传统双分区（无硬件 SWAP 机制）架构下，Bootloader 确认接收到的升级包是专门为 B 区编译的，通常不是通过"运行时智能识别"，而是通过**"工程编译规范 + 固件头部元数据校验"**来实现的。

1. 编译阶段的严格区分（源头控制）

这是最基础的一步。开发者在构建系统（如 Makefile 或 CMake）中，必须针对 A 区和 B 区配置不同的链接脚本（Linker Script）。

• 编译 A 区固件 ：链接地址（ROM Base）设为 0x08010000，编译生成 app_a.bin。
• 编译 B 区固件 ：链接地址设为 0x08040000，编译生成 app_b.bin。

打包工具或上位机在下发固件时，会根据目标 Slot 明确指定下发的是 app_b.bin。

2. 固件头部（Header）注入元数据（关键校验）

为了防止上位机发错包，或者在差分升级等复杂场景下出错，固件在打包时，会在二进制文件的头部（Header）注入特定的元数据。Bootloader 在擦写 Flash 之前，会解析这个头部进行校验：

• 分区标识（Slot ID） ：在固件头中写入明确的标识，例如 TARGET_SLOT = 0x0A 代表 A 区，0x0B 代表 B 区。Bootloader 读取该字段，若当前要写入 B 区但读到的是 0x0A，则直接拒绝刷写。
• 硬件兼容标识（HW Compat）：记录该固件适用的硬件版本，防止刷入不匹配的固件。
• 链接基地址（Base Address） ：部分严谨的系统会将预期的链接基地址（如 0x08040000）写入固件头。Bootloader 读取后与 B 区的实际物理地址进行比对，若不一致则报错。

3. Bootloader 的解析与校验流程

当 Bootloader 准备将数据写入 B 区时，其内部逻辑如下：

1. 接收并缓存头部：先接收固件的前几百个字节（Header 部分）。
2. 校验魔数与签名：确认这是一个合法的固件包，且未被篡改。
3. 读取目标标识 ：解析 Header 中的 TARGET_SLOT 或 Base Address 字段。
4. 逻辑匹配判断 ：
   • 如果 Header.TARGET_SLOT == SLOT_B，校验通过，Bootloader 开始擦除 B 区并将后续数据写入 0x08040000。
   • 如果 Header.TARGET_SLOT == SLOT_A，校验失败，Bootloader 返回"固件不匹配"错误码，中止刷写流程。

4. 状态机与防呆设计

在双分区系统中，Bootloader 还会结合全局的**活动分区标志（Active Bank Flag）和 分区状态（Partition Status）**进行防呆。例如，如果当前系统正处于"尝试启动 B 区"的 PENDING_VERIFY 状态，此时若收到新的升级包，Bootloader 会强制要求该升级包必须是针对 B 区的，以防止将 A 区固件错误地覆盖到正在测试的 B 区，导致系统陷入无限重启的死循环。

总结来说 ，Bootloader 并不具备"看一眼代码就知道它该在哪运行"的魔法，它完全依赖于打包时写入的元数据（分区标识/基地址）与当前待刷写目标地址之间的严格比对，以此来确保地址匹配的绝对正确。

---

七、上位机在刷写前需要知道目标分区

在传统双分区（无硬件 SWAP 机制）架构下，刷写流程确实需要上位机和 ECU 之间进行严格的"分区对齐"。

1. 上位机的"诊断与匹配"

在发起刷写前，上位机（如 4S 店的诊断仪或 OTA 服务器）必须首先与 ECU 进行通信，获取当前 ECU 的状态信息。这通常通过 UDS 诊断协议（如 0x22 读取数据服务）来实现。上位机会读取 ECU 当前的活动分区标志（Active Bank Flag）以及硬件/软件版本号。

2. 下发"专区专用"的升级包

在明确了 ECU 当前运行在哪个区（例如当前激活的是 A 区，需要升级 B 区）之后，上位机才会从服务器或本地库中，精准提取出专门为 B 区编译的固件包 （其内部链接地址指向 B 区的物理空间），并通过 UDS 协议（如 0x34 请求下载服务）下发给 ECU。

3. ECU Bootloader 的"防呆校验"

当 ECU 的 Bootloader 接收到这个升级包时，它并不是盲目地直接往 Flash 里写。它会先解析固件包头部（Header）的元数据，检查里面的 TARGET_SLOT（目标分区标识）或 Base Address（基地址）。如果发现上位机下发的包是 A 区的，但当前系统要求刷写 B 区，Bootloader 会直接拒绝写入，并返回"固件不匹配"的故障码。

4. 总结

在这种传统架构下，**"谁在运行 -> 决定刷哪个区 -> 下发对应区的包"**是一个强绑定的闭环。上位机必须具备精确的分区状态感知能力，且服务器必须妥善管理两套不同地址的固件包。这也是为什么这种传统方案在工程实现上相对繁琐，且极易因为发错包或刷错区而导致车辆"变砖"的原因。

相比之下，TC397 等支持硬件 SWAP 的芯片，由于只需要维护一份基于统一逻辑地址的固件包，就彻底省去了上位机判断"该下发哪份代码"的麻烦，极大地简化了 OTA 的云端管理和刷写逻辑。