隨著嵌入式系統的發展，產品對于代碼升級功能的需求越來越大。通過代碼升級，可以實現諸如支持新功能，修復故障等目標。

代碼升級本質上是對片上閃存flash（主要是code flash）進行擦除和寫入的過程。由于需要在代碼運行的同時實現對flash內容的操作，因此有些特別需要注意的部分。如：假如在傳輸過程中出現異常，導致代碼升級失敗，設備能否從該狀態正常啟動并恢復至最近一次升級前的狀態。還有，假如向芯片中燒錄的新代碼存在漏洞，或傳輸途徑中遭到破壞，設備能否檢測到這種異常并拒絕運行該代碼。另外，由于代碼升級跟芯片的flash結構密切相關，因此該過程中是否涉及中斷向量表重定位等也需考慮。

代碼升級的實現方式多種多樣，系統架構也千差萬別，如何在眾多方式中找到合適的升級方式，需要用戶根據應用場景的需求進行評估。

在此，我們介紹一種面向32位微處理器的安全啟動代碼框架——MCUboot。

MCUboot都有哪些特定呢？主要是以下幾個：

完全開源，持續更新

支持各種升級模式：overwrite，swap，direct XIP（Execute In Place）和拷貝到RAM中執行

對新固件Firmware進行安全校驗，且安全校驗的級別可根據實際需求選擇

可從升級異常中恢復

MCUboot相關的資源都在哪里呢？您可進入MCUboot官網（MCUboot official website），源碼全部托管在GitHub上。頁面下有一個md文件，作為MCUboot的官方介紹。

由于MCUboot是一個系統框架，因此它規定了對于芯片的flash劃分，將整個芯片的存儲空間劃分為Bootloader、Primary Slot和Secondary Slot三個部分。某種意義上說，Primary Slot和Secondary Slot互為對方的備份，在不同的升級模式下，各slot的作用也有所不同，這一點我們在后續詳細介紹。

對于一個32位單片機來說，客戶可以自行移植MCUboot以適配當前產品，而Renesas FSP（Flexible Software Package靈活軟件包）已經幫客戶實現了該適配，對于Renesas RA系列產品來說，MCUboot相關的大多數配置均可通過界面簡單添加和配置，就像添加一個普通的外設驅動那樣。

靈活配置軟件包FSP

我們以FSP對MCUboot的支持為例，對MCUboot的相關特性進行介紹。

首先介紹MCUboot支持的四種升級模式，分別是Overwrite、Swap、Direct XIP和加載到RAM中執行。由于FSP不支持第四種——加載到RAM中執行，因為我們重點介紹前三種。

Overwrite模式

MCUboot Overwrite模式圖解

對于Overwrite模式來說，起點是芯片中燒錄了Bootloader和User Application v1.0（初始版本），上電后Bootloader分別檢查Secondary Slot和Primar Slot中的內容，由于此時Secondary Slot為空，因此Bootloader檢查Primary Slot中Image（映像文件）的完整性，確認其合法后會跳轉到Primary Slot中的User Application v1.0中執行（此時PC指針運行在Primary Slot中，黃色的Execution箭頭標識）。

代碼運行的過程中收到了升級請求，則會接收新Image并燒錄到Secondary Slot中。對于接收新Image的途徑，則完全依賴用戶應用程序的實現，可以是USB、網口、Modbus等。燒錄完成后，會執行一條軟復位指令，使得芯片回到復位向量表處開始執行Bootloader，此時Bootloader發現Secondary Slot中有一個新的代碼，假如它的版本是v2.0，高于Primary Slot中的v1.0，則會將Secondary Slot中的內容拷貝到Primary Slot中，然后將Secondary Slot擦除。

如果比較整個過程的起始狀態和結束狀態，我們會發現，芯片中運行的代碼從低版本的v1.0變成了高版本的v2.0，實現了代碼的升級。

從Overwrite模式的流程不難看出它的一些特點：

由于代碼設計比較簡單，因此Bootloader帶來的代碼量較小。因此能夠留更多的空間給應用程序使用。

Overwrite不支持代碼回滾。即假如芯片中燒錄了新Image，則升級完成后舊Image不復存在。

代碼僅在Secondary Slot中備份而非執行，最終需拷貝到Primary Slot中執行，因此升級所用的Application Image進行編譯/鏈接的地址始終為Primary Slot地址空間。

由于整個過程中需要對flash進行兩次擦除（Primary Slot和Secondary Slot）一次寫入（Primary Slot），因此整個Boot的過程依賴flash的特性，主要是擦寫速度。

對于Renesas RA系列產品來說，假如在Stack中添加了MCUboot模塊，則升級模式的修改界面如下所示。

FSP中MCUboot升級模式選項

注意：Overwrite Only和Overwrite Only Fast比較類似，唯一的區別是，后者僅將用到的sectors（此處可以理解為Flash Block）從Secondary Slot拷貝到Primary Slot，未用部分不拷貝。

Swap模式

MCUboot Swap升級模式圖解

從系統框圖來說，Swap模式和Overwrite模式相比，在flash劃分上多了Scratch area，用于存儲兩個slot交換的中間內容。

為簡化說明，對于Swap模式來說，依然假設起點是芯片中燒錄了Bootloader和User Application v1.0 （位于Primary Slot），代碼運行過程中收到了升級指令，接收來自外部的新Image （User Application v2.0），并燒錄到Secondary Slot中，完成后執行軟復位，芯片重新回到Bootloader中運行。此時Bootloader判斷Secondary Slot有更高版本v2.0的代碼，檢查其完整性，確定合法后將Primary Slot中的內容和Secondary Slot中的內容以Block為單元進行交換。

交換完成后，Primary Slot保存了高版本v2.0的Image，而Secondary Slot中保存了低版本v1.0的Image，代碼依然在Primary Slot中執行。

Swap模式下的初始狀態，Primary Slot中運行的是低版本v1.0 Image，而完成升級后的結束狀態下，Primary Slot中運行的是高版本v2.0 Image，因此完成了一次升級。

從Swap模式的流程可以看出它的一些特點：

支持代碼回滾/回退/降級。由于升級完成后，低版本v1.0 Image依然存儲在芯片中，因此若在高版本v2.0 上發現bug需要修復，則可以重新執行升級程序使得代碼回到v1.0。

由于代碼功能較為復雜，因此Bootloader帶來的代碼量較大。其他條件一致的情況下，Swap模式的代碼是最大的。又由于保留了Scratch area用于代碼交換，因此留給應用程序的空間就更小了。

整個升級過程中對于Primary Slot和Secondary Slot均執行擦和寫各一次，因此Boot時間較長。

由于flash專門劃分了Scratch area用于對兩個Slot進行代碼交換，在升級過程中，會對該區域進行多次擦寫。具體的擦寫次數取決于Scratch area大小和Slot大小，簡單的計算方式為，利用Primary Slot除以Scratch area得到的結果，即對Scratch area的擦除次數。寫入次數和擦除次數相等。