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

在最近的两篇文章中，我们从概念和流程上梳理了： 一个终端设备如何把一个固件，安全无误的从服务器上，下载到本地。

这篇文章就继续往下深入，以一个实际的 ESP32 项目，来完整的梳理一下 OTA 升级的全过程。

主要包括下面 3 部分内容：

AWS 平台上，部署一个 OTA 升级任务时，需要完成哪些步骤；

ESP32 模组中，关于 Flash 分区和 OTA 升级控制过程和代码说明；

如何通过 ESP32，给与之相连的 MCU 进行 OTA 升级；

PS： 在下面的内容中，终端设备指的就是 ESP32 模组。

ESP32 Flash 分区

其实 ESP32 的官方文档的过程描述，已经是非常的详细了。

不仅把每一个操作的步骤都写的很清楚，而且把一些可能遇到的错误，都会做一些善意的提醒。

下面这部分内容，基本上是来源于官方的文档。

我们这里只是把一些与本文相关的、比较重要的内容摘录在这里。

首先要了解的，肯定是 Flash 的分区信息了。

所有的固件、数据，都要存储在 Flash 中，它是一个系统的记忆部件，离开了它，再怎么聪明的 CPU 都无用武之地。

关于分区表，ESP32 中预定义了 2 份分区表，分别对应：是否存在 OTA 功能这两种情况，截图如下：

没有 OTA 的分区表：

有 OTA 功能的分区表：

既然我们是在描述 OTA 过程，那肯定就是以带有 OTA 功能的这个分区表为准了。

在这张分区表中，一共定义了 3 个应用程序分区：

factory 分区；

ota＿0 分区；

ota＿1 分区；

这三个分区的类型都是 app，但具体 app 的类型不相同。

其中，位于 0x10000 偏移地址处的为出厂应用程序（factory），其余两个为 OTA 应用程序（ota＿0，ota＿1）。

名为 otadata 的数据分区，用于保存 OTA 升级时需要的数据。

启动加载器会查询该分区（otadata）的数据，以判断：应该从哪个 OTA 应用程序分区来加载程序。

如果 otadata 分区为空（说明这台设备还没有进行过 OTA 升级），则会执行出厂程序，也就是执行 factory 分区中的固件程序。

如果 otadata 分区非空，则启动加载器将加载这个分区中的数据，进而判断： 启动哪个 OTA 镜像文件。