物联网中常用的ota升级方案

说明

在进行物联网开发的过程中，免不了进行ota升级，那么如何做好ota升级又是非常值得思考的问题。

下面从实际应用案例中，剖析一下ota升级的方案。

方案1

最简单的OTA升级，flash布局如下：

其升级的方案是，每个APP的尾部都会记录如下的相关信息，可以作为跳转的标志。

所以可以这样理解，APP0作为运行分区，APP1作为升级分区，当升级分区的标志置位时，将升级分区的代码放到运行分区中执行。

每次都只会跳转到APP0去执行代码。

优点：

该方案设计比较简单，资源占用小。

缺点：

如果升级的过程中出现错误，而校验又没有检测到，则会导致程序起不来。需要加强校验机制，也需要确保下载代码完全的准确性。

也可能在升级之后，出现联网模块不能使用，导致需要去现场解决，这种问题发生后非常严重。

方案2

方案1会存在可能起不来的风险，这时需要去现场进行程序烧录，成本很大。所以第二种是差分升级。

当APP0运行时，将升级的程序放到APP1中，下次BOOT跳转从APP1地址去运行程序。

当APP1运行时，将升级的程序放到APP0中，下次BOOT跳转从APP0地址去运行程序。

这样可以解决一个问题，当模块升级后连接不了网络的问题。如果连接网络失败，可以将失败的原因放到备份SRAM中，多次连接不上，BOOT检测到这个现象，可以跳转到另外一个可以运行的程序进行降级运行。因为两个可以运行的程序没有被破坏。

但是这个问题解决不了由于程序传输错误导致的程序启动不了的问题。

方案3

我曾经也在实际项目中用到过另外OTA方案，如下设计：

该设计的核心在于BOOT中集成联网模块功能，当BOOT下载时，首先会置位相关的标志位。

其设计上采用BOOT主要用于下载功能，当程序运行APP时，需要升级时，会首先将config的标志位置位，然后跳转到BOOT中进行升级，将代码永远放到APP_BAK中，升级完成后，可以校验通过后，将APP_BAK的代码拷贝到APP中，然后再运行APP区代码。

最后一切功能没问题后，再将config设置成正常状态，否则每次boot启动后都会进行OTA请求。

优点：

程序功能可靠有保障，减少可能起不来的风险

缺点：

由于BOOT中集成了比较多的功能，比较复杂，当替换联网模块时，BOOT和APP的代码需要同步修改。

方案4

rt-thread官网上有一种OTA的方案，具体实现如下：

分区名	起始地址	分区大小	分区位置	介绍
app	自定义	自定义	片内 Flash	存储 app 固件
download	自定义	自定义	片内 Flash 或者片外 SPI Flash	存储待升级固件
factory	自定义	自定义	片内 Flash 或者片外 SPI Flash	存储出厂固件
boot	--	--	--	boot固件

流程图如下：

解释一下factory分区的实际应用场景。

由于差分升级或者普通的BOOT升级方案都会存在系统启动不了的可能性，所以增加了一个一定可以启动的固件。具体的使用是需要boot中检测一个硬件IO，当该IO被长时间按下后，会进入出厂程序设置。这样减少了设备出问题后，技术人员需要现场升级的烦恼，即使不懂技术的人也能够按下按键进行复位。

优点：

消除设备启动不了的问题，减少程序下载失败的风险

缺点：

资源消耗太大，三个固件起码需要外挂SPI flash才能设计的比较好，完全利用内部flash，资源有点紧张。