ESP32 开发之：亚马逊 AWS 平台 OTA 升级过程完全梳理

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

文章链接在此：

物联网设备OTA软件升级之：升级包下载过程之旅

物联网设备OTA软件升级之：完全升级和增量升级

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

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

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

   
   

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

   
   

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

   
   

PS: 在下面的内容中，终端设备指的就是 ESP32 模组。
ESP32 Flash 分区
其实ESP32的官方文档的过程描述，已经是非常的详细了。

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

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

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

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

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

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

没有 OTA 的分区表：

有 OTA 功能的分区表：

官方的文档链接在这里: https://docs.espressif.com/projects/esp-idf/zh_CN/v4.3-beta3/esp32/api-guides/partition-tables.html。

既然我们是在描述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 镜像文件。

AWS 平台部署 OTA 升级任务
AWS平台按照不同的业务类型，划分为不同的服务。这样处理起来，流程更规范，操作步骤也更多，当然也更赚钱一些！

从上一篇文章中可以看到，当一个新的固件准备好之后，需要做2件事情：

1. 把固件(bin 文件)和一个固件描述文件(json格式的文本文件)，上传到 S3 云存储服务器上;

   
   

2. 在 AWS Core 任务管理中，新建一个升级任务(会得到一个 Job ID)。在这个任务中需要选择：

   
   

(1) 步骤1中上传的 json 文件;

(2) 哪些终端设备需要升级;

json格式的固件描述文档，格式大概如下(可以根据实际的业务需求进行修改)：

{
"product": "产品名称",
"group": "设备分组",
"firmware":
[
{
"ota_type": "esp32",
"url": "http://xxx/esp32-v1.1.0.bin",
"md5": "xxx"
}
]
}
不知道您是否注意到：在firmware字段中，使用的是数组([...])，而不是对象({...})？

这样来组织的原因是，OTA升级不仅仅可以对ESP32模组中的固件进行升级("ota_type": "esp32")，还可以对其他的一些固件或用户数据进行更新。

比如：更新ESP32串口连接的MCU中的固件程序。

对了，一个终端在通过网络连接到云平台时，都有一个唯一的 ID编号，一般都是利用ESP32模组上的网卡MAC地址来作为唯一ID。

当完成以上步骤时，在服务器端，就存在着一个升级任务关系链：

也就是说：一个Job ID就对应着一次OTA升级任务。终端设备在进行OTA升级过程中，就是从这个Job ID开始的。

ESP32 OTA 升级的触发
ESP32与AWS平台之间，是通过MQTT协议进行通信的。

因此，当运营人员创建了一个OTA升级任务后，所有相关的终端设备，必须从某个预先确定好的主题(topic)中，接收到OTA升级通知指令。

例如一个可能的topic：$aws/things/xxx/job/notify

其中的xxx，代表终端设备的MAC地址，只有这样，每一个设备才能够接收到属于自己的命令。

升级通知指令的内容中，一定会包含OTA升级的Job ID，例如：

{
"timestamp": "xxxxxx",
"job_id": "001"
}
当终端设备接收到这个升级通知指令时，提取出job_id字段，然后向云平台发起请求：获取与这个job_id关联的固件描述信息，也就是之前上传的Json格式的文件息。

AWS平台接收到这个请求后，就会把与这个job_id相关联的OTA升级任务描述文件(json文件)，发送给终端设备。

设备拿到了固件描述文件，自然也就知道了固件的：版本，下载地址，MD5 值等信息，于是就进入后面的下载环节了。

以上的过程描述，基本上是一个终端设备触发OTA升级的最基本的过程。

在实际的项目中，可能会遇到一些稍微复杂的情况。

例如：一个终端设备一直处于断电状态。此时，云平台中已经对固件进行了好几次的升级，但是由于这台设备一直没有运行，因此它的固件已经过时了好几个版本。

有一天，这台设备上电运行了，此时它会从云平台接收到好几个升级任务，这个时候应该如何处理呢？

也许，我们就要对升级通知的指令中，赋予更多详细的内容，让这台设备有足够的信息来判断该如何进行升级。

ESP32 固件下载和本地升级
ESP32在提取出固件的下载地址(URL)之后，就开始进入下载环节了。

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

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

链接地址：https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32/api-reference/system/ota.html

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,