亞馬遜 AWS 平臺(tái) OTA 升級(jí)過程詳情

本篇內(nèi)容介紹了“亞馬遜 AWS 平臺(tái) OTA 升級(jí)過程詳情”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

在最近的兩篇文章中，我們從概念和流程上梳理了: 一個(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. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

4. 如何通過 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 件事情：

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

• 在 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)營(yíng)人員創(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, &update_handle);             }         }         esp_ota_write( update_handle, (const void *)ota_write_data, data_read);     } }

把這個(gè)過程畫成流程圖，就是下面這個(gè)樣子：

我們假設(shè)這次固件升級(jí)，存儲(chǔ)在 ota_0 這個(gè)分區(qū)中。

在固件下載完畢之后，esp_ota_end() 函數(shù)會(huì)在 otadata 分區(qū)寫入一個(gè)標(biāo)記: 下次啟動(dòng)時(shí)，請(qǐng)加載 ota_0 分區(qū)中的固件程序。

當(dāng) ESP32 重新啟動(dòng)時(shí)，啟動(dòng)加載器從 otadata 分區(qū)讀取數(shù)據(jù)，得知這一次需要啟動(dòng) ota_0分區(qū)里的固件。

此時(shí)有一件很重要的事情需要做：當(dāng) ota_0 分區(qū)中的固件啟動(dòng)正確無誤后，需要調(diào)用函數(shù)  esp_ota_mark_app_valid_cancel_rollback() 往 otadata 區(qū)寫 ESP_OTA_IMG_VALID，標(biāo)記:  這個(gè)分區(qū)中的固件是沒有問題的!

這樣的話，以后每次重啟時(shí)，都會(huì)加載 ota_0 分區(qū)里的固件。

相反的情況：如果 ota_0 分區(qū)里的固件，在第一次啟動(dòng)后新固件運(yùn)行有問題，需要調(diào)用函數(shù)  esp_ota_mark_app_invalid_rollback_and_reboot() 往 otadata 區(qū)寫  ESP_OTA_IMG_INVALID，標(biāo)記：這個(gè)分區(qū)中的固件有問題!

這樣的話，重啟之后，啟動(dòng)加載器將會(huì)選擇之前的 app 分區(qū)里的固件，可能是 factory 分區(qū)，也可能是 ota_1 分區(qū)。

OTA 升級(jí)過程中斷了，怎么辦?

以上描述的過程都是理想的情況，那么如果遇到一些異常情況，該如何處理呢?

例如：從接收到固件描述信息，到固件下載完成。在這期間的任何一個(gè)時(shí)間點(diǎn)，如果因?yàn)閿嚯姷仍?，?dǎo)致設(shè)備重啟了，該如何繼續(xù) OTA 升級(jí)過程?

我們知道，在程序運(yùn)行的時(shí)候，所有的數(shù)據(jù)都是保存在內(nèi)存中的。

重啟之后，內(nèi)存中的數(shù)據(jù)是一篇空白。

如果希望 OTA 升級(jí)過程可以在任何異常情況下都能順利進(jìn)行，必須保存一些必要的信息，包括：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. json 格式的固件描述文件;

3. 固件下載過程中已經(jīng)完成的每一個(gè)階段;

這些信息可以調(diào)用 nvs_write() 函數(shù)，保存在非易失性存儲(chǔ)設(shè)備中。

即使系統(tǒng)因?yàn)閿嚯姷仍蛑貑⒘?，也可以通過 nvs_read() 函數(shù)，讀取之前已經(jīng)完成的步驟，然后繼續(xù)后續(xù)的升級(jí)操作。

通過 ESP32，升級(jí) MCU 固件

ESP32 模組，僅僅是一個(gè)用來連接網(wǎng)絡(luò)云平臺(tái)的無線設(shè)備。

對(duì)于一個(gè)實(shí)際的產(chǎn)品而言，發(fā)揮實(shí)際功能控制作用的，往往是另一片單片機(jī)，比如: STM32。

單片機(jī)中的固件也有可能需要進(jìn)行 OTA 升級(jí)，此時(shí) ESP32 就要作為中間的一個(gè)媒介，先把 MCU  固件下載下來存儲(chǔ)在本地，然后再通過串口發(fā)送給單片機(jī)。

在這種情況下，ESP32 接收到的 OTA 固件描述信息就有可能是下面這個(gè)樣子：

{   "product": "產(chǎn)品名稱",   "group": "設(shè)備分組",   "firmware":    [      {         "ota_type": "stm32",         "url": "http://xxx/mcu-v1.2.3.bin",         "md5": "xxx"      }   ] }

從 ota_type 字段，可以知道這次是給 MCU 進(jìn)行升級(jí)，接下來的下載過程就與上述流程很類似了。

唯一的區(qū)別就是：下載的時(shí)候，需要把固件保存到 Flash 上的一塊獨(dú)立的數(shù)據(jù)分區(qū)中，而不是 ota_0 或 ota_1 分區(qū)。

至此，關(guān)于 ESP32 模組以及 MCU 的 OTA 升級(jí)過程就基本描述完畢了。

“亞馬遜 AWS 平臺(tái) OTA 升級(jí)過程詳情”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！