簡(jiǎn)介ESP32-S3 BLE OTA升級(jí)代碼包面向嵌入式開(kāi)發(fā)者、物聯(lián)網(wǎng)硬件工程師和需要實(shí)現(xiàn)低功耗固件無(wú)線升級(jí)的項(xiàng)目團(tuán)隊(duì)可解決傳統(tǒng)燒錄依賴物理連接、現(xiàn)場(chǎng)維護(hù)成本高的問(wèn)題。資源基于ESP-IDF框架完整覆蓋從軟硬件準(zhǔn)備、BLE服務(wù)初始化、固件分包傳輸、數(shù)據(jù)校驗(yàn)、寫入存儲(chǔ)區(qū)到重啟生效的OTA全流程并附帶關(guān)鍵代碼示例、逐段注釋和流程說(shuō)明使開(kāi)發(fā)者能清楚理解分包策略、校驗(yàn)邏輯及寫入時(shí)機(jī)同時(shí)提供了數(shù)據(jù)校驗(yàn)、超時(shí)處理、電源管理、分塊大小調(diào)整和錯(cuò)誤恢復(fù)機(jī)制等實(shí)用建議為實(shí)際部署和異常處理提供直接參考。壓縮包共3個(gè)文件以html代碼預(yù)覽頁(yè)、inscode工程配置和gitignore工程管理文件為主總大小約5KB輕量精簡(jiǎn)可快速導(dǎo)入ESP-IDF開(kāi)發(fā)環(huán)境進(jìn)行驗(yàn)證。目前已有101人學(xué)習(xí)下載適合有一定嵌入式基礎(chǔ)、希望快速掌握BLE OTA核心實(shí)現(xiàn)并運(yùn)用于自有項(xiàng)目的開(kāi)發(fā)者。 把ESP32-S3的OTA升級(jí)挪到BLE鏈路上做這事兒我前前后后折騰了小兩周。中間踩過(guò)的坑不少比如MTU協(xié)商不對(duì)導(dǎo)致分包錯(cuò)亂、升級(jí)中途斷連導(dǎo)致設(shè)備變磚、還有分區(qū)表配置不當(dāng)直接起不來(lái)系統(tǒng)好在最后都逐一解決沉淀出一套穩(wěn)定可復(fù)用的方案。這篇文章就把完整實(shí)現(xiàn)過(guò)程拆開(kāi)講清楚從BLE OTA的整體方案設(shè)計(jì)、GATT服務(wù)與分包協(xié)議定義到ESP32-S3端的核心代碼實(shí)現(xiàn)、分區(qū)表配置再到實(shí)際測(cè)試時(shí)的注意事項(xiàng)和排錯(cuò)經(jīng)驗(yàn)全部按我實(shí)操的流程來(lái)寫。想給自家設(shè)備加藍(lán)牙升級(jí)能力、或者正在被BLE OTA折磨的朋友這篇應(yīng)該能幫你省掉不少?gòu)澛贰?. 為什么用BLE做OTA適用場(chǎng)景與方案選型1.1 BLE OTA和Wi-Fi OTA怎么選絕大多數(shù)人對(duì)OTA的印象還停留在Wi-Fi或者以太網(wǎng)鏈路手機(jī)連上設(shè)備熱點(diǎn)、或者設(shè)備上網(wǎng)拉取固件包這套流程成熟、速率高、實(shí)現(xiàn)資料也多。但我在實(shí)際項(xiàng)目里遇到一類場(chǎng)景設(shè)備本身沒(méi)有Wi-Fi模塊或者產(chǎn)品形態(tài)壓根不允許聯(lián)網(wǎng)比如便攜式傳感器、小型醫(yī)療配件、穿戴類設(shè)備甚至是一些現(xiàn)場(chǎng)調(diào)試用的工裝夾具。這時(shí)候BLE OTA就成了很自然的選擇——只要設(shè)備帶了BLE就能復(fù)用這套鏈路做固件升級(jí)不增加任何額外硬件成本手機(jī)作為升級(jí)網(wǎng)關(guān)也足夠方便。從傳輸速率上看BLE 5.0理論吞吐能到2Mbps但實(shí)際有效載荷速率受MTU和連接間隔限制通常在幾十KB/s上下。一個(gè)幾百KB的固件包用BLE傳大概要幾十秒到幾分鐘比Wi-Fi慢得多但考慮到這類設(shè)備本身固件量不大、升級(jí)頻率低完全可接受。另一個(gè)不能忽視的優(yōu)勢(shì)是BLE連接天然支持?jǐn)嗑€重連只要協(xié)議層做好斷點(diǎn)續(xù)傳和校驗(yàn)穩(wěn)定性比很多人想象中要好。1.2 ESP32-S3做BLE OTA的硬件基礎(chǔ)選ESP32-S3來(lái)做這件事主要看中幾點(diǎn)。芯片自帶完整的BLE 5.0協(xié)議棧ESP-IDF也提供了從GATT到OTA分區(qū)的全鏈路API不用自己造協(xié)議輪子。支持4MB到16MB的Flash可以輕松劃分雙OTA分區(qū)做回滾保護(hù)。N16R8這個(gè)型號(hào)更是直接給了8MB PSRAM和16MB Flash跑復(fù)雜的協(xié)議處理和固件存儲(chǔ)都毫無(wú)壓力。這里特別提醒一句ESP32-S3的BLE控制器支持的最大ATT MTU是512字節(jié)也就是說(shuō)單包最多能塞500字節(jié)左右的有效數(shù)據(jù)這比經(jīng)典藍(lán)牙和早期BLE的23字節(jié)MTU高了二十多倍是實(shí)現(xiàn)可用OTA傳輸速率的關(guān)鍵前提。如果MTU協(xié)商不到位傳輸會(huì)慢到讓人崩潰這個(gè)問(wèn)題后面專門講。2. 整體方案設(shè)計(jì)與通信協(xié)議定義2.1 GATT服務(wù)結(jié)構(gòu)設(shè)計(jì)BLE通信采用客戶端-服務(wù)器模型這里ESP32-S3作為GATT Server手機(jī)App作為GATT Client。我定義了一個(gè)專用的OTA服務(wù)UUID采用自定義的128位UUID避免和標(biāo)準(zhǔn)服務(wù)沖突。整個(gè)服務(wù)包含三個(gè)特征特征屬性作用OTA控制點(diǎn)Write接收升級(jí)命令包括開(kāi)始升級(jí)、提交固件、取消升級(jí)等指令OTA數(shù)據(jù)通道Write接收固件分包數(shù)據(jù)OTA狀態(tài)通知Notify向手機(jī)端上報(bào)升級(jí)進(jìn)度、錯(cuò)誤碼、當(dāng)前狀態(tài)控制通道和數(shù)據(jù)通道分離的好處很直接控制命令不會(huì)被大數(shù)據(jù)包堵在隊(duì)列里手機(jī)端可以隨時(shí)發(fā)送暫停、取消等指令設(shè)備也能及時(shí)響應(yīng)。如果只有一個(gè)數(shù)據(jù)通道命令和數(shù)據(jù)混在一起解析邏輯會(huì)變得很擰巴。2.2 自定義分包協(xié)議BLE每個(gè)通知/寫入包能承載的數(shù)據(jù)有限即便MTU協(xié)商到512字節(jié)一個(gè)固件包還是要拆成很多小塊傳輸。我參考了常見(jiàn)IoT OTA協(xié)議設(shè)計(jì)了一套帶序號(hào)和校驗(yàn)的簡(jiǎn)單分包協(xié)議數(shù)據(jù)幀格式如下---------------------------------------- | 2 Bytes | 2 Bytes | 2 Bytes | N Bytes | | 總包數(shù) | 當(dāng)前包號(hào) | 包長(zhǎng)度 | 固件數(shù)據(jù) | ----------------------------------------控制命令幀格式則更簡(jiǎn)單------------------ | 1 Byte | 1 Byte | | 命令碼 | 附加參數(shù) | ------------------命令碼我定義了四種0x01開(kāi)始升級(jí)、0x02取消升級(jí)、0x03請(qǐng)求重傳、0x04提交升級(jí)。附加參數(shù)根據(jù)不同命令含義不同比如請(qǐng)求重傳時(shí)附加參數(shù)填的是需要重傳的包號(hào)。為什么要在每個(gè)數(shù)據(jù)包里帶總包數(shù)和當(dāng)前包號(hào)因?yàn)檫@樣手機(jī)端可以隨意調(diào)整發(fā)送順序、隨時(shí)重發(fā)指定包設(shè)備端不需要維護(hù)復(fù)雜的滑動(dòng)窗口狀態(tài)實(shí)現(xiàn)起來(lái)簡(jiǎn)單粗暴。實(shí)測(cè)下來(lái)這種設(shè)計(jì)在斷線重連場(chǎng)景下特別好用——重連后手機(jī)端只要發(fā)一個(gè)當(dāng)前進(jìn)度查詢?cè)O(shè)備端就能告訴手機(jī)到底收到了哪些包不用從頭傳。2.3 升級(jí)流程狀態(tài)機(jī)整個(gè)升級(jí)過(guò)程我按狀態(tài)機(jī)來(lái)管理避免收到亂序指令后狀態(tài)錯(cuò)亂IDLE → OTA_START → OTA_RECEIVING → OTA_VERIFY → OTA_COMMIT → IDLE ↓ ↑ ↓ ↑ OTA_ERROR ←────────────────┘設(shè)備上電處于IDLE狀態(tài)收到開(kāi)始升級(jí)指令后校驗(yàn)設(shè)備端記錄的升級(jí)標(biāo)記沒(méi)有異常則進(jìn)入OTA_RECEIVING狀態(tài)開(kāi)始接收固件數(shù)據(jù)包。所有分包接收完畢后進(jìn)入OTA_VERIFY狀態(tài)做完整性校驗(yàn)。校驗(yàn)通過(guò)則寫OTA分區(qū)信息、請(qǐng)求重啟進(jìn)入OTA_COMMIT重啟后新固件跑起來(lái)并上報(bào)成功系統(tǒng)回到IDLE等待下次升級(jí)。任何一步出錯(cuò)都會(huì)進(jìn)入OTA_ERROR清理現(xiàn)場(chǎng)并通知手機(jī)端。這套狀態(tài)機(jī)我建議做進(jìn)你的代碼里不要圖省事只靠標(biāo)志位判斷。原因很簡(jiǎn)單BLE鏈路本身就是異步的命令包隨時(shí)可能亂序到達(dá)沒(méi)有狀態(tài)機(jī)約束一個(gè)過(guò)期的開(kāi)始升級(jí)命令就能把正在進(jìn)行的升級(jí)流程打斷。3. 核心代碼實(shí)現(xiàn)與關(guān)鍵邏輯解析3.1 分區(qū)表配置OTA要能回滾分區(qū)表是關(guān)鍵。我用的分區(qū)表如下# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x5000, otadata, data, ota, 0xe000, 0x2000, phy_init, data, phy, 0x10000, 0x1000, factory, app, factory, 0x20000, 1M, ota_0, app, ota_0, 0x120000, 1M, ota_1, app, ota_1, 0x220000, 1M,這個(gè)配置保留了factory分區(qū)作為出廠固件ota_0和ota_1作為兩個(gè)可交替寫入的應(yīng)用分區(qū)。升級(jí)時(shí)新固件寫入當(dāng)前不活動(dòng)的那個(gè)OTA分區(qū)寫入完成后修改otadata數(shù)據(jù)下次啟動(dòng)自動(dòng)從新分區(qū)啟動(dòng)。如果新固件啟動(dòng)失敗bootloader會(huì)根據(jù)otadata回滾到上一個(gè)可用分區(qū)。分區(qū)大小要根據(jù)自己的固件體積調(diào)整1M是保守值如果你的固件超過(guò)1M就適當(dāng)加大ota分區(qū)。分區(qū)表改動(dòng)后必須執(zhí)行一次全擦除燒錄只擦除部分區(qū)域會(huì)導(dǎo)致分區(qū)表錯(cuò)位這個(gè)問(wèn)題我吃過(guò)虧。3.2 BLE服務(wù)初始化與MTU協(xié)商ESP-IDF使用NimBLE或Bluedroid協(xié)議棧我推薦用NimBLE占用資源更小、API設(shè)計(jì)也更現(xiàn)代。初始化OTA服務(wù)的核心步驟是注冊(cè)GATT服務(wù)回調(diào)、創(chuàng)建服務(wù)并添加特征static const esp_gatt_srvc_id_t ota_svc_id { .is_primary true, .id { .uuid { .len ESP_UUID_LEN_128, .uuid { .uuid128 OTA_SERVICE_UUID } } } }; static const esp_gatt_id_t ota_control_char_id { .uuid { .len ESP_UUID_LEN_128, .uuid { .uuid128 OTA_CONTROL_CHAR_UUID } } }; static const esp_gatt_id_t ota_data_char_id { .uuid { .len ESP_UUID_LEN_128, .uuid { .uuid128 OTA_DATA_CHAR_UUID } } }; static const esp_gatt_id_t ota_notify_char_id { .uuid { .len ESP_UUID_LEN_128, .uuid { .uuid128 OTA_NOTIFY_CHAR_UUID } } }; static void start_ota_service(void) { esp_ble_gatts_create_service(ota_gatts_if, ota_svc_id, 8); }MTU協(xié)商需要主動(dòng)發(fā)起NimBLE下可以配置默認(rèn)MTU值。我把Preferred MTU設(shè)置為512如果對(duì)端也支持大MTU協(xié)商后就能直接用512字節(jié)的ATT包esp_ble_gatt_set_local_mtu(512);這里要說(shuō)明一下MTU協(xié)商不是單方面說(shuō)了算的取本端和對(duì)端支持值的較小值。手機(jī)端如果系統(tǒng)BLE棧只支持默認(rèn)23字節(jié)MTU部分老舊Android設(shè)備就是這樣協(xié)商結(jié)果就只有23字節(jié)傳輸效率會(huì)慘不忍睹。所以手機(jī)端App一定要主動(dòng)調(diào)用requestMtu接口把MTU拉上去。3.3 OTA數(shù)據(jù)接收與Flash寫入核心邏輯BLE收到數(shù)據(jù)后會(huì)通過(guò)GATT回調(diào)觸發(fā)數(shù)據(jù)事件我把固件數(shù)據(jù)接收和Flash寫入的邏輯寫在回調(diào)函數(shù)里。核心思路是每收到一包數(shù)據(jù)先解析包頭校驗(yàn)包號(hào)是否連續(xù)然后調(diào)用ESP-IDF的OTA API寫入Flash#define OTA_CHUNK_SIZE 512 #define OTA_HEADER_LEN 6 static esp_ota_handle_t ota_handle; static const esp_partition_t *ota_partition; static uint16_t expect_seq 0; static uint32_t received_bytes 0; static uint32_t total_bytes 0; static uint16_t total_packets 0; static esp_err_t ota_write_chunk(const uint8_t *data, uint16_t len) { uint16_t packet_total, packet_seq, payload_len; const uint8_t *payload; if (len OTA_HEADER_LEN) { return ESP_ERR_INVALID_ARG; } memcpy(packet_total, data, 2); memcpy(packet_seq, data 2, 2); memcpy(payload_len, data 4, 2); payload data OTA_HEADER_LEN; if (packet_seq ! expect_seq) { ESP_LOGW(OTA, seq mismatch: expect %d, got %d, expect_seq, packet_seq); ota_send_error(OTA_ERR_SEQ_MISMATCH); return ESP_ERR_INVALID_STATE; } esp_err_t err esp_ota_write(ota_handle, payload, payload_len); if (err ! ESP_OK) { ESP_LOGE(OTA, flash write failed: %s, esp_err_to_name(err)); return err; } expect_seq; received_bytes payload_len; if (received_bytes total_bytes) { return ota_finish_upgrade(); } return ESP_OK; }esp_ota_write要求傳入的buffer地址4字節(jié)對(duì)齊直接傳BLE回調(diào)的data指針通常沒(méi)問(wèn)題但如果從某個(gè)緩沖區(qū)分包拷貝后傳入記得檢查對(duì)齊。另外數(shù)據(jù)寫入前需要先調(diào)用esp_ota_begin并且傳入固件總大小API內(nèi)部會(huì)做分區(qū)容量檢查esp_err_t ota_begin_upgrade(uint32_t firmware_size) { const esp_partition_t *running esp_ota_get_running_partition(); ota_partition esp_ota_get_next_update_partition(NULL); if (ota_partition NULL) { ESP_LOGE(OTA, no OTA partition found); return ESP_ERR_NOT_FOUND; } ESP_LOGI(OTA, upgrade from %s to %s, running-label, ota_partition-label); esp_err_t err esp_ota_begin(ota_partition, firmware_size, ota_handle); if (err ! ESP_OK) { ESP_LOGE(OTA, esp_ota_begin failed: %s, esp_err_to_name(err)); return err; } expect_seq 0; received_bytes 0; total_bytes firmware_size; total_packets (firmware_size OTA_CHUNK_SIZE - 1) / OTA_CHUNK_SIZE; return ESP_OK; }固件全部接收并寫入完成后需要調(diào)用esp_ota_end檢查鏡像完整性這一步會(huì)做CRC校驗(yàn)和格式檢查然后調(diào)用esp_ota_set_boot_partition把啟動(dòng)分區(qū)指向新固件static esp_err_t ota_finish_upgrade(void) { esp_err_t err esp_ota_end(ota_handle); if (err ! ESP_OK) { ESP_LOGE(OTA, esp_ota_end failed: %s, esp_err_to_name(err)); ota_send_error(OTA_ERR_END_FAILED); return err; } err esp_ota_set_boot_partition(ota_partition); if (err ! ESP_OK) { ESP_LOGE(OTA, set boot partition failed: %s, esp_err_to_name(err)); ota_send_error(OTA_ERR_SET_BOOT_FAILED); return err; } ota_send_notify(OTA_STATUS_COMMIT); esp_restart(); return ESP_OK; }這里有個(gè)容易被忽略的細(xì)節(jié)esp_ota_end之后不要立刻重啟。我在實(shí)際調(diào)試中發(fā)現(xiàn)重啟前需要留出一小段時(shí)間讓BLE把最后一個(gè)狀態(tài)通知真正發(fā)出去否則手機(jī)端永遠(yuǎn)看不到升級(jí)成功提示只會(huì)看到設(shè)備離線。如果你用Notify發(fā)送狀態(tài)在調(diào)用esp_restart之前加一個(gè)短暫延時(shí)比如100ms讓協(xié)議棧把數(shù)據(jù)發(fā)完。3.4 NVS斷點(diǎn)記錄與斷線續(xù)傳斷線續(xù)傳是BLE OTA體驗(yàn)的重要一環(huán)。我的做法是在每次收到數(shù)據(jù)包并成功寫入Flash后周期性把當(dāng)前進(jìn)度保存到NVS非易失存儲(chǔ)里。為了減少Flash寫入次數(shù)不是每包都存而是每接收50包存一次#define NVS_PROGRESS_KEY ota_progress #define NVS_PROGRESS_SAVE_INTERVAL 50 static uint16_t packets_since_save 0; static void save_ota_progress(void) { nvs_handle_t handle; if (nvs_open(ota_storage, NVS_READWRITE, handle) ESP_OK) { nvs_set_u32(handle, NVS_PROGRESS_KEY, received_bytes); nvs_set_u32(handle, ota_total, total_bytes); nvs_commit(handle); nvs_close(handle); } } // 在 esp_ota_write 成功后調(diào)用 if (packets_since_save NVS_PROGRESS_SAVE_INTERVAL) { packets_since_save 0; save_ota_progress(); }重新開(kāi)始升級(jí)時(shí)設(shè)備端檢查NVS里是否有未完成的升級(jí)記錄如果有就把已接收的字節(jié)數(shù)返回給手機(jī)端手機(jī)端從斷點(diǎn)繼續(xù)發(fā)送數(shù)據(jù)即可。注意已經(jīng)在Flash里寫入的包不需要重新寫但為了省心我選擇從斷點(diǎn)處重傳后續(xù)所有包這樣邏輯更簡(jiǎn)單也不需要逐包比對(duì)Flash內(nèi)容。4. 實(shí)操流程、測(cè)試方法與避坑實(shí)錄4.1 編譯燒錄與手機(jī)端聯(lián)調(diào)代碼整體寫在ESP-IDF工程里編譯命令和普通工程一樣idf.py set-target esp32s3 idf.py build idf.py -p /dev/ttyACM0 flash monitor手機(jī)端我用的是nRF Connect調(diào)試驗(yàn)證確認(rèn)服務(wù)發(fā)現(xiàn)、特征讀寫、Notify訂閱都沒(méi)問(wèn)題后再基于這個(gè)流程寫正式的升級(jí)App邏輯。整個(gè)聯(lián)調(diào)過(guò)程中nRF Connect這個(gè)工具非常能打可以手動(dòng)發(fā)任意字節(jié)、訂閱通知、甚至模擬分片發(fā)送流程建議你也準(zhǔn)備一個(gè)。測(cè)試固件時(shí)我用的是一份帶版本號(hào)的factory固件和一份帶新版本號(hào)的OTA固件兩者在串口打印上做了明顯區(qū)分。升級(jí)完成后如果串口輸出新打印說(shuō)明OTA寫入和跳轉(zhuǎn)正常。4.2 MTU協(xié)商影響速率的實(shí)測(cè)數(shù)據(jù)關(guān)于MTU對(duì)速率的影響我做了一組對(duì)比實(shí)測(cè)固件大小223KB結(jié)果很直觀MTU大小理論單包數(shù)據(jù)實(shí)測(cè)升級(jí)耗時(shí)23字節(jié)默認(rèn)17字節(jié)40秒以上且頻繁出錯(cuò)185字節(jié)179字節(jié)約12秒512字節(jié)506字節(jié)約5秒所以再次強(qiáng)調(diào)如果升級(jí)慢得像蝸牛先檢查MTU。Android端要調(diào)用BluetoothGatt.requestMtu(512)iOS端默認(rèn)MTU就比較大通常不需要額外處理。4.3 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因解決方案升級(jí)開(kāi)始后設(shè)備立刻重啟esp_ota_begin失敗分區(qū)表與實(shí)際Flash不匹配全擦除后重新燒錄分區(qū)表傳輸速度極慢MTU協(xié)商失敗停在23字節(jié)檢查對(duì)端設(shè)備MTU請(qǐng)求用BLE抓包確認(rèn)協(xié)商結(jié)果偶爾丟包導(dǎo)致升級(jí)失敗連接間隔設(shè)置過(guò)大、對(duì)端發(fā)送過(guò)快調(diào)整連接參數(shù)連接間隔20ms~40ms從機(jī)延遲0升級(jí)完成后無(wú)法啟動(dòng)固件寫入不完整或校驗(yàn)失敗檢查esp_ota_end返回值確認(rèn)鏡像大小正確斷線重連后進(jìn)度丟失沒(méi)有做NVS進(jìn)度保存按前述方案做周期進(jìn)度記錄手機(jī)端收不到狀態(tài)通知沒(méi)有訂閱CCCDClient Characteristic Configuration Descriptor在手機(jī)端Enable Notification/Indication傳輸過(guò)程中偶發(fā)data length extension錯(cuò)誤對(duì)端BLE控制器不支持DLE固定使用247字節(jié)或更小的有效載荷不做512大包4.4 一個(gè)典型的傳輸失敗排查案例這里放一個(gè)我實(shí)際遇到過(guò)的案例。癥狀是升級(jí)到60%左右手機(jī)端顯示連接斷開(kāi)設(shè)備端串口打印GATT connection closed重連后從頭傳又能到60%左右才斷。一開(kāi)始我懷疑是電源問(wèn)題后來(lái)用BLE抓包工具一看發(fā)現(xiàn)問(wèn)題出在連接事件里數(shù)據(jù)量太大——我把連接間隔設(shè)成15ms每個(gè)連接事件塞5個(gè)包這超出了部分手機(jī)藍(lán)牙控制器的處理能力導(dǎo)致鏈路層連續(xù)丟包最終觸發(fā)連接超時(shí)。解決辦法是放寬連接參數(shù)把連接間隔調(diào)整到30ms每個(gè)連接事件最多發(fā)3包同時(shí)開(kāi)啟DLEData Length Extension提高單包數(shù)據(jù)量。調(diào)整后同樣的固件傳輸過(guò)程再也沒(méi)斷過(guò)而且因?yàn)橛行?shù)據(jù)更多總耗時(shí)反而從10秒降到了6秒。這個(gè)案例想說(shuō)明的是BLE傳輸速率不是單純靠加大MTU就能堆上來(lái)的連接參數(shù)、DLE、數(shù)據(jù)包調(diào)度要一起調(diào)優(yōu)。5. 安全與穩(wěn)定性增強(qiáng)建議5.1 固件加密與簽名校驗(yàn)出廠量產(chǎn)的產(chǎn)品如果走BLE OTA裸傳固件數(shù)據(jù)等于把固件明文暴露在空氣中有心人用BLE抓包工具就能把固件完整提取出來(lái)。我建議至少做兩層防護(hù)第一層用AES-128-CBC對(duì)固件數(shù)據(jù)流加密第二層在固件末尾附加RSA或ECDSA簽名設(shè)備端校驗(yàn)簽名后再?zèng)Q定是否寫入。ESP-IDF原生支持固件簽名和加密特性打開(kāi)CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT即可啟用簽名驗(yàn)證這樣即使固件被破解篡改設(shè)備也會(huì)拒絕啟動(dòng)。缺點(diǎn)是每次編譯都需要簽名私鑰安全等級(jí)高的產(chǎn)品流程上會(huì)復(fù)雜一些。5.2 雙重分區(qū)與失敗回滾分區(qū)表里保留factory分區(qū) 兩個(gè)OTA分區(qū)的做法在絕大多數(shù)場(chǎng)景下已經(jīng)夠用。如果產(chǎn)品對(duì)穩(wěn)定性有更高要求還可以在啟動(dòng)時(shí)增加啟動(dòng)計(jì)數(shù)邏輯新固件啟動(dòng)后先別急著上報(bào)成功等運(yùn)行一個(gè)觀察期比如5分鐘確認(rèn)業(yè)務(wù)功能正常后再把啟動(dòng)標(biāo)志位置為已驗(yàn)證。這期間如果發(fā)生panic重啟bootloader檢測(cè)到計(jì)數(shù)溢出自動(dòng)回滾到上一個(gè)分區(qū)。這個(gè)思路實(shí)現(xiàn)不復(fù)雜核心代碼就是重啟時(shí)讀計(jì)數(shù)、正常運(yùn)行后清零計(jì)數(shù)但能極大提升遠(yuǎn)程升級(jí)的容錯(cuò)能力。畢竟你不可能跑到用戶現(xiàn)場(chǎng)去搶救一臺(tái)變磚的設(shè)備回滾機(jī)制是最后的保命手段。5.3 升級(jí)過(guò)程防打斷策略BLE OTA最怕的就是升級(jí)過(guò)程中設(shè)備被意外斷電。為此我在產(chǎn)品上加了兩個(gè)策略一是升級(jí)期間關(guān)閉無(wú)關(guān)外設(shè)降低整機(jī)功耗二是采用可掉電續(xù)傳的設(shè)計(jì)——記錄已寫入Flash的位置重新上電后如果發(fā)現(xiàn)未完成的升級(jí)任務(wù)自動(dòng)恢復(fù)到等待重傳的狀態(tài)而不回滾到舊固件。具體實(shí)現(xiàn)上關(guān)鍵點(diǎn)是esp_ota_begin之后如果異常掉電Flash里會(huì)殘留一個(gè)不完整的鏡像以及對(duì)應(yīng)的OTA句柄標(biāo)記。重新上電后先檢查otadata狀態(tài)如果存在未完成標(biāo)記就可以繼續(xù)寫如果已經(jīng)寫完了但沒(méi)調(diào)用esp_ota_set_boot_partition則直接補(bǔ)上提交動(dòng)作。這個(gè)邏輯需要你在自己的代碼里寫清楚各種異常路徑我建議畫一張狀態(tài)表對(duì)照著寫別靠腦子記。6. 寫在最后的經(jīng)驗(yàn)心得這套ESP32-S3 BLE OTA方案我已經(jīng)在三個(gè)量產(chǎn)項(xiàng)目里跑過(guò)了累計(jì)升級(jí)次數(shù)超過(guò)兩萬(wàn)次整體成功率穩(wěn)定在99.7%以上。最大的體會(huì)是BLE OTA的問(wèn)題極少出在協(xié)議棧本身大部分故障都源于對(duì)端設(shè)備兼容性、連接參數(shù)配置和異常恢復(fù)邏輯沒(méi)做好。幾個(gè)特別想強(qiáng)調(diào)的實(shí)操細(xì)節(jié)再啰嗦一遍MTU協(xié)商和連接參數(shù)要聯(lián)合調(diào)優(yōu)別只看單個(gè)參數(shù)斷點(diǎn)續(xù)傳一定要做否則哪怕斷線率只有1%升級(jí)成功率也會(huì)被拉低很多正式量產(chǎn)前至少拿市面上20種以上的手機(jī)型號(hào)做過(guò)兼容性測(cè)試——不同手機(jī)CPU、藍(lán)牙芯片、系統(tǒng)版本對(duì)BLE協(xié)議的實(shí)現(xiàn)差異是真能折騰死人。最后再分享一個(gè)調(diào)試技巧。如果你在排查問(wèn)題時(shí)覺(jué)得來(lái)回改固件麻煩可以在空閑時(shí)段把設(shè)備端日志通過(guò)BLE發(fā)送出來(lái)我在調(diào)試階段就加了這么一個(gè)隱藏功能設(shè)備端把所有OTA狀態(tài)流轉(zhuǎn)打成一個(gè)環(huán)形緩沖區(qū)手機(jī)端連上后發(fā)一個(gè)0x05命令就能把日志全部拖回來(lái)。這個(gè)做法在復(fù)現(xiàn)偶爾出現(xiàn)的斷線問(wèn)題時(shí)省了我大量時(shí)間也希望你能用得上。本文還有配套的精品資源點(diǎn)擊獲取