亞馬遜 AWS 平臺 OTA 升級過程詳情

本篇內容介紹了“亞馬遜 AWS 平臺 OTA 升級過程詳情”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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

文章鏈接在此：

• 物聯網設備OTA軟件升級之：升級包下載過程之旅

• 物聯網設備OTA軟件升級之：完全升級和增量升級

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

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

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

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

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

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

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

• 在 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, &update_handle);             }         }         esp_ota_write( update_handle, (const void *)ota_write_data, data_read);     } }

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

我們假設這次固件升級，存儲在 ota_0 這個分區中。

在固件下載完畢之后，esp_ota_end() 函數會在 otadata 分區寫入一個標記: 下次啟動時，請加載 ota_0 分區中的固件程序。

當 ESP32 重新啟動時，啟動加載器從 otadata 分區讀取數據，得知這一次需要啟動 ota_0分區里的固件。

此時有一件很重要的事情需要做：當 ota_0 分區中的固件啟動正確無誤后，需要調用函數  esp_ota_mark_app_valid_cancel_rollback() 往 otadata 區寫 ESP_OTA_IMG_VALID，標記:  這個分區中的固件是沒有問題的!

這樣的話，以后每次重啟時，都會加載 ota_0 分區里的固件。

相反的情況：如果 ota_0 分區里的固件，在第一次啟動后新固件運行有問題，需要調用函數  esp_ota_mark_app_invalid_rollback_and_reboot() 往 otadata 區寫  ESP_OTA_IMG_INVALID，標記：這個分區中的固件有問題!

這樣的話，重啟之后，啟動加載器將會選擇之前的 app 分區里的固件，可能是 factory 分區，也可能是 ota_1 分區。

OTA 升級過程中斷了，怎么辦?

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

例如：從接收到固件描述信息，到固件下載完成。在這期間的任何一個時間點，如果因為斷電等原因，導致設備重啟了，該如何繼續 OTA 升級過程?

我們知道，在程序運行的時候，所有的數據都是保存在內存中的。

重啟之后，內存中的數據是一篇空白。

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

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

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

3. 固件下載過程中已經完成的每一個階段;

這些信息可以調用 nvs_write() 函數，保存在非易失性存儲設備中。

即使系統因為斷電等原因重啟了，也可以通過 nvs_read() 函數，讀取之前已經完成的步驟，然后繼續后續的升級操作。

通過 ESP32，升級 MCU 固件

ESP32 模組，僅僅是一個用來連接網絡云平臺的無線設備。

對于一個實際的產品而言，發揮實際功能控制作用的，往往是另一片單片機，比如: STM32。

單片機中的固件也有可能需要進行 OTA 升級，此時 ESP32 就要作為中間的一個媒介，先把 MCU  固件下載下來存儲在本地，然后再通過串口發送給單片機。

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

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

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

唯一的區別就是：下載的時候，需要把固件保存到 Flash 上的一塊獨立的數據分區中，而不是 ota_0 或 ota_1 分區。

至此，關于 ESP32 模組以及 MCU 的 OTA 升級過程就基本描述完畢了。

“亞馬遜 AWS 平臺 OTA 升級過程詳情”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！