痞子衡這幾天在支援一個i.MXRT1050客戶項目，客戶遇到了軟複位無法從32MB NOR Flash重新啟動的問題。這個客戶是做醫療裝置的，已經基于i.MXRT做出一款成功的産品了，是以客戶其實有豐富的i.MXRT使用經驗。目前調試的項目是客戶的第二款産品，這個軟複位無法啟動問題已經困擾他們很久，但問題畢竟不是特别緊急，不影響他們開發進度，是以耽擱至今。這次客戶趁着出差蘇州參加勞特巴赫TRACE32調試器教育訓練機會，讓痞子衡現場幫他們定位問題，經過一番調試和分析，痞子衡終于成功地解決了問題，特此将問題解決的全過程記錄下來，供大家參考。
大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是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，它是問題的引爆點。
i.MXRT内部有一些非易失性寄存器（比如IOMUXC_GPR寄存器組，SRC寄存器等），這些寄存器僅在POR時才會被複位，而普通軟複位是不會改變其狀态的。客戶App代碼近5MB，如果是去肉眼排查是否操作了非易失性寄存器，難免有疏漏。最簡單的方法就是在正常啟動和非正常啟動時分别用調試器将這些寄存器的值全部儲存下來，然後使用文本工具去對比。經測試，兩種情況下，這些非易失性寄存器并無差別，是以這個疑點被排除。
現在我們開始逐漸精簡App代碼，由于客戶代碼涉及機密，是以精簡的工作由客戶來做，當然客戶也最清楚如何去精簡他們自己的代碼。一番測試下來，我們發現App代碼裡隻要不去讀存在Flash裡的靜态圖檔資料，就不會存在軟複位無法重新啟動問題，看起來我們已經找到線索了。
問題出在App代碼裡讀存在Flash裡的靜态圖檔資料，這意味着App裡可能用了特殊的讀Flash方法改變了Flash狀态，并且這個Flash狀态是非易失性的。謎團接近解開了，痞子衡讓客戶公布了他們的L2 loader裡的FDCB配置頭以及App裡的讀Flash圖檔的代碼實作：
先來看客戶的FDCB啟動頭，客戶僅讓BootROM配置Flash工作于50MHz，并且是1bit SDR Fast Read（指令是0x0B），這是标準3位元組位址讀，是以配置成功後通過AHB總線最大可通路16MB以内的Flash空間。因為客戶的L2 loader很小，且存儲在Flash的起始位址，是以這樣的配置對于啟動而言沒有問題。
再來看客戶實作的讀Flash函數BigCapRead()，根據前面的介紹，靜态圖檔資料是從0x60800000處開始存儲的，是以0x60800000 - 0x60FFFFFF範圍内的8MB資料是可以直接AHB讀，但是0x61000000位址之後的資料在上述BootROM的配置下無法直接通路，這也是為什麼客戶寫了BigCapRead()函數，這個函數會根據傳入的位址範圍來判斷資料是在低16MB空間還是高16MB空間，然後對位址空間做了一個切換。
對于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位址上看不出這個變化）。
看到這，這個軟複位無法重新開機問題真相大白了，是由于這顆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軟複位無法正常啟動問題的分析解決經驗痞子衡便介紹完畢了，掌聲在哪裡~~~
文章會同時釋出到我的 部落格園首頁、CSDN首頁、知乎首頁、微信公衆号 平台上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
最後歡迎關注痞子衡個人微信公衆号【痞子衡嵌入式】，一個專注嵌入式技術的公衆号，跟着痞子衡一起玩轉嵌入式。
衡傑(痞子衡)，目前就職于恩智浦MCU系統部門，擔任嵌入式系統應用工程師。
專欄内所有文章的轉載請注明出處：http://www.cnblogs.com/henjay724/
與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]
可以關注痞子衡的Github首頁 https://github.com/JayHeng，有很多好玩的嵌入式項目。
關于專欄文章有任何疑問請直接在部落格下面留言，痞子衡會及時回複免費(劃重點)答疑。
痞子衡郵箱已被私信擠爆，技術問題不推薦私信，堅持私信請先掃碼付款(5元起步)再發。