大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是i.MXRT部分型號上新增的FlexSPI Remap功能。
OTA升級設計幾乎是每個量產客戶都繞不開的話題，產品發布后免不了要做固件(App)升級以修復bug或者增加新特性。升級App是個麻煩事，因為處理不好，App被破壞了導致啟動不了，產品就容易變磚，變了磚即使能救回來，也非常影響用戶體驗。
如今基於i.MXRT的客戶量產產品越來越多，關於OTA安全升級的客戶支持也越來越多。早期的i.MXRT型號（比如i.MXRT1050/1020/1015）在做基於FlexSPI NOR Flash的OTA升級時，有一個最大痛點即App版本切換不便，因此后面的i.MXRT型號中（比如i.MXRT1064/1060/1010）新增了FlexSPI的Remap功能。今天痞子衡就來介紹一下這個Remap功能是如何用於安全OTA的。
一、OTA設計中的痛點
1.1 OTA一般設計
在講App版本切換不便痛點前，先給大家簡單介紹一下OTA升級設計過程中處理App版本的一般套路。下面是一個典型的OTA設計中NOR Flash里內容分布，最前面一般是L2 OTA Boot，負責更新升級或者啟動App；接下來是主App區，就是真正實現產品功能的App；然后是Temp區，一般用作App更新臨時緩沖區；最后是User Data區，存放一些固定不變的圖片資源（如果有GUI的話），或者放一些動態保存的系統關鍵數據。
這里面的Temp區設計是一個關鍵，如果沒有Temp區，在OTA升級時只能原地覆蓋主App區（App 1），升級過程中一旦發生意外（比如斷電），系統里就沒有完整App可用了，會導致產品變磚。而有了Temp區作緩存，升級過程就會可靠多了，如下圖所示，新版本App（App 2）首先會被放在Temp區，僅當App 2完整性校驗通過之后，才會從Temp區搬移到主App區，搬移完成之后再擦除Temp區。這樣的設計下，即使App 2下載到Temp區或者App 2往App 1搬移時發生意外，系統里都有完整App用於恢復。
上面介紹的處理App版本的典型設計在實際應用中其實不算特別常用，因為系統中僅存在一份最新的App，其不支持版本回滾。有時候我們的新版本App因為一些原因（比如新增功能有bug）導致運行並不穩定，我們希望能夠回退到上一個已經運行穩定的舊版本App，系統需要保留兩份不同版本App，所以就有了如下改進的OTA設計NOR Flash內容分布，在主App區（App 2）后面增加一個次App區（App 1）。
這時候升級過程稍微復雜一點，如下圖所示，多了一步主App區（App 2）搬移到次App區（App 1）的過程(Step 2)，這也是版本回滾的關鍵。不過萬事都是有代價的，版本回滾的代價就是增加了OTA升級的時間，以及將Flash中App區從兩段划分成三段，導致App最大長度減少了1/3。
1.2 App版本切換痛點
前面介紹了OTA升級設計中管理App版本的兩種方法，注意這里的App都是指在FlexSPI NOR Flash中原地執行(XIP)的App，代碼鏈接在芯片內部SRAM或者外擴RAM的App不在討論范疇（這種Non-XIP屬性的App升級不存在版本切換的痛點）。現在聊XIP App版本切換的痛點：
在上面的圖中你會發現，新版本App最終都會被搬到主App區（就是緊接着L2 OTA Boot后面的第一個App位置），為什么要這么做？這就涉及MCU中App鏈接相關知識了，因為MCU不同於MPU，其沒有MMU組件，不支持虛擬內存，所以App一般都是固定地址鏈接，App代碼體二進制數據僅放在鏈接的位置才可以正常執行，將App拷貝到非鏈接位置是不能運行的。OTA升級中雖然App版本不同，但是這些App都有一個共同的鏈接地址，即都是鏈接在主App區的。
比如下圖OTA系統中使用了一塊8MB的Flash，在i.MXRT里的系統映射起始地址是0x60000000，L2 OTA Boot和User Data各占1MB，剩余6MB被均分成3段，那么App x/2/1都需要從0x60100000地址開始鏈接放中斷向量表。
可能你會說，我們也可以設計不同鏈接地址的App，這樣就不需要將新版本App都往主App區搬移了，是的，原理上可以這么做，但實踐中，需要管理不同鏈接地址的App，導致OTA升級上位機端操作比較復雜，容易出錯（當前待升級的App必須與上一次升級的App鏈接地址不同），因此這種方法不推薦。
所以最大的痛點就是App總要往主App區搬移，既增加了OTA升級時間，也因為搬移操作過多減小了Flash的壽命（總擦寫次數是一定的）。
二、詳解FlexSPI Remap功能
2.1 FlexSPI NOR系統映射地址
我們知道FlexSPI連接的NOR Flash能夠實現XIP，最主要的原因是FlexSPI有對應系統映射空間且NOR Flash自身可以按Byte地址訪問，這里的系統映射空間主要用於AHB方式讀。CPU去從系統映射空間里讀App指令碼，FlexSPI模塊會自動將AHB總線傳來的地址數據請求轉換成IPG命令方式去獲取NOR Flash里的對應指令內容。更多原理可參看 《在串行NOR Flash XIP調試原理》。
i.MXRT1060中分配給FlexSPI的系統映射空間如下，兩個FlexSPI一共分配了496MB。
i.MXRT1010中分配給FlexSPI的系統映射空間如下，一個FlexSPI分配了504MB。
2.2 FlexSPI Remap功能設計
i.MXRT中的Remap設計其實是系統架構層面的，在AHB總線層面做一個地址重定向，並不是在FlexSPI模塊里實現的，這也是為什么Remap相關控制在IOMUXC_GPR寄存器里（設置后Remap立刻生效，但這些寄存器不是非易失性的，普通軟復位就會置位）。下面是Remap控制寄存器（對於含兩個FlexSPI的型號，Remap控制是同時作用的）：
| Remap功能 | 對應控制寄存器 | |
|---|---|---|
| i.MXRT106x | i.MXRT1010 | |
| ADDR_START | IOMUXC_GPR_GPR30 | IOMUXC_GPR_GPR27 |
| ADDR_END | IOMUXC_GPR_GPR31 | IOMUXC_GPR_GPR28 |
| ADDR_OFFSET | IOMUXC_GPR_GPR32 | IOMUXC_GPR_GPR29 |
Remap設計說起來其實特別簡單，就是地址（addr）落在[ADDR_START, ADDR_END]里的AHB訪問，其實際訪問到的是addr + ADDR_OFFSET位置處的數據。（注意ADDR_START, ADDR_END, ADDR_OFFSET都是4KB對齊的）
舉例來看，根據ADDR_OFFSET的大小不同，會有三種情況：第一種是ADDR_OFFSET = ADDR_END - ADDR_START，如下圖所示。這也是OTA中最常用的情況，ADDR_START可設為主App區起始地址，ADDR_END可設為次App區起始地址。
第二種是ADDR_OFFSET > ADDR_END - ADDR_START，如下圖所示：
第三種是ADDR_OFFSET < ADDR_END - ADDR_START，如下圖所示。不過這種情況在實際應用中並不推薦。
2.3 Remap對擦寫Flash的影響
啟用了Remap功能后，很多人會對調用FlexSPI NOR驅動函數去擦寫Flash有點疑惑。其實完全不必要有這種疑惑，擦寫Flash操作走的是FlexSPI IPG命令方式，屬於FlexSPI模塊內部的事情，完全不受上層系統Remap功能影響，你可以就當Remap功能完全不存在，原來怎么做還是怎么做。
下面這段測試代碼是在MIMXRT1060-EVK上跑的，用ROM API驅動擦寫0x60100000地址，擦寫操作前加了一段Remap設置干擾，實測下來Remap設置對擦寫沒有任何影響，復位后去讀Flash，操作的還是原0x60100000地址。其實從測試代碼也能看出端倪，API里傳入是0x100000，這是Flash絕對偏移地址，跟系統映射沒關系。
flexspi_nor_config_t flashConfig;
serial_nor_config_option_t configOption;
configOption.option0.U = 0xc0000007;
uint32_t programBuffer[64];
for (uint32_t i = 0; i < sizeof(programBuffer); i++)
{
*((uint8_t *)programBuffer + i) = (uint8_t)(i & 0xFF);
}
IOMUXC_GPR->GPR30 = 0x60100000;
IOMUXC_GPR->GPR31 = 0x60200000;
IOMUXC_GPR->GPR32 = 0x100000;
g_bootloaderTree->flexSpiNorDriver->get_config(0, &flashConfig, &configOption);
g_bootloaderTree->flexSpiNorDriver->init(0, &flashConfig);
g_bootloaderTree->flexSpiNorDriver->erase(0, &flashConfig, 0x100000, 0x100);
g_bootloaderTree->flexSpiNorDriver->program(0, &flashConfig, 0x100000, programBuffer);
三、FlexSPI Remap解決OTA痛點
有了Remap功能，現在再回到OTA設計，此時我們只需要兩個App分區即可。新版本App（App 2）首先會被放在后Temp區，App 2更新完成且校驗通過之后，直接使用Remap功能將App 2重映射到App 1位置，此舉既不增加額外物理搬移操作，也同時保留了新舊兩份App可以實現版本回滾，而且整個OTA過程僅有一次App擦寫耗時也最短，完美解決痛點。
當Remap功能已被使能，再有新版本App（App 3）更新需求時，其需要被下載到前Temp區，注意Flash擦寫操作都是通過IPG方式實現，所以不受Remap功能干擾，僅需關注絕對物理地址偏移，App下載完成，取消Remap功能即可，如此往復。
至此，i.MXRT部分型號上新增的FlexSPI Remap功能痞子衡便介紹完畢了，掌聲在哪里~~~
歡迎訂閱
文章會同時發布到我的 博客園主頁、CSDN主頁、知乎主頁、微信公眾號 平台上。
微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
