---

大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是i.MXRT上使用16MB以上NOR Flash軟復位無法正常啟動問題的分析解決經驗。

痞子衡這幾天在支持一個i.MXRT1050客戶項目，客戶遇到了軟復位無法從32MB NOR Flash重新啟動的問題。這個客戶是做醫療設備的，已經基于i.MXRT做出一款成功的產品了，所以客戶其實有豐富的i.MXRT使用經驗。目前調試的項目是客戶的第二款產品，這個軟復位無法啟動問題已經困擾他們很久，但問題畢竟不是特別緊急，不影響他們開發進度，所以耽擱至今。這次客戶趁著出差蘇州參加勞特巴赫TRACE32調試器培訓機會，讓痞子衡現場幫他們定位問題，經過一番調試和分析，痞子衡終于成功地解決了問題，特此將問題解決的全過程記錄下來，供大家參考。

一、問題描述

在描述問題前，首先給大家介紹下客戶的項目設計，底下是客戶硬件簡圖。客戶選用的i.MXRT1052作為主控，掛載了兩個QSPI Flash，FlexSPI接口連接的32MB Flash用于啟動和存放靜態圖片資源(只需要讀即可)，LPSPI接口連接的1MB Flash用于存放運行時狀態數據(需要讀寫)，此外板子連接了一個顯示屏，所以還掛載一片SDRAM用于顯示緩存，其實SDRAM除了顯示緩存功能之外，還用于執行App(QSPI Flash里的App會自加載到SDRAM執行)。

有必要重點介紹下QSPI Flash啟動設計細節，客戶選用的Flash型號是ISSI的IS25WP256D，這是一款容量256Mb的四線串行Flash。客戶啟動流程設計的挺復雜，芯片上電之后，BootROM負責從Flash中XIP啟動L2 loader程序，L2 loader運行后從Flash中選出最新的一份Boot程序(A/B是雙備份)，將其加載到SDRAM中執行。Boot程序運行后做一些系統初始化工作，然后直接跳轉到App中執行(XIP)，App才是最終的客戶應用程序，這個應用程序會完成往SDRAM的自拷貝以及跳轉執行。

客戶的App實際大小接近5MB，對于嵌入式程序來說，這個體量相當大了，這也是為什么客戶需要借助專業的勞特巴赫TRACE32調試器來分析定位程序邏輯設計問題。從下圖還可以看到從0x60800000開始，Flash中還存放了一些靜態圖片資源，客戶項目有顯示屏，Flash里放一些固定圖片數據方便UI切換。

介紹完客戶的項目設計，現在描述客戶的軟復位無法重新啟動問題。其實這個問題現象很簡單，就是每次重新上電啟動，程序都是可以正常運行的，但是一旦使用按鍵軟復位(ONOFF Reset)，系統就會有一定概率起不來(概率很大，很容易復現)，調試器連上去會發現PC停留在BootROM里，這意味著此時BootROM沒能正常啟動L2 loader。

二、問題分析

讓我們來分析一下問題，這個問題要從兩方面來考慮：一、板子上芯片的POR和軟復位的區別；二、軟復位無法啟動是概率性的，因此痞子衡想到了如下四處疑點：

兩種復位下主芯片內部非易失寄存器狀態的區別是否對BootROM運行產生了影響？

兩種復位下主芯片內FlexSPI這個模塊狀態是否有區別？

兩種復位下外掛Flash芯片狀態是否有區別？

客戶App代碼里是否有某種操作導致了概率性問題的發生？

因為每次都是軟復位重新啟動出問題，所以客戶板級供電設計不在疑點范圍內。雖然問題都表現在BootROM沒法加載L2 loader執行，但BootROM本身缺陷也不是我們主要考慮的方向，畢竟BootROM是固化在芯片內部的，可靠性有一定保證。我們首先要把疑點放在概率性以及兩種復位的差異上，那么我們從哪里開始著手測試？

痞子衡想的是先從第4個疑點開始下手，原因是前3個疑點本質上都由第4個疑點引起的，客戶代碼的執行可能會改主芯片內部非易失性寄存器，也同時會操作FlexSPI模塊去訪問外部Flash，它是問題的引爆點。

三、開始測試

3.1 對比非易失性寄存器

i.MXRT內部有一些非易失性寄存器(比如IOMUXC_GPR寄存器組，SRC寄存器等)，這些寄存器僅在POR時才會被復位，而普通軟復位是不會改變其狀態的。客戶App代碼近5MB，如果是去肉眼排查是否操作了非易失性寄存器，難免有疏漏。最簡單的方法就是在正常啟動和非正常啟動時分別用調試器將這些寄存器的值全部保存下來，然后使用文本工具去對比。經測試，兩種情況下，這些非易失性寄存器并無區別，因此這個疑點被排除。

3.2 逐步精簡App代碼

現在我們開始逐步精簡App代碼，由于客戶代碼涉及機密，所以精簡的工作由客戶來做，當然客戶也最清楚如何去精簡他們自己的代碼。一番測試下來，我們發現App代碼里只要不去讀存在Flash里的靜態圖片數據，就不會存在軟復位無法重新啟動問題，看起來我們已經找到線索了。

四、原因分析

問題出在App代碼里讀存在Flash里的靜態圖片數據，這意味著App里可能用了特殊的讀Flash方法改變了Flash狀態，并且這個Flash狀態是非易失性的。謎團接近解開了，痞子衡讓客戶公布了他們的L2 loader里的FDCB配置頭以及App里的讀Flash圖片的代碼實現：

4.1 L2 loader的FDCB

