物聯網中常用的ota升級方案

說明

在進行物聯網開發的過程中，免不了進行ota升級，那么如何做好ota升級又是非常值得思考的問題。

下面從實際應用案例中，剖析一下ota升級的方案。

方案1

最簡單的OTA升級，flash布局如下：

其升級的方案是，每個APP的尾部都會記錄如下的相關信息，可以作為跳轉的標志。

所以可以這樣理解，APP0作為運行分區，APP1作為升級分區，當升級分區的標志置位時，將升級分區的代碼放到運行分區中執行。

每次都只會跳轉到APP0去執行代碼。

優點：

該方案設計比較簡單，資源占用小。

缺點：

如果升級的過程中出現錯誤，而校驗又沒有檢測到，則會導致程序起不來。需要加強校驗機制，也需要確保下載代碼完全的準確性。

也可能在升級之后，出現聯網模塊不能使用，導致需要去現場解決，這種問題發生后非常嚴重。

方案2

方案1會存在可能起不來的風險，這時需要去現場進行程序燒錄，成本很大。所以第二種是差分升級。

當APP0運行時，將升級的程序放到APP1中，下次BOOT跳轉從APP1地址去運行程序。

當APP1運行時，將升級的程序放到APP0中，下次BOOT跳轉從APP0地址去運行程序。

這樣可以解決一個問題，當模塊升級后連接不了網絡的問題。如果連接網絡失敗，可以將失敗的原因放到備份SRAM中，多次連接不上，BOOT檢測到這個現象，可以跳轉到另外一個可以運行的程序進行降級運行。因為兩個可以運行的程序沒有被破壞。

但是這個問題解決不了由于程序傳輸錯誤導致的程序啟動不了的問題。

方案3

我曾經也在實際項目中用到過另外OTA方案，如下設計：

該設計的核心在于BOOT中集成聯網模塊功能，當BOOT下載時，首先會置位相關的標志位。

其設計上采用BOOT主要用于下載功能，當程序運行APP時，需要升級時，會首先將config的標志位置位，然后跳轉到BOOT中進行升級，將代碼永遠放到APP_BAK中，升級完成后，可以校驗通過后，將APP_BAK的代碼拷貝到APP中，然后再運行APP區代碼。

最后一切功能沒問題后，再將config設置成正常狀態，否則每次boot啟動后都會進行OTA請求。

優點：

程序功能可靠有保障，減少可能起不來的風險

缺點：

由于BOOT中集成了比較多的功能，比較復雜，當替換聯網模塊時，BOOT和APP的代碼需要同步修改。

方案4

rt-thread官網上有一種OTA的方案，具體實現如下：

流程圖如下：

解釋一下factory分區的實際應用場景。

由于差分升級或者普通的BOOT升級方案都會存在系統啟動不了的可能性，所以增加了一個一定可以啟動的固件。具體的使用是需要boot中檢測一個硬件IO，當該IO被長時間按下后，會進入出廠程序設置。這樣減少了設備出問題后，技術人員需要現場升級的煩惱，即使不懂技術的人也能夠按下按鍵進行復位。

優點：

消除設備啟動不了的問題，減少程序下載失敗的風險

缺點：

資源消耗太大，三個固件起碼需要外掛SPI flash才能設計的比較好，完全利用內部flash，資源有點緊張。

責任編輯：lq