NXP实战笔记（十六）：NXP 32K3xx系列单片机有关OTA升级的思考

1、概述

2、参考资料

3、思考点1：需不需要传统BootLoader？

3.1、无需传统BootLoader

3.2、有传统BootLoader

4、OTA升级之后是否立即实施切换

5、兼容编程会话

6、APP内部集成34、36、37服务

7、Flash放置问题

1、概述

NXP的S32K3系列单片机通过HSE（硬件安全引擎）的ABSWAP功能实现OTA（Over-The-Air）升级，是一种确保固件更新过程安全可靠的方法。

HSE（硬件安全引擎）：HSE是NXP S32K3系列单片机中的一个安全特性，它提供加密、安全启动和密钥存储等安全功能，符合ISO26262标准，达到ASIL D安全等级。HSE支持多种加密算法，包括AES、RSA和ECC，确保数据传输和存储的安全性。此外，HSE还支持无线固件更新（FOTA），允许MCU接收和安装新的固件，而不影响系统的正常运行。

ABSWAP功能：ABSWAP是HSE提供的固件更新机制之一，它支持双分区功能，允许在不同的闪存区域中存储两个固件版本。这样可以在更新过程中切换到新的固件版本，而不影响当前运行的固件。这对于需要进行无线固件更新（FOTA）的应用来说非常有用。ABSWAP方式支持OTA升级，意味着在更新固件时，单片机可以继续执行其他任务，而不会中断服务。

OTA升级实现过程：

安装HSE FW：首先需要安装HSE固件（HSE FW），这通常需要使能firmware feature flag，并使用编程器直接烧录加密映像文件或使用特定工具进行安装。

分区与更新：在安装HSE FW后，系统会将闪存划分为激活区和未激活区。固件更新时，新的固件会被写入未激活区。一旦新固件验证无误，系统会通过ABSWAP机制切换到新的固件分区，使新固件生效，而旧固件则成为未激活区，准备下一次更新。

安全特性：HSE提供的安全特性确保了整个OTA升级过程的安全性。例如，使用加密算法保护固件传输过程，防止未授权访问和篡改。同时，HSE还支持安全启动，确保系统启动时加载的固件是经过验证的，未被篡改。

正文开始不废话：

首先没用到安全启动

2、参考资料

NXP实现OTA升级，简单的一句话，需要进行大量的代码实践及资料查询，资料非常重要，下面看下都用到了哪些资料。

资料	描述	来源
HSE_FW_S32K3xx_0_2_40_0.zip	HSE的固件及API描述文件。	官网下载
an744810+-+HSE+FW+install+for+S32K3xx+(1.0).pdf	HSE的大致描述	官网下载
RM758223-HSE-B+Firmware+Reference+Manual+-+V2.3(2.3) 非常重要的文档	HSE原理、安装、实现细节文档	找官方FAE要，签了NDA协议才会发。
https://community.nxp.com/	NXP技术论坛，实用资料很多	NXP社区网址
SW32K3_OTADEMO_0.8.0	OTA的Demo	官网下载

3、思考点1：需不需要传统BootLoader？

3.1、无需传统BootLoader

为什么会有这个问题呢？OTA程序本身集成了BootLoader功能，本质上讲APP程序具备了BootLoader的一切功能。再做一个boot是否显得多余了？

没有BootLoader的OTA内存划分如下图。（NXP S32K312为例子）

首次下载需要将 Active PartitionAPP与Passive Partition APP均下载进去，不然无法切换。一切就死机了。

思考一下：这个时候是不是需要做个操作，在OTA升级写PFx的时候，写一个OTA有效标志位，当标志位有效才让切，否则不给切，防止死机。

这个地方需要操作HEX的合并，S32DS编译器可以合并bin文件的，通过链接文件编译之后自动就生成了。

合并多个bin的方式，S32DS编译器可以实现的，参考HSE的固件安装程序链接文件语法。

