基于Bank Swap的STM32 軟件升級方案

陳藝芃，林飛浪，郭大鳴，陳飛明

（1.武漢郵電科學研究院，湖北武漢 430074；2.烽火通信科技股份有限公司，湖北武漢 430073；3.武漢紡織大學，湖北 武漢 430073）

在嵌入式板級應用的開發過程中，系統設備的軟件代碼不是一次開發就能夠完成的，需要進行多次的修改、更新和壓縮操作來完善。針對測試人員在測試過程中發現的一些問題和客戶在使用過程中提出的一些新的功能需求，軟件開發人員需要提供一種合理的代碼升級方式以便對設備進行在線升級。

嵌入式設備軟件升級通常采用移植一個適用于該系統的獨立BootLoader的方式，BootLoader 指啟動引導程序，是系統加電后運行的第一段軟件代碼，通過這段代碼，可以初始化硬件設備，建立內存空間的映射圖，以便為最終調用操作系統內核提供正確的環境[1-2]。使用這種方式存在的問題是升級前需要將MCU 片內Flash 舊版本擦除，為新版本的寫入釋放空間，這勢必導致設備停機[3-5]。

近年來常用的Bank Swap 方式可以解決上述問題。Bank Swap是ST公司對旗下的STM32F4、STM32F7系列芯片提供的MCU 片內Dual Bank Flash 進行交換的方式，它在執行程序的同時可對另一個Bank 進行擦除和編程操作。利用這個特性，可實現在線程序更新。在嵌入式設備軟件初版代碼的開發過程中，初始代碼可能會較為龐大，對于比較復雜的設備，需要很大的運行內存容量，而Bank Swap 方式要將MCU 片內Flash 分為兩部分運行，可用運存容量減半，直接采用Bank Swap 方式可能會影響開發過程中對軟件的調試。

針對上述問題，文中設計了一種將獨立BootLoader和Bank Swap 結合的方案。在開發初期先使用BootLoader+APP的方式過渡，并設計BootLoader+APP的版本，使其具備升級轉換成Bank Swap 模式的功能。待開發后期壓縮工程的目標文件小于1M（STM32F4 片內Flash 容量為2 M），通過修改程序中的標識位完成模式切換，即可以實現不停機升級操作,滿足所有開發需求的同時將外部Flash 棄用，可以停止對片外BootLoader的維護，減少運維工作量。

1 獨立BootLoader啟動方式

對于STM32平臺的啟動引導和代碼升級，常用的方式是采用BootLoader+APP的方式。在此可以移植一個適用于該系統的獨立BootLoader，將MCU片內Flash劃分為BootLoader 區和User Code 區[6]。BootLoader用于實現通過某種通信方式(如USB、USART)接收程序或數據，執行對APP 代碼的更新,通常存儲于Flash的起始地址(0x08000000)。User Code 區運行的是產品實現業務邏輯正常運行的APP 代碼，該部分代碼存儲在片內Flash 中的BootLoader 區之后，需要進行相對的地址偏移；而緩存的升級數據可以存儲在片外Flash 中，以節約內部存儲空間。獨立BootLoader 模式升級數據流向圖如圖1 所示。

圖1 獨立BootLoader模式升級數據流向圖

圖1 箭頭所指為數據流向，在APP 中接收升級數據并緩存到外部Flash。升級時MCU 重啟進入BootLoader，BootLoader 檢查是否需要更新，若需要更新，則讀取緩存在外部Flash的升級數據包，進行后續升級動作，引導代碼進入應用區；若BootLoader沒有檢測到需要更新，開始檢測應用區代碼是否完整，如果完整則引導進入應用區，否則停留在Boot中，提示上位機等待BootLoader 引導程序進入應用區運行[7-9]。應用接收到升級命令，在Flash 做一個升級動作標記，記錄升級的版本等信息。重啟MCU 進入BootLoader 進行升級。

2 Bank Swap啟動方式

近年來利用Bank Swap 方式進行軟件升級也越發普遍。對于STM32F4 系列的MCU，可以通過配置Dual Bank和Dual Boot 項，改變RWW 特性，從而實現Bank Swap 方式，以解決上述問題[10]。

2.1 Dual Bank模式下的Flash編排

配置成Dual Bank 模式后，片內Flash的地址將重新編排。如圖2 所示，Bank1的地址為0x08000 000～0x080FFFFF，Bank2的地址為0x08100000～0x081FFFFF，扇區的數量從12 增加到了24，均勻分配于兩個Bank 之中。每個Bank 中對應扇區的容量都為之前的一半，Dual Bank 模式時讀寫的最小單元為128 bit，也是Single Bank的一半。

圖2 切換Dual Boot模式Flash分區示意圖

