i.MXRT新增的FlexSPI Remap功能有何作用？

大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是 i.MXRT 部分型号上新增的 FlexSPI Remap 功能。

OTA 升级设计几乎是每个量产客户都绕不开的话题，产品发布后免不了要做固件(App)升级以修复 bug 或者增加新特性。升级 App 是个麻烦事，因为处理不好，App 被破坏了导致启动不了，产品就容易变砖，变了砖即使能救回来，也非常影响用户体验。

如今基于 i.MXRT 的客户量产产品越来越多，关于 OTA 安全升级的客户支持也越来越多。早期的 i.MXRT 型号（比如 i.MXRT1050/1020/1015）在做基于 FlexSPI NOR Flash 的 OTA 升级时，有一个最大痛点即 App 版本切换不便，因此后面的 i.MXRT 型号中（比如 i.MXRT1064/1060/1010）新增了 FlexSPI 的 Remap 功能。今天痞子衡就来介绍一下这个 Remap 功能是如何用于安全 OTA 的。

一、OTA 设计中的痛点

1.1 OTA 一般设计

在讲 App 版本切换不便痛点前，先给大家简单介绍一下 OTA 升级设计过程中处理 App 版本的一般套路。下面是一个典型的 OTA 设计中 NOR Flash 里内容分布，最前面一般是 L2 OTA Boot，负责更新升级或者启动 App；接下来是主 App 区，就是真正实现产品功能的 App；然后是 Temp 区，一般用作 App 更新临时缓冲区；最后是 User Data 区，存放一些固定不变的图片资源（如果有 GUI 的话），或者放一些动态保存的系统关键数据。

这里面的 Temp 区设计是一个关键，如果没有 Temp 区，在 OTA 升级时只能原地覆盖主 App 区（App 1），升级过程中一旦发生意外（比如断电），系统里就没有完整 App 可用了，会导致产品变砖。而有了 Temp 区作缓存，升级过程就会可靠多了，如下图所示，新版本 App（App 2）首先会被放在 Temp 区，仅当 App 2 完整性校验通过之后，才会从 Temp 区搬移到主 App 区，搬移完成之后再擦除 Temp 区。这样的设计下，即使 App 2 下载到 Temp 区或者 App 2 往 App 1 搬移时发生意外，系统里都有完整 App 用于恢复。

上面介绍的处理 App 版本的典型设计在实际应用中其实不算特别常用，因为系统中仅存在一份最新的 App，其不支持版本回滚。有时候我们的新版本 App 因为一些原因（比如新增功能有 bug）导致运行并不稳定，我们希望能够回退到上一个已经运行稳定的旧版本 App，系统需要保留两份不同版本 App，所以就有了如下改进的 OTA 设计 NOR Flash 内容分布，在主 App 区（App 2）后面增加一个次 App 区（App 1）。

这时候升级过程稍微复杂一点，如下图所示，多了一步主 App 区（App 2）搬移到次 App 区（App 1）的过程(Step 2)，这也是版本回滚的关键。不过万事都是有代价的，版本回滚的代价就是增加了 OTA 升级的时间，以及将 Flash 中 App 区从两段划分成三段，导致 App 最大长度减少了 1/3。

1.2 App 版本切换痛点

前面介绍了 OTA 升级设计中管理 App 版本的两种方法，注意这里的 App 都是指在 FlexSPI NOR Flash 中原地执行(XIP)的 App，代码链接在芯片内部 SRAM 或者外扩 RAM 的 App 不在讨论范畴（这种 Non-XIP 属性的 App 升级不存在版本切换的痛点）。现在聊 XIP App 版本切换的痛点：

在上面的图中你会发现，新版本 App 最终都会被搬到主 App 区（就是紧接着 L2 OTA Boot 后面的第一个 App 位置），为什么要这么做？这就涉及 MCU 中 App 链接相关知识了，因为 MCU 不同于 MPU，其没有 MMU 组件，不支持虚拟内存，所以 App 一般都是固定地址链接，App 代码体二进制数据仅放在链接的位置才可以正常执行，将 App 拷贝到非链接位置是不能运行的。OTA 升级中虽然 App 版本不同，但是这些 App 都有一个共同的链接地址，即都是链接在主 App 区的。

