在最近的兩篇文章中，我們從概念和流程上梳理了: 一個(gè)終端設(shè)備如何把一個(gè)固件，安全無誤的從服務(wù)器上，下載到本地。

文章鏈接在此：

物聯(lián)網(wǎng)設(shè)備OTA軟件升級(jí)之：升級(jí)包下載過程之旅

物聯(lián)網(wǎng)設(shè)備OTA軟件升級(jí)之：完全升級(jí)和增量升級(jí)

這篇文章就繼續(xù)往下深入，以一個(gè)實(shí)際的ESP32項(xiàng)目，來完整的梳理一下OTA升級(jí)的全過程。

主要包括下面3部分內(nèi)容：

1. AWS 平臺(tái)上，部署一個(gè) OTA 升級(jí)任務(wù)時(shí)，需要完成哪些步驟;

   
   

2. ESP32 模組中，關(guān)于 Flash 分區(qū)和 OTA 升級(jí)控制過程和代碼說明;

   
   

3. 如何通過 ESP32，給與之相連的 MCU 進(jìn)行 OTA 升級(jí);

   
   

PS: 在下面的內(nèi)容中，終端設(shè)備指的就是 ESP32 模組。
ESP32 Flash 分區(qū)
其實(shí)ESP32的官方文檔的過程描述，已經(jīng)是非常的詳細(xì)了。

不僅把每一個(gè)操作的步驟都寫的很清楚，而且把一些可能遇到的錯(cuò)誤，都會(huì)做一些善意的提醒。

下面這部分內(nèi)容，基本上是來源于官方的文檔。

我們這里只是把一些與本文相關(guān)的、比較重要的內(nèi)容摘錄在這里。

首先要了解的，肯定是Flash的分區(qū)信息了。

所有的固件、數(shù)據(jù)，都要存儲(chǔ)在Flash中，它是一個(gè)系統(tǒng)的記憶部件，離開了它，再怎么聰明的CPU都無用武之地。

關(guān)于分區(qū)表，ESP32中預(yù)定義了2份分區(qū)表，分別對(duì)應(yīng)：是否存在 OTA 功能這兩種情況，截圖如下：

沒有 OTA 的分區(qū)表：

有 OTA 功能的分區(qū)表：

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

既然我們是在描述OTA過程，那肯定就是以帶有OTA功能的這個(gè)分區(qū)表為準(zhǔn)了。

在這張分區(qū)表中，一共定義了3個(gè)應(yīng)用程序分區(qū)：

factory 分區(qū);
ota_0 分區(qū);
ota_1 分區(qū);

這三個(gè)分區(qū)的類型都是app，但具體app的類型不相同。

其中，位于0x10000偏移地址處的為出廠應(yīng)用程序（factory），其余兩個(gè)為OTA應(yīng)用程序（ota_0，ota_1）。

名為otadata的數(shù)據(jù)分區(qū)，用于保存OTA升級(jí)時(shí)需要的數(shù)據(jù)。

啟動(dòng)加載器會(huì)查詢?cè)摲謪^(qū)(otadata)的數(shù)據(jù)，以判斷：應(yīng)該從哪個(gè)OTA應(yīng)用程序分區(qū)來加載程序。

如果otadata分區(qū)為空(說明這臺(tái)設(shè)備還沒有進(jìn)行過OTA升級(jí))，則會(huì)執(zhí)行出廠程序，也就是執(zhí)行factory分區(qū)中的固件程序。

如果otadata分區(qū)非空，則啟動(dòng)加載器將加載這個(gè)分區(qū)中的數(shù)據(jù)，進(jìn)而判斷: 啟動(dòng)哪個(gè) OTA 鏡像文件。

AWS 平臺(tái)部署 OTA 升級(jí)任務(wù)
AWS平臺(tái)按照不同的業(yè)務(wù)類型，劃分為不同的服務(wù)。這樣處理起來，流程更規(guī)范，操作步驟也更多，當(dāng)然也更賺錢一些！

從上一篇文章中可以看到，當(dāng)一個(gè)新的固件準(zhǔn)備好之后，需要做2件事情：

1. 把固件(bin 文件)和一個(gè)固件描述文件(json格式的文本文件)，上傳到 S3 云存儲(chǔ)服務(wù)器上;

   
   

2. 在 AWS Core 任務(wù)管理中，新建一個(gè)升級(jí)任務(wù)(會(huì)得到一個(gè) Job ID)。在這個(gè)任務(wù)中需要選擇：

   
   

(1) 步驟1中上傳的 json 文件;