將Single Bank 轉變成Dual Bank 是通過縱向劃分實現的。讀取寬度由8 words 變成了4 words。如圖3 所示，將Flash 控制器的地址線和數據線由一組分成兩組，高位一組，低位一組，這樣就可以實現在一個Bank 執行讀操作時，對另一個Bank 進行寫操作。

圖3 Dual Boot模式Flash的劃分方式圖

另外需要注意的是模式轉換前，存儲數據地址的變動。假設Sector1 中存儲著連續的256 bit 數據，由于采用縱向劃分，在劃分過程中高地址被重新編排，分別存儲到Sector1和Sector13的對應位置中，跟原來的地址不再連續，導致Flash 保存的內容被完全打亂了。即使切換前只使用到MCU 片內Flash的前半部分，也需要在模式切換后將原有的數據擦除并重新燒錄到設定的Bank 中。

當Flash配置成Dual Bank模式時，STM32F4 可以實現Dual Boot 模式，即雙啟動方式。程序可以選擇從Bank1啟動，也可從Bank2啟動。這個操作是由保存在片內MCU的System Memory中的BootLoader 實現的，BootLoader 判斷到當前是Dual Bank 模式且配置Dual Boot 選項，則根據用戶配置的啟動地址，選擇從Bank1 啟動或者從Bank2 啟動。

2.2 RWW在Dual Bank中的實現機制

RWW（Read-While-Write，RWW）是指在系統做運行讀取操作的同時支持擦除寫入操作的特性。由圖4 可以看出，當使用Single Bank 模式時，對Flash的寫操作會導致其他讀操作被掛起，程序停止執行。而Dual Bank 模式中，可以在一個Bank的程序執行過程中對另一個Bank 執行寫操作。

圖4 RWW特性示意圖

Bank Swap 方式利用Dual Bank 中的RWW 特性，在實現升級的同時其他任務可以繼續運行，不影響系統正常功能的運轉，并保證了升級期間片內另一個Bank 舊版本的完整性。

3 軟件升級方案解析

鑒于上述分析，結合工程實際需要，考慮到防止User Code 在開發初期超出單Bank 最大容量的可能（STM32F4 片內Flash 容量為2 M），最終決定選擇獨立BootLoader和Bank Swap 結合的方案。在開發初期先使用BootLoader+APP的方式過渡，并將此獨立BootLoader的版本設計為具備升級轉換成Bank Swap模式的功能。待開發后期壓縮工程的目標文件小于1M，通過修改程序中的標識位完成模式切換，升級操作完全在MCU 片內進行，通過Bank 切換即可以實現不停機升級操作。更新為Bank Swap 穩定版后可以停止對片外BootLoader的維護，減少運維工作量。

3.1 配置準備

將Flash 配置成Dual Bank 模式，片內Flash 地址進行重新編排。通過Flash_OPTCR 寄存器配置User Option Byte 中的nDBANK=0。Option Byte 不能直接寫，需要通過Flash_OPTCR 寄存器來操作。

配置Dual Bank 模式完成后，即可開啟Dual Boot模式。通過Flash_OPTCR 寄存器，配置Option Byte中的nDBOOT=0，即可配置成Dual Boot 模式。

Flash 配置成兩個Bank后，可實現Bank之間直接進行地址交換的功能。配置SYSCFG_MEMRMP寄存器中的SWP_FB，來選擇是否交換。當SWP_FB的值為0 時，Bank1的基地址為0x08000000，Bank2的基地址為0x08 100000；當SWP_FB的值為1 時，兩個Bank的基地址對換。由此可以看出，無論從哪個Bank 啟動，都能保證起始基地址為0x08000000。

3.2 獨立BootLoader模式的業務流程

獨立BootLoader模式業務流程如圖5所示?？梢钥闯鯞ootLoader和APP是互斥的，BootLoader運行時APP不運行，APP運行時BootLoader不運行。APP 接收完升級數據后，自身無法更新自身的代碼，必須重啟進入BootLoader才能完成APP代碼的更新[11]。App 在Flash 中的某個位置記錄升級動作，然后重啟進入BootLoader，BootLoader檢查Flash中相應位置的標志位，如需升級，則讀取代碼緩存區的新版本程序，對APP 進行更新，更新完成后清空該標志位。

圖5 獨立BootLoader模式業務流程圖

將新程序寫入User Code 區，發生斷電等意外時，APP 可能不完整，下次啟動BootLoader 后會對APP的完整性進行檢查，如果發現APP 不完全（這種情況多數是上次升級刷機時，沒有完成Flash的寫操作便被中斷導致的，那么升級包緩存區還保留著升級程序），則檢查升級包緩存區的升級文件是否完整[12]。如果完整，則將其再次恢復到APP 代碼區，否則停留在BootLoader，并主動請求升級。

