ESP32 開發之：亞馬遜 AWS 平臺 OTA 升級過程完全梳理
在最近的兩篇文章中，我們從概念和流程上梳理了: 一個終端設備如何把一個固件，安全無誤的從服務器上，下載到本地。
文章鏈接在此：
- 物聯網設備OTA軟件升級之：升級包下載過程之旅
- 物聯網設備OTA軟件升級之：完全升級和增量升級
這篇文章就繼續往下深入，以一個實際的 ESP32 項目，來完整的梳理一下 OTA 升級的全過程。
主要包括下面 3 部分內容：
- AWS 平臺上，部署一個 OTA 升級任務時，需要完成哪些步驟;
- ESP32 模組中，關于 Flash 分區和 OTA 升級控制過程和代碼說明;
- 如何通過 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 升級過程可以在任何異常情況下都能順利進行，必須保存一些必要的信息，包括：
- json 格式的固件描述文件;
- 固件下載過程中已經完成的每一個階段;
這些信息可以調用 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 升級過程就基本描述完畢了。
以上這些內容，都是是一些結構性的流程節點，剩下部分就是一些細節問題了，按照官方文檔的指導步驟，都可以順利完成開發!
