随着汽车电子自动化和自动驾驶技术日益普及，行业内主机厂（Car OEM）和汽车零部件供应商（Tier 1）对车内ECU (Electronic Control Unit，电控单元) Bootloader有着大量需求。并且对于研发者而言一个新功能的开发如果没有OAT或者Bootloader这将是开发过程中的一大阻碍，使得UDS（ISO14229）和TP (ISO15765-2/ISO17987-2) 被广泛的在Bootloader中使用。恩智浦为了方便用户开发，也提供了相应的文档和资料，本文就来借此机会简单聊聊关于S32K3的Bootloader/OTA方案。
图1 域OTA解决方案的体系结构

K3 Bootloader/OTA优势

说起S32K，大家第一反应肯定是如日中天的K1，不得不说K1在汽车电子中还是相当有分量的，那么新一代产品K3对比K1到底有什么优势呢？这个可以看我们连载的第一篇，里面有对于S32K3的性能概述：连载 | 带你深入了解NXP汽车通用控制器S32K3 (一)：概述篇。由于今天我们主要是来介绍OTA的我们也借这个图简单了解下两者的差异。
图2 S32K1和K3对比图

首先可以看出来，K3除了安全的提升，K3的OTA是Seamless OTA，里面特别括弧标注了（RWW，Memory remapping for A/B Swap，FW rollback option），这些标注出来的内容，相比K1还有其他品牌的MCU有什么过人之处呢？下面我们来详细看看：

* RWW，其实就是边读边写（Read While Write）。UTest扇区是S32K3中添加的另一项功能，这是一个专用的非易失性扇区，具有独立编程功能，可用于存储测试信息并支持RWW。这个功能有什么好处呢，其实在很多情况下应用程序需要在闪存中运行，同时还需要读写闪存中的数据，拿Bootloader来说，支持RWW，可以保证你在升级状态下程序还是Running的其中一个要素，目前很多车厂都有这样的新需求提出来，因为传统Bootloader为了更新代码，不得不停止应用运行来更新，这样大大降低了效率。

* Memory remapping for A/B Swap A/B双重映射。这个可以简单看下图传统bootloader和A/B双版本的方式区别，主要优势是在于传统单个固件升级如果出现了失败的情况下，由于没有一些措施，很有可能导致firmware不小心擦除或者篡改掉导致失效，这样会有一定的风险。值得一提的是K3是硬件方式实现，相比于之前软件上去做双备份版本控制，相对可靠性应该会更好些。
图3 单固件和双固件升级区别

FW rollback option 固件回滚。这个其实也是辅助于bootloader，如果出现问题，可以始终使用原始固件进行回滚，避免出现失效，这里也是硬件实现。

Bootloader原理概述

嵌入式操作系统中，Bootloader是在操作系统内核运行之前运行。可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。

一般情况下，一个完整的升级应用需要三部分：1. Boot引导程序；2. App应用程序；3. 上位机客户端；这里不谈APP和上位机，主要说下Boot引导程序。

引导加载程序分为三层：
* 引导加载程序 — 负责启动用户应用程序并轮询传入数据
* 通信处理/内存处理 — 负责处理接收到的数据并处理对非易失性存储器的写入
* 微控制器驱动程序 — 负责处理与微控制器上可用的实际外围设备之间的通信

图4 引导程序架构

图5 Bootloader 工作流程

由此可以看出，一个bootloader的开发需要对MCU 内核，中断，存储，通信，软件开发工具链，编程文件格式都需要有一定程度的掌握才可以实现。

Bootloader实现

一．如何移植修改Bootloader

对于已有的一个bootloader如果移植K3，需要做如下更改：
1. 移植修改对应堆栈。
2. 划分引导boot和app的Flash和RAM空间。
3. 将对应驱动移植到HAL（例如Flash，Time，CAN/LIN）。
4. 配置boot启动信息，主要是app地址和跳转地址信息。
5. 配置用户代码，使能对应宏和调试配置。
6. UDS服务层配置。
7. 引导加载程序放到IVT区，具体可以看RM手册 memory map，一共五个地址，这里不详细说明。
图6 存储配置

二．Bootloader和App交互
图7 bootloader和App交互图

从这个图中可以看到，K3信息交互是放到RAM里，对应有相应的标志位并且带CRC，当APP接收到指令要做更新时，会检测到标志进到bootloader，并且会清除对应标志位，同理APP也是一样。这里需要注意的是无论boot还是app，更新CRC的值一定要对，否则升级就是无效的。

三．注意要点

在引导加载程序中，应确认APP的有效性时，开机或复位。这些数据包括以下信息：

a. APP flash空间是否被擦除?
b. APP flash空间编程了吗?
c. APP数据结构是否有效?
d. 指针信息
e. CRC

此外，需要注意的还有目前Flash driver是需要代码独立的，每个函数都可以放到任何地址（只要地址对齐）。如下图
图8 实现独立Flash Driver

S32K3 OTA

OTA关键技术点

以下的这些基本上来说都是FOTA需要关注的点：

* UDS (ISO14229)服务端和客户端
* TP (ISO1765-2/CAN, ISO17987-2/LIN, ISO13400-2/DoIP, NXP private TP)
* Uptane（OTA框架）Uptane link: https://uptane.github.io/
* FFS(文件系统)
* LWIP（通信协议栈）
* RSA (HSE), SHA (HSE), AES, CRC（加密安全）

S32K3 OTA Flash特性（DCM）

K3 DCM如图会检测OTA_EN位同时也会检测OTA_Indicator_1和OTA_Indicator_2，去做判断，然后会做选择A/B哪一个block映射。
图9 K3 Flash逻辑结构

图10 DCM 判断规则

关于Indicator判断规则如下，实际这部分是直接由HSE和硬件部分来实现的，用户了解即可。
图11 Indicator判断规则

A/B OTA升级示例

下图为S32K3中OTA功能所遵循的流程示例。可分为3种情况：初始状态、更新状态和已经更新好重新映射的状态。

* 初始状态：执行代码的活动块和被删除的被动块
* 更新状态：正如我们在第二个表中看到的，在被动块中更新代码后，逻辑地址和物理地址相同
* 已经更新好重新映射的状态：在OTA指示符重置和验证后，它将物理地址重新映射到逻辑地址到活动部分。大家可以考虑下code是如何进行变化的