---- 　　大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是**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和軟復位的區別；二、軟復位無法啟動是概率性的，因此痞子衡想到了如下四處疑點： > 1. 兩種復位下主晶片內部非易失暫存器狀態的區別是否對BootROM執行產生了影響？ > 2. 兩種復位下主晶片內FlexSPI這個模組狀態是否有區別？ > 3. 兩種復位下外掛Flash晶片狀態是否有區別？ > 4. 客戶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空間，然後對地址空間做了一個切換。 ```C #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 < FLASH_BIG_CAP_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軟復位無法正常啟動問題的分析解決經驗痞子衡便介紹完畢了，掌聲在哪裡~~~ ### 歡迎訂閱 文章會同時釋出到我的 [部落格園主頁](https://www.cnblogs.com/henjay724/)、[CSDN主頁](https://blog.csdn.net/henjay724)、[知乎主頁](https://www.zhihu.com/people/henjay724)、[微信公眾號](http://weixin.sogou.com/weixin?type=1&query=痞子衡嵌入式) 平臺上。 微信搜尋"__痞子衡嵌入式__"或者掃描下面二維碼，就可以在手機上第一時間看了哦。 ![](http://henjay724.com/image/github/pzhMcu_qrcode_258x