為執行BootLoader 升級模式轉換為Bank Swap模式的指令，在代碼中增加了一個標識，每次升級的時候，BootLoader 識別該標識，如果沒有轉換成Swap方式的需求，則按原設計，將代碼升級到User Code區；假如有轉換成Bank Swap 模式的需求，則將代碼更新到Bank2，同時設置boot address 啟動地址為Bank2的起始地址，確認設置為Dual Boot 模式，然后重啟進入Bank2 運行新程序。新程序應當具備Swap Bank 模式的升級能力。

3.3 Bank Swap模式的業務流程

升級為Swap 模式后，進入Bank2 運行，便切換到Bank Swap 模式了，此后，新的業務流程如圖6 所示。在Bank Swap 模式中，程序也是永遠運行于起始地址是0x8000000的片內Flash 中，但有可能是Bank1，也有可能是Bank2，因為執行Bank Swap 操作后，Bank2的起始地址也是0x8000000。因此，升級的過程中，新程序總是燒錄在地址0x8100000 中，經過Swap，0x8100000 所屬的Bank的地址便會變成0x8000000。需要在程序中通過讀取Option Byte 中的某些位的值來判斷當前程序運行在哪個Bank，如BOOT_ADD0 寄存器或者SWP_BF的值。

圖6 Bank Swap模式業務流程圖

Bank Swap 操作是System Memory 中的固件Boot Loader 完成的，這個BootLoader是STM32自帶的[13]。只需要配置代碼的啟動地址和Flash的Dual Boot 模式，System Memory 中的BootLoader 會完成Bank Swap操作，并引導程序到指定的Bank 運行。

4 實驗驗證與分析

按照上述方案，采用以STM32F429IIT6 為核心設計的一個電源監控系統為例，通過網管對系統進行升級驗證。

如圖7 所示，準備好Tftp 服務器以及需要分別先后燒錄的兩個bin 文件[14]。為了更明顯地感知升級完成的現象，文中使用同一個工程，改變osdelay 參數將LED 測試燈閃爍的頻率設置成不一樣的值，0100.bin 為LED 快閃燒錄到地址0x8000000，閃爍延時設為300 ms；0101.bin 為LED 慢閃燒錄到地址0x8100000，閃爍延時設為2 000 ms。

圖7 Tftp傳輸工具和bin文件

打開Tftp 客戶端設置界面會自動地讀取本地的IP 地址，在下方添加主機信息和端口號以及想要傳輸的bin 文件所在的位置，如圖8 所示[15-16]。

圖8 Tftp傳輸參數填寫

使用SecureCRT 接收設備側串口上報的信息，如圖9 所示。可以看到在升級前系統運行在Bank1 中，點擊Tftp 中的Put 傳輸新文件，設備執行更新命令，檢查CRC 校驗后自動識別非運行Bank（Bank2）的Flash 地址，寫入更新信息并完成檢查。在升級過程中設備正常運行，LED的閃爍頻率并未發生變化。重啟后串口提示系統已經切換到Bank2中運行，LED的閃爍頻率也明顯降低，說明設備成功完成升級。

圖9 SecureCRT接收的串口信息

重復上述操作將0100.bin 文件燒錄進Bank1 中，升級過程中LED 持續慢閃，重啟后閃爍變快，恢復為初始頻率。說明此時系統可以在不影響運行的情況下，完成Read-While-Write 升級工作。

為了驗證設備在Bank Swap 模式下升級過程中出現的異常停機情況不會影響設備更新前運行程序的完整性，在升級期間拔掉設備與主機間的通信線，此時升級中斷。重新上電后發現監控單元上的軟件為上一次的版本信息，與網管上待升級版本的信息不一致，說明升級失敗后監控單元自動退回到升級前的版本運行，沒有被升級所破壞。

5 結論

該文以STM32F4 軟件升級的現實案例為背景，為實現升級過程中不打斷設備運行的RWW 特性，以及升級異常時具有自動退回到升級前版本的能力，同時兼顧開發初期代碼量較大影響調試的現實問題，設計了一種獨立BootLoader 與Bank Swap 相結合的方案。獨立BootLoader 方案能提供更大的容量供User Code 使用，作為開發期間的過渡；而Bank Swap 方案使用System Memory 中自帶的BootLoader啟動，不需要開發和維護獨立的BootLoader，可以最終實現RWW 特性以及升級失敗時保護的功能。兩種模式間通過標志位實現切換。最后通過Tftp 進行升級，通過LED 燈的運行狀態以及串口上報的信息，驗證了Bank的切換功能以及升級過程中系統可以正常運行的特性，實現了系統的設計要求。該設計對于嵌入式板級應用的開發升級具有較大的意義。