工業產品設計里經常會有冗余程序/備份程序設計的需求，因為在工業環境里要求設備能夠持續穩定運行，不能輕易宕機，但現實環境中常常有各種意外發生，其中一個常見的意外就是設備主控MCU程序被破壞。

為了降低程序損壞這種意外帶來的影響，一個很典型的做法就是增加MCU程序的份數，第一份被破壞，就啟動第二份...，用程序數量的增加來降低啟動失敗率，這屬于概率學手段范疇。

我們知道恩智浦i.MX RT系列MCU內部沒有非易失性存儲器，它需要搭配外部存儲器來工作，可選存儲器類型非常多：NOR Flash, NAND Flash, eMMC, SD卡都行。

其中對于NAND型存儲器，冗余程序設計是必備的，因為NAND本身允許壞塊現象存在，所以不得不做冗余設計。而對于NOR型存儲器，冗余設計則不是必需的，偏偏串行NOR Flash是i.MX RT最常用的搭檔，那該怎么辦？別急，今天痞子衡介紹的就是i.MX RT1010/1060上串行NOR Flash冗余程序設計，恩智浦已經都給你考慮到了。

注：本文所涉及的串行NOR Flash冗余程序設計，不支持早期的i.MX RT1050/1020/1015型號。

一、初識冗余程序啟動

在i.MX RT上可以掛載串行NOR Flash去啟動程序的外設有兩個，分別是FlexSPI和 LPSPI，如下圖所示。

注：并不是所有 i.MXRT 型號都支持 LPSPI 外設掛載存儲器去啟動。

其中連接在FlexSPI 上的 Flash A 屬于主啟動設備，連接在LPSPI上的Flash B屬于備份啟動設備（關于備份設備啟動詳見痞子衡舊文《從Serial(1-bit SPI) EEPROM/NOR恢復啟動》）。

用兩片NOR Flash去完成冗余程序設計當然是沒問題，但也相應增加了硬件成本，而本文今天要討論得不是這種冗余程序設計，我們要聊的是在一片掛載在FlexSPI上的串行 NOR Flash里做冗余程序設計，就是圖中的image 0和image 1。

冗余程序啟動流程其實特別簡單，上電永遠先啟動物理地址靠前的image 0，如果 image 0被破壞了，則啟動image 1。原則上image 0和image 1應該是完全一樣的（鏈接地址也一樣，并且中途不需要搬移這兩份image數據，這個是靠芯片里的一個黑科技做到的，下文會細講），畢竟是冗余設計，不過你要執意放兩份不完全一樣的image，倒也沒問題。

二、實測冗余程序啟動

我們知道i.MX RT芯片上電總是先運行廠商固化好的BootROM，所以冗余程序啟動設計是做在BootROM代碼里的。之前有一篇舊文《了解i.MXRT1060系列ROM中串行NOR Flash啟動初始化流程優化點》中2.1 節其實已經簡單地提到了冗余程序設計，其主要借助了芯片系統FlexSPI地址重映射(Remap)功能，這個功能是在恩智浦后期推出的 i.MX RT1060/1010 等型號上才有的，這也是上文所說的黑科技。關于這個黑科技，痞子衡也有舊文《利用i.MXRT1060,1010上新增的FlexSPI地址重映射(Remap)功能可安全OTA》。

有了FlexSPI Remap黑科技存在，我們就可以將同一份image binary放在Flash中兩個不同位置，并且不用做擦除編程操作來交換其位置，就可以實現各自的啟動執行。如果沒有這個黑科技，我們只能老老實實做數據搬移，這會增加擦除次數從而影響Flash使用壽命。

原理搞清楚了，現在我們在板子上實測一下這個功能，看看如何正確地放兩份image進Flash，哪些情況會導致image 0啟動失敗從而去啟動image 1。

我們就以恩智浦官方MIMXRT1060-EVK開發板為例，這個板子FlexSPI1上掛了兩片 Flash，默認連接的8MB QuadSPI Flash，還有一片64MB HyperFlash（需要做板子改動才能使能）：

2.1 使能冗余程序啟動

使能冗余程序啟動特性很簡單，就是將fuse 0x6E0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET燒錄為非0值即可，根據下面定義，第二份image 偏移地址最大可以設到Flash中0x3FC0000（63.75MB）處：

Remap功能的ADDR_START寄存器固定設為Flash 起始映射地址。

fuse 0x6e0[15:13] - xSPI_FLASH_IMAGE_SIZE，App的最大長度，標識了第一份App的結束地址，該值加上ADDR_START后被填入Remap功能的ADDR_END寄存器。

