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

文章鏈接在此：

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

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

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

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

1. AWS 平臺上，部署一個 OTA 升級任務時，需要完成哪些步驟;

   
   

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

   
   

3. 如何通過 ESP32，給與之相連的 MCU 進行 OTA 升級;

   
   

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

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

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

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

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

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

關于分區(qū)表，ESP32中預定義了2份分區(qū)表，分別對應：是否存在 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功能的這個分區(qū)表為準了。

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

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

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

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

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

啟動加載器會查詢該分區(qū)(otadata)的數(shù)據(jù)，以判斷：應該從哪個OTA應用程序分區(qū)來加載程序。

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

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

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

從上一篇文章中可以看到，當一個新的固件準備好之后，需要做2件事情：

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

   
   

2. 在 AWS Core 任務管理中，新建一個升級任務(會得到一個 Job ID)。在這個任務中需要選擇：

   
   

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

(2) 哪些終端設備需要升級;

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

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

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

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

對了，一個終端在通過網(wǎng)絡連接到云平臺時，都有一個唯一的 ID編號，一般都是利用ESP32模組上的網(wǎng)卡MAC地址來作為唯一ID。

當完成以上步驟時，在服務器端，就存在著一個升級任務關系鏈：

也就是說：一個Job ID就對應著一次OTA升級任務。終端設備在進行OTA升級過程中，就是從這個Job ID開始的。

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

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

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

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

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

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

AWS平臺接收到這個請求后，就會把與這個job_id相關聯(lián)的OTA升級任務描述文件(json文件)，發(fā)送給終端設備。

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

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

在實際的項目中，可能會遇到一些稍微復雜的情況。

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

有一天，這臺設備上電運行了，此時它會從云平臺接收到好幾個升級任務，這個時候應該如何處理呢？

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

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

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

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

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