比如下图 OTA 系统中使用了一块 8MB 的 Flash，在 i.MXRT 里的系统映射起始地址是 0x60000000，L2 OTA Boot 和 User Data 各占 1MB，剩余 6MB 被均分成 3 段，那么 App x/2/1 都需要从 0x60100000 地址开始链接放中断向量表。

可能你会说，我们也可以设计不同链接地址的 App，这样就不需要将新版本 App 都往主 App 区搬移了，是的，原理上可以这么做，但实践中，需要管理不同链接地址的 App，导致 OTA 升级上位机端操作比较复杂，容易出错（当前待升级的 App 必须与上一次升级的 App 链接地址不同），因此这种方法不推荐。

所以最大的痛点就是 App 总要往主 App 区搬移，既增加了 OTA 升级时间，也因为搬移操作过多减小了 Flash 的寿命（总擦写次数是一定的）。

二、详解 FlexSPI Remap 功能

2.1 FlexSPI NOR 系统映射地址

我们知道 FlexSPI 连接的 NOR Flash 能够实现 XIP，最主要的原因是 FlexSPI 有对应系统映射空间且 NOR Flash 自身可以按 Byte 地址访问，这里的系统映射空间主要用于 AHB 方式读。CPU 去从系统映射空间里读 App 指令码，FlexSPI 模块会自动将 AHB 总线传来的地址数据请求转换成 IPG 命令方式去获取 NOR Flash 里的对应指令内容。

i.MXRT1060 中分配给 FlexSPI 的系统映射空间如下，两个 FlexSPI 一共分配了 496MB。

i.MXRT1010 中分配给 FlexSPI 的系统映射空间如下，一个 FlexSPI 分配了 504MB。

2.2 FlexSPI Remap 功能设计

i.MXRT 中的 Remap 设计其实是系统架构层面的，在 AHB 总线层面做一个地址重定向，并不是在 FlexSPI 模块里实现的，这也是为什么 Remap 相关控制在 IOMUXC_GPR 寄存器里（设置后 Remap 立刻生效，但这些寄存器不是非易失性的，普通软复位就会置位）。下面是 Remap 控制寄存器（对于含两个 FlexSPI 的型号，Remap 控制是同时作用的）：

Remap 设计说起来其实特别简单，就是地址（addr）落在[ADDR_START, ADDR_END]里的 AHB 访问，其实际访问到的是 addr + ADDR_OFFSET 位置处的数据。（注意 ADDR_START, ADDR_END, ADDR_OFFSET 都是 4KB 对齐的）

举例来看，根据 ADDR_OFFSET 的大小不同，会有三种情况：第一种是 ADDR_OFFSET = ADDR_END - ADDR_START，如下图所示。这也是 OTA 中最常用的情况，ADDR_START 可设为主 App 区起始地址，ADDR_END 可设为次 App 区起始地址。

第二种是 ADDR_OFFSET > ADDR_END - ADDR_START，如下图所示：

第三种是 ADDR_OFFSET < ADDR_END - ADDR_START，如下图所示。不过这种情况在实际应用中并不推荐。

2.3 Remap 对擦写 Flash 的影响

启用了 Remap 功能后，很多人会对调用 FlexSPI NOR 驱动函数去擦写 Flash 有点疑惑。其实完全不必要有这种疑惑，擦写 Flash 操作走的是 FlexSPI IPG 命令方式，属于 FlexSPI 模块内部的事情，完全不受上层系统 Remap 功能影响，你可以就当 Remap 功能完全不存在，原来怎么做还是怎么做。

三、FlexSPI Remap 解决 OTA 痛点

有了 Remap 功能，现在再回到 OTA 设计，此时我们只需要两个 App 分区即可。新版本 App（App 2）首先会被放在后 Temp 区，App 2 更新完成且校验通过之后，直接使用 Remap 功能将 App 2 重映射到 App 1 位置，此举既不增加额外物理搬移操作，也同时保留了新旧两份 App 可以实现版本回滚，而且整个 OTA 过程仅有一次 App 擦写耗时也最短，完美解决痛点。

当 Remap 功能已被使能，再有新版本 App（App 3）更新需求时，其需要被下载到前 Temp 区，注意 Flash 擦写操作都是通过 IPG 方式实现，所以不受 Remap 功能干扰，仅需关注绝对物理地址偏移，App 下载完成，取消 Remap 功能即可，如此往复。

至此，i.MXRT 部分型号上新增的 FlexSPI Remap 功能痞子衡便介绍完毕了，掌声在哪里~~~