fuse 0x6e0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET，標識了第二份App的起始地址（在Flash中偏移位置），即填入Remap功能的ADDR_OFFSET寄存器的值。

本次測試，我們就將FLEXSPI_NOR_SEC_IMAGE_OFFSET燒錄為0x10，xSPI_FLASH_IMAGE_SIZE保持默認0，即第二份image 偏移地址在Flash 0x400000（4MB）處，最大image長度也是4MB，可借助MCUBootUtility工具完成Fuse燒錄：

2.2 下載兩份無簽名image進Flash

現在開始準備image，我們就直接用SDK_2.10.1_EVK-MIMXRT1060boardsevkmimxrt1060demo_appsled_blinky例程，簡單直觀。為了便于肉眼分辨效果，我們生成兩個稍微不一樣的image，閃燈間隔時間一個是200ms（image 0 - iled_blinky_delay200ms.bin），另一個是2s（image 1 - iled_blinky_delay2s.bin）：

然后還是借助MCUBootUtility工具，先使用All-In-One操作將image 0下載進Flash，因為是bin文件，所以我們要填入正確的鏈接起始地址（對于i.MX RT1060就是 0x60000000；對于i.MX RT1010應該是0x60000400，具體查看工程鏈接文件便知）。

此外我們使用的是完整的可啟動鏡像文件（包含了全部所需啟動頭），也可以直接在軟件通用編程器界面做下載。

image0下載進Flash后，繼續下載image 1，這時候只能在軟件通用編程器界面操作。這里主要是設置好下載起始地址，前面我們使能冗余程序啟動時在Fuse里設置的偏移地址是0x400000，那么此時下載起始地址就應該是0x400000（對于i.MX RT1060是0x400000；對于i.MX RT1010應該是0x400400）。至此兩份image下載就完成了。

2.3 快速驗證兩份image正確性

現在Flash里有了兩份image，我們來做一個快速驗證，看看image是不是放得符合冗余程序啟動的要求。對于image 0，沒什么好說的，芯片啟動模式設為2'b10 后斷電復位應該可以看到image 0在執行，最重要的是驗證image 1是不是合法。

這里開始涉及到芯片冗余程序啟動流程核心了，當image 0啟動失敗后，芯片BootROM不是立刻去執行image 1的，它用了一個取巧的方式，在一個軟復位不置位的寄存器里（SRC_GPR10）標記了當前狀態，然后調用NVIC_SystemReset()重新進入BootROM執行，第二次BootROM執行時才會去啟動image 1。

所以這也給了我們快速驗證image 1執行的可能性，我們在板子上掛上J-Link仿真器，然后打開J-Link Commander，直接將SRC_GPR10寄存器改寫為0x40000000，再依次執行reset和go命令，這時你應該可以看到image 1正在執行了。

2.4 測試無簽名 image 0 損壞條件

痞子衡之前在《i.MXRT Bootable image格式》一文里介紹過一個可啟動image包含哪些組成部分，其中最簡單的無簽名image應該至少包含FDCB, IVT, BD, App四部分，芯片BootROM也是按序讀取這四部分數據完成程序啟動的。

現在我們嘗試分別破壞這幾個組成部分來看看何種程度的image 0損壞能被BootROM識別出從而去啟動image 1，下面是測試結果。從測試結果來看，除了Image 0 - App的損壞無法檢測外，image 0其余啟動頭的損壞都可以被BootROM識別到。

2.5 能檢測image 0 app損壞的方法

如果不能檢測image app部分的損壞，那這個冗余程序啟動功能就比較雞肋了，畢竟app部分的數據才是整個image核心所在。如果要加上app損壞檢測，需要使能i.MX RT 簽名啟動，還是可以借助MCUBootUtility工具完成全部流程，下載兩份含簽名的image進Flash的過程跟2.2節基本差不多，只是Secure Boot Type里需要選擇 "HAB Signed Image Boot"，含簽名的image 0下載沒什么好說的，All-In-One操作全搞定，含簽名的image 1數據可以通過在通用編程器界面里將含簽名的image 0數據全部讀回得到，這個具體操作就不詳細展開了。

含簽名image 0相比無簽名image 0多了HABdata(csf,cert,signature) 數據段，BootROM在跳轉image之前會根據HAB data數據對image進行驗簽，驗簽通過才做跳轉。

此時再做一次破壞實驗，結果如下，顯然加了簽名的image 0其完整性就有保證了，這時的冗余程序啟動設計才能發揮出最大效果。

來源：恩智浦MCU加油站（作者： 痞子衡）