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

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

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

AWS 平臺上，部署一個 OTA 升級任務(wù)時，需要完成哪些步驟；

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

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

PS： 在下面的內(nèi)容中，終端設(shè)備指的就是 ESP32 模組。

ESP32 Flash 分區(qū)

其實 ESP32 的官方文檔的過程描述，已經(jīng)是非常的詳細(xì)了。

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

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

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

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

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

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

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

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

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

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

factory 分區(qū)；

ota＿0 分區(qū)；

ota＿1 分區(qū)；

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

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

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

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

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

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