先來看客戶的FDCB啟動頭，客戶僅讓BootROM配置Flash工作于50MHz，并且是1bit SDR Fast Read(命令是0x0B)，這是標準3字節地址讀，因此配置成功后通過AHB總線最大可訪問16MB以內的Flash空間。因為客戶的L2 loader很小，且存儲在Flash的起始地址，所以這樣的配置對于啟動而言沒有問題。

4.2 App讀Flash實現

再來看客戶實現的讀Flash函數BigCapRead()，根據前面的介紹，靜態圖片數據是從0x60800000處開始存儲的，因此0x60800000 - 0x60FFFFFF范圍內的8MB數據是可以直接AHB讀，但是0x61000000地址之后的數據在上述BootROM的配置下無法直接訪問，這也是為什么客戶寫了BigCapRead()函數，這個函數會根據傳入的地址范圍來判斷數據是在低16MB空間還是高16MB空間，然后對地址空間做了一個切換。

#define?FLASH_BIG_CAP_SIZE?(0x1000000)

static?status_t?flexspi_nor_select_segment(uint32_t?base,?uint8_t?seg){
????qspi_transfer_t?flashXfer;
????status_t?status?=?Success;
????uint32_t?writeValue?=?0x00;
????uint32_t?readValue?=?0x00;

????flexspi_nor_write_enable(base,?0,?true);

????flexspi_nor_read_volatilebankaddr_reg(base,?&readValue);
????if?((readValue?&?0x01)?==?(seg?&?0x1))
????{
????????return?Success;
????}

????writeValue?=?seg?&?0x1;
????flexspi_nor_write_volatilebankaddr_reg(base,?writeValue);

????flexspi_nor_read_volatilebankaddr_reg(base,?&readValue);
????if?(readValue?!=?writeValue)
????{
????????return?Failure;
????}

????flexspi_nor_wait_bus_busy(base);
????return?Success;
}

static?UINT32?BigCapRead(struct?flash_dev*?dev,?UINT32?start_addr,?UCHAR?*buffer,?UINT32?size){
????UINT32?tempLen?=?0;
????UINT32?result?=?0;
????if?(start_addr?>=?FLASH_BIG_CAP_SIZE)
????{
????????flexspi_nor_select_segment(dev->base,?1);
????????start_addr?=?start_addr?-?FLASH_BIG_CAP_SIZE;
????????result?=?Read(dev,?start_addr,?buffer,?size);
????}
????else
????{
????????if?(start_addr?+?size?????????{
????????????flexspi_nor_select_segment(dev->base,?0);
????????????result?=?Read(dev,?start_addr,?buffer,?size);
????????}
????????else
????????{
????????????tempLen?=?FLASH_BIG_CAP_SIZE?-?start_addr;
????????????flexspi_nor_select_segment(dev->base,?0);
????????????result?=?Read(dev,?start_addr,?buffer,?tempLen);
????????????flexspi_nor_select_segment(dev->base,?1);
????????????result?=?Read(dev,?0,?buffer?+?tempLen,?size?-?tempLen);
????????}
????}
????return?result;
}

4.3 關于Flash的3/4字節地址

對于16MB以上空間的Flash，總會面臨3/4字節地址訪問的問題，JESD216規定了3/4字節地址訪問標準命令，對于3字節地址Fast Read，其命令是FRD(0x0B)；而對于四字節地址Fast Read，其命令是4FRD(0x0C)。對于一個32MB的Flash，如果僅需要訪問低16MB空間，可以使用FRD；如果需要訪問高16MB空間，則需要使用4FRD。

4FRD相比FRD多傳輸了一字節地址，對于地址連續的大塊數據訪問，這個1字節地址影響不太，但是如果是執行代碼或者非連續數據訪問，4FRD相比FRD還是有效率上的降低的，對于這個問題，不同的廠家提供了不同的解決方案。

客戶選用的這款Flash來自ISSI，ISSI的解決方案是在Flash內部增加一個Bank Address Register，其bit0用于實時切換低Bank和高Bank(并且這個位是非易失性的，僅POR才會復位，引腳reset無法復位！)，當bit0值為0時，FRD命令訪問的是低16MB空間，而bit0置1后，FRD命令此時實際訪問的是高16MB空間(從AHB地址上看不出這個變化)。

4.4 解決方案

看到這，這個軟復位無法重啟問題真相大白了，是由于這顆Flash里的內部非易失寄存器BAR[0]的操作導致的，如果軟復位時間點恰好在App讀了高16MB空間(Bank1)里的數據之后，此時Bank發生了切換，軟復位后BootROM去啟動時無法讀到存在低16MB空間(Bank0)的有效的L2 loader。如果軟復位時間點發生在App正在讀低16MB空間的數據，那下次還是可以正常啟動，這就是概率性啟動失敗的原因。

原因調查清楚了，問題解決方法就很簡單了，將L2 loader里的FDCB頭用4FRD代替FRD，這樣BootROM配置完成之后，可以直接AHB讀全部的32MB空間，不需要切換Bank，因此App里的BigCapRead()函數里的Bank切換操作可以刪掉。

這個經驗也告訴了我們，當使用16MB以上Flash作為啟動設備時，一定要小心處理好3/4字節地址訪問問題，不然就可能出現啟動問題。

至此，i.MXRT上使用16MB以上NOR Flash軟復位無法正常啟動問題的分析解決經驗痞子衡便介紹完畢了，掌聲在哪里~~~

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的idea 升级到2020后 无法启动_i.MXRT软复位后无法从32MB Flash启动？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。