(2) 哪些終端設(shè)備需要升級(jí);

json格式的固件描述文檔，格式大概如下(可以根據(jù)實(shí)際的業(yè)務(wù)需求進(jìn)行修改)：

{
"product": "產(chǎn)品名稱",
"group": "設(shè)備分組",
"firmware":
[
{
"ota_type": "esp32",
"url": "http://xxx/esp32-v1.1.0.bin",
"md5": "xxx"
}
]
}
不知道您是否注意到：在firmware字段中，使用的是數(shù)組([...])，而不是對(duì)象({...})？

這樣來組織的原因是，OTA升級(jí)不僅僅可以對(duì)ESP32模組中的固件進(jìn)行升級(jí)("ota_type": "esp32")，還可以對(duì)其他的一些固件或用戶數(shù)據(jù)進(jìn)行更新。

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

對(duì)了，一個(gè)終端在通過網(wǎng)絡(luò)連接到云平臺(tái)時(shí)，都有一個(gè)唯一的 ID編號(hào)，一般都是利用ESP32模組上的網(wǎng)卡MAC地址來作為唯一ID。

當(dāng)完成以上步驟時(shí)，在服務(wù)器端，就存在著一個(gè)升級(jí)任務(wù)關(guān)系鏈：

也就是說：一個(gè)Job ID就對(duì)應(yīng)著一次OTA升級(jí)任務(wù)。終端設(shè)備在進(jìn)行OTA升級(jí)過程中，就是從這個(gè)Job ID開始的。

ESP32 OTA 升級(jí)的觸發(fā)
ESP32與AWS平臺(tái)之間，是通過MQTT協(xié)議進(jìn)行通信的。

因此，當(dāng)運(yùn)營人員創(chuàng)建了一個(gè)OTA升級(jí)任務(wù)后，所有相關(guān)的終端設(shè)備，必須從某個(gè)預(yù)先確定好的主題(topic)中，接收到OTA升級(jí)通知指令。

例如一個(gè)可能的topic：$aws/things/xxx/job/notify

其中的xxx，代表終端設(shè)備的MAC地址，只有這樣，每一個(gè)設(shè)備才能夠接收到屬于自己的命令。

升級(jí)通知指令的內(nèi)容中，一定會(huì)包含OTA升級(jí)的Job ID，例如：

{
"timestamp": "xxxxxx",
"job_id": "001"
}
當(dāng)終端設(shè)備接收到這個(gè)升級(jí)通知指令時(shí)，提取出job_id字段，然后向云平臺(tái)發(fā)起請(qǐng)求：獲取與這個(gè)job_id關(guān)聯(lián)的固件描述信息，也就是之前上傳的Json格式的文件息。

AWS平臺(tái)接收到這個(gè)請(qǐng)求后，就會(huì)把與這個(gè)job_id相關(guān)聯(lián)的OTA升級(jí)任務(wù)描述文件(json文件)，發(fā)送給終端設(shè)備。

設(shè)備拿到了固件描述文件，自然也就知道了固件的：版本，下載地址，MD5 值等信息，于是就進(jìn)入后面的下載環(huán)節(jié)了。

以上的過程描述，基本上是一個(gè)終端設(shè)備觸發(fā)OTA升級(jí)的最基本的過程。

在實(shí)際的項(xiàng)目中，可能會(huì)遇到一些稍微復(fù)雜的情況。

例如：一個(gè)終端設(shè)備一直處于斷電狀態(tài)。此時(shí)，云平臺(tái)中已經(jīng)對(duì)固件進(jìn)行了好幾次的升級(jí)，但是由于這臺(tái)設(shè)備一直沒有運(yùn)行，因此它的固件已經(jīng)過時(shí)了好幾個(gè)版本。

有一天，這臺(tái)設(shè)備上電運(yùn)行了，此時(shí)它會(huì)從云平臺(tái)接收到好幾個(gè)升級(jí)任務(wù)，這個(gè)時(shí)候應(yīng)該如何處理呢？

也許，我們就要對(duì)升級(jí)通知的指令中，賦予更多詳細(xì)的內(nèi)容，讓這臺(tái)設(shè)備有足夠的信息來判斷該如何進(jìn)行升級(jí)。

ESP32 固件下載和本地升級(jí)
ESP32在提取出固件的下載地址(URL)之后，就開始進(jìn)入下載環(huán)節(jié)了。

官方文檔非常詳細(xì)的描述了固件的下載過程。

下面這段代碼，就是從官方文檔中摘抄過來的：

鏈接地址：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,