OTA升级中App切换痛点是什么

本篇文章给大家分享的是有关OTA升级中App切换痛点是什么,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。

成都创新互联始终坚持【策划先行,效果至上】的经营理念,通过多达10年累计超上千家客户的网站建设总结了一套系统有效的全网营销解决方案,现已广泛运用于各行各业的客户,其中包括:成都楼梯护栏等企业,备受客户赞扬。

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的话),或者放一些动态保存的系统关键数据。

OTA升级中App切换痛点是什么  

这里面的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用于恢复。

OTA升级中App切换痛点是什么  

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

OTA升级中App切换痛点是什么  

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

OTA升级中App切换痛点是什么  
 
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地址开始链接放中断向量表。

OTA升级中App切换痛点是什么  

可能你会说,我们也可以设计不同链接地址的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里的对应指令内容。更多原理可参看 《在串行NOR Flash XIP调试原理》。

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

OTA升级中App切换痛点是什么  

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

OTA升级中App切换痛点是什么  
 
2.2 FlexSPI Remap功能设计

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

Remap功能对应控制寄存器
i.MXRT106xi.MXRT1010
ADDR_STARTIOMUXC_GPR_GPR30IOMUXC_GPR_GPR27
ADDR_ENDIOMUXC_GPR_GPR31IOMUXC_GPR_GPR28
ADDR_OFFSETIOMUXC_GPR_GPR32IOMUXC_GPR_GPR29

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区起始地址。

OTA升级中App切换痛点是什么  

第二种是ADDR_OFFSET > ADDR_END - ADDR_START,如下图所示:

OTA升级中App切换痛点是什么  

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

OTA升级中App切换痛点是什么  
 
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功能即可,如此往复。

OTA升级中App切换痛点是什么    

以上就是OTA升级中App切换痛点是什么,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。


网站题目:OTA升级中App切换痛点是什么
标题URL:http://myzitong.com/article/jpideg.html