ESP32 固件下载和本地升级

ESP32 在提取出固件的下载地址（URL）之后，就开始进入下载环节了。

官方文档非常详细的描述了固件的下载过程。

下面这段代码，就是从官方文档中摘抄过来的：

bool image＿header＿was＿checked ＝ false；
while （1） ｛
   int data＿read ＝ esp＿http＿client＿read（client， ota＿write＿data， BUFFSIZE）；
   ．．．
   if （data＿read ＞ 0） ｛
       if （image＿header＿was＿checked ＝＝ false） ｛
           esp＿app＿desc＿t new＿app＿info；
           if （data＿read ＞ sizeof（esp＿image＿header＿t） ＋ sizeof（esp＿image＿segment＿header＿t） ＋ sizeof（esp＿app＿desc＿t）） ｛
               ／／ check current version with downloading
               if （esp＿efuse＿check＿secure＿version（new＿app＿info．secure＿version） ＝＝ false） ｛
                   ESP＿LOGE（TAG， ＂This a new app can not be downloaded due to a secure version is lower than stored in efuse．＂）；
                   http＿cleanup（client）；
                   task＿fatal＿error（）；
               ｝
               image＿header＿was＿checked ＝ true；
               esp＿ota＿begin（update＿partition， OTA＿SIZE＿UNKNOWN， ＆update＿handle）；
           ｝
       ｝
       esp＿ota＿write（ update＿handle， （const void ＊）ota＿write＿data， data＿read）；
   ｝
｝

把这个过程画成流程图，就是下面这个样子：

我们假设这次固件升级，存储在 ota＿0 这个分区中。

在固件下载完毕之后，esp＿ota＿end（） 函数会在 otadata 分区写入一个标记： 下次启动时，请加载 ota＿0 分区中的固件程序。

当 ESP32 重新启动时，启动加载器从 otadata 分区读取数据，得知这一次需要启动 ota＿0 分区里的固件。

此时有一件很重要的事情需要做：当 ota＿0 分区中的固件启动正确无误后，需要调用函数 esp＿ota＿mark＿app＿valid＿cancel＿rollback（） 往 otadata 区写 ESP＿OTA＿IMG＿VALID，标记： 这个分区中的固件是没有问题的！

这样的话，以后每次重启时，都会加载 ota＿0 分区里的固件。

相反的情况：如果 ota＿0 分区里的固件，在第一次启动后新固件运行有问题，需要调用函数 esp＿ota＿mark＿app＿invalid＿rollback＿and＿reboot（） 往 otadata 区写 ESP＿OTA＿IMG＿INVALID ，标记：这个分区中的固件有问题！

这样的话，重启之后，启动加载器将会选择之前的 app 分区里的固件，可能是 factory 分区，也可能是 ota＿1 分区。

OTA 升级过程中断了，怎么办？

以上描述的过程都是理想的情况，那么如果遇到一些异常情况，该如何处理呢？

例如：从接收到固件描述信息，到固件下载完成。在这期间的任何一个时间点，如果因为断电等原因，导致设备重启了，该如何继续 OTA 升级过程？

我们知道，在程序运行的时候，所有的数据都是保存在内存中的。

重启之后，内存中的数据是一篇空白。

如果希望 OTA 升级过程可以在任何异常情况下都能顺利进行，必须保存一些必要的信息，包括：

json 格式的固件描述文件；

固件下载过程中已经完成的每一个阶段；

这些信息可以调用 nvs＿write（） 函数，保存在非易失性存储设备中。

即使系统因为断电等原因重启了，也可以通过 nvs＿read（） 函数，读取之前已经完成的步骤，然后继续后续的升级操作。

通过 ESP32，升级 MCU 固件

ESP32 模组，仅仅是一个用来连接网络云平台的无线设备。

对于一个实际的产品而言，发挥实际功能控制作用的，往往是另一片单片机，比如： STM32。

单片机中的固件也有可能需要进行 OTA 升级，此时 ESP32 就要作为中间的一个媒介，先把 MCU 固件下载下来存储在本地，然后再通过串口发送给单片机。

在这种情况下，ESP32 接收到的 OTA 固件描述信息就有可能是下面这个样子：

｛
 ＂product＂： ＂产品名称＂，
 ＂group＂： ＂设备分组＂，
 ＂firmware＂：
 ［
    ｛
       ＂ota＿type＂： ＂stm32＂，
       ＂url＂： ＂http：／／xxx／mcu－v1．2．3．bin＂，
       ＂md5＂： ＂xxx＂
    ｝
 ］
｝

从 ota＿type 字段，可以知道这次是给 MCU 进行升级，接下来的下载过程就与上述流程很类似了。

唯一的区别就是：下载的时候，需要把固件保存到 Flash 上的一块独立的数据分区中，而不是 ota＿0 或 ota＿1 分区。

－－－－－－ End －－－－－－

至此，关于 ESP32 模组以及 MCU 的 OTA 升级过程就基本描述完毕了。

以上这些内容，都是是一些结构性的流程节点，剩下部分就是一些细节问题了，按照官方文档的指导步骤，都可以顺利完成开发！