i.MXRT軟復(fù)位后無法從32MB Flash啟動？

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

?

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

?

一、問題描述

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

?

?

有必要重點介紹下 QSPI Flash 啟動設(shè)計細節(jié)，客戶選用的 Flash 型號是 ISSI 的 IS25WP256D，這是一款容量 256Mb 的四線串行 Flash?？蛻魡恿鞒淘O(shè)計的挺復(fù)雜，芯片上電之后，BootROM 負責從 Flash 中 XIP 啟動 L2 loader 程序，L2 loader 運行后從 Flash 中選出最新的一份 Boot 程序（A/B 是雙備份），將其加載到 SDRAM 中執(zhí)行。Boot 程序運行后做一些系統(tǒng)初始化工作，然后直接跳轉(zhuǎn)到 App 中執(zhí)行（XIP），App 才是最終的客戶應(yīng)用程序，這個應(yīng)用程序會完成往 SDRAM 的自拷貝以及跳轉(zhuǎn)執(zhí)行。

?

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

?

?

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

?

二、問題分析

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

?

兩種復(fù)位下主芯片內(nèi)部非易失寄存器狀態(tài)的區(qū)別是否對 BootROM 運行產(chǎn)生了影響？

兩種復(fù)位下主芯片內(nèi) FlexSPI 這個模塊狀態(tài)是否有區(qū)別？

兩種復(fù)位下外掛 Flash 芯片狀態(tài)是否有區(qū)別？

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

?

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

?

三、開始測試

3.1 對比非易失性寄存器

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

?

3.2 逐步精簡 App 代碼

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

?

四、原因分析

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

?

4.1 L2 loader 的 FDCB

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

?

?

4.2 App 讀 Flash 實現(xiàn)

再來看客戶實現(xiàn)的讀 Flash 函數(shù) BigCapRead()，根據(jù)前面的介紹，靜態(tài)圖片數(shù)據(jù)是從 0x60800000 處開始存儲的，因此 0x60800000 - 0x60FFFFFF 范圍內(nèi)的 8MB 數(shù)據(jù)是可以直接 AHB 讀，但是 0x61000000 地址之后的數(shù)據(jù)在上述 BootROM 的配置下無法直接訪問，這也是為什么客戶寫了 BigCapRead()函數(shù)，這個函數(shù)會根據(jù)傳入的地址范圍來判斷數(shù)據(jù)是在低 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?<?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 關(guān)于 Flash 的 3/4 字節(jié)地址

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

?

?

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

?

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

?

?

4.4 解決方案

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

?

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

?

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

?

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