TARGET(binary) 
INPUT (C:\NXP\HSE_FW_S32K3XX_0_1_2_1\hse_full_mem\hse\bin\s32k3x2_hse_fw_0.13.0_1.2.1_pb220205.bin.pink)
OUTPUT_FORMAT(default).hse_bin :{. = ALIGN (0x4);__hse_bin_start__ = .;C:\NXP\HSE_FW_S32K3XX_0_1_2_1\hse_full_mem\hse\bin\s32k3x2_hse_fw_0.13.0_1.2.1_pb220205.bin.pink (.data). = ALIGN (0x4);__hse_bin_end__ = .;} > HSE_BINARY    __HSE_BIN_START = ORIGIN(HSE_BINARY);__HSE_BIN_SIZE = __hse_bin_end__ - __hse_bin_start__;

看上去其实也行，这种方式实现上也行，一种选择吧。个人而言是通过下面这种实现的。

3.2、有传统BootLoader

有传统BootLoader内存分配如下

可以看到，多了传统Boot，多了应用有效标志位，内存划分更细致。

操作的时候当一个白板控制器拿到手里之后，首先安装HSE（安装之后断电两次间隔2S以上），后面需要将整个PF0与PF1的下图六部分下载到控制器中。

注意点：（Active Partition BootLoader）、（Active APP Valid Flag）、（Passive Partition BootLoader）、（Passive APP Valid Flag）、（Active Partition BootLoader）、（Passive Partition APP）在合并bin文件的时候不能偷懒，相同内容的bin文件不能省略下面链接文件代码为一个。

TARGET(binary) 
INPUT (xxx.bin)
OUTPUT_FORMAT(default)

应用有效标志位的bin文件可以通过J-Flash生成，boot与APP的bin文件可以直接通过S32DS生成。

推荐一种S32DS自带的生成bin方式。

填入的描述语言如下：

arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.s19";arm-none-eabi-objcopy -v -O ihex "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.hex";arm-none-eabi-objcopy -v -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"
或着
arm-none-eabi-objcopy -O srec ${ProjName}.elf ${ProjName}.s19;arm-none-eabi-objcopy -O ihex ${ProjName}.elf ${ProjName}.hex;arm-none-eabi-objcopy -O binary ${ProjName}.elf ${ProjName}.bin;

目前项目实现上还是选择要传统BootLoader了，因为在大部分时候市场调试人员升级直接按照以前的习惯就行，另外在BootLoader里面加入了防刷死机制，即使有什么问题，也可以拯救回来，如何设计防刷死方案，之前的文章中有描述。

4、OTA升级之后是否立即实施切换

程序的执行一直在PF0里面的，并且通过OTA升级到PF1，什么时候升级呢？时间点在哪里，这更多的是需求问题。

通过HSE操作可以实现在跑车过程中升级的，但是跑车过程中程序是禁止复位的，复位就是事故了，所以此时激活OTA的过程理论上在安全状态下通过31例程服务会好一些。

31例程服务也有选择，应不应该在31执行的时候进行复位还是只是执行切换动作，到11服务的时候再进行复位自动切换。

5、兼容编程会话

存在传统bootLoader的方案里面，本地升级需要用到10 02写重编程标志位，此段数据一般在RAM区域，然后进行复位跳转到Boot进行升级，但是在OTA升级的时候怎么进入编程会话之后不复位进行升级呢？

第一种方式：通过31服务执行OTA升级请求，此时置位一个OTA升级请求标志位，后面执行10 02的时候判断标志位再看复位不复位。

第二种方式：10会话控制是可以自定义会话控制模式的，例如常用的10 60 定义为OTA会话，在OTA会话模式下进行OTA升级即可。

6、APP内部集成34、36、37服务

通过OTA升级的时候，因为有需求在车辆运行过程中进行升级，所以APP内部需要集成34、36、37服务，FF00擦除服务也是需要的，但是擦除服务会占用大量时间，在擦除服务的时候，我是把WDG时间给加大的，再发送78的同时防止复位，这个时候有一个注意点，擦除的地址信息不能包含HSE与SBAF区域否则会擦除失败的。