大家好,我是痞子衡,是正經(jīng)搞技術(shù)的痞子。今天痞子衡給大家分享的是i.MXRT 上使用 16MB 以上 NOR Flash 軟復(fù)位無(wú)法正常啟動(dòng)問(wèn)題的分析解決經(jīng)驗(yàn)。
?
痞子衡這幾天在支持一個(gè) i.MXRT1050 客戶項(xiàng)目,客戶遇到了軟復(fù)位無(wú)法從 32MB NOR Flash 重新啟動(dòng)的問(wèn)題。這個(gè)客戶是做醫(yī)療設(shè)備的,已經(jīng)基于 i.MXRT 做出一款成功的產(chǎn)品了,所以客戶其實(shí)有豐富的 i.MXRT 使用經(jīng)驗(yàn)。目前調(diào)試的項(xiàng)目是客戶的第二款產(chǎn)品,這個(gè)軟復(fù)位無(wú)法啟動(dòng)問(wèn)題已經(jīng)困擾他們很久,但問(wèn)題畢竟不是特別緊急,不影響他們開(kāi)發(fā)進(jìn)度,所以耽擱至今。這次客戶趁著出差蘇州參加勞特巴赫 TRACE32 調(diào)試器培訓(xùn)機(jī)會(huì),讓痞子衡現(xiàn)場(chǎng)幫他們定位問(wèn)題,經(jīng)過(guò)一番調(diào)試和分析,痞子衡終于成功地解決了問(wèn)題,特此將問(wèn)題解決的全過(guò)程記錄下來(lái),供大家參考。
?
一、問(wèn)題描述
在描述問(wèn)題前,首先給大家介紹下客戶的項(xiàng)目設(shè)計(jì),底下是客戶硬件簡(jiǎn)圖??蛻暨x用的 i.MXRT1052 作為主控,掛載了兩個(gè) QSPI Flash,F(xiàn)lexSPI 接口連接的 32MB Flash 用于啟動(dòng)和存放靜態(tài)圖片資源(只需要讀即可),LPSPI 接口連接的 1MB Flash 用于存放運(yùn)行時(shí)狀態(tài)數(shù)據(jù)(需要讀寫(xiě)),此外板子連接了一個(gè)顯示屏,所以還掛載一片 SDRAM 用于顯示緩存,其實(shí) SDRAM 除了顯示緩存功能之外,還用于執(zhí)行 App(QSPI Flash 里的 App 會(huì)自加載到 SDRAM 執(zhí)行)。
?
?
有必要重點(diǎn)介紹下 QSPI Flash 啟動(dòng)設(shè)計(jì)細(xì)節(jié),客戶選用的 Flash 型號(hào)是 ISSI 的 IS25WP256D,這是一款容量 256Mb 的四線串行 Flash??蛻魡?dòng)流程設(shè)計(jì)的挺復(fù)雜,芯片上電之后,BootROM 負(fù)責(zé)從 Flash 中 XIP 啟動(dòng) L2 loader 程序,L2 loader 運(yùn)行后從 Flash 中選出最新的一份 Boot 程序(A/B 是雙備份),將其加載到 SDRAM 中執(zhí)行。Boot 程序運(yùn)行后做一些系統(tǒng)初始化工作,然后直接跳轉(zhuǎn)到 App 中執(zhí)行(XIP),App 才是最終的客戶應(yīng)用程序,這個(gè)應(yīng)用程序會(huì)完成往 SDRAM 的自拷貝以及跳轉(zhuǎn)執(zhí)行。
?
客戶的 App 實(shí)際大小接近 5MB,對(duì)于嵌入式程序來(lái)說(shuō),這個(gè)體量相當(dāng)大了,這也是為什么客戶需要借助專業(yè)的勞特巴赫 TRACE32 調(diào)試器來(lái)分析定位程序邏輯設(shè)計(jì)問(wèn)題。從下圖還可以看到從 0x60800000 開(kāi)始,F(xiàn)lash 中還存放了一些靜態(tài)圖片資源,客戶項(xiàng)目有顯示屏,F(xiàn)lash 里放一些固定圖片數(shù)據(jù)方便 UI 切換。
?
?
介紹完客戶的項(xiàng)目設(shè)計(jì),現(xiàn)在描述客戶的軟復(fù)位無(wú)法重新啟動(dòng)問(wèn)題。其實(shí)這個(gè)問(wèn)題現(xiàn)象很簡(jiǎn)單,就是每次重新上電啟動(dòng),程序都是可以正常運(yùn)行的,但是一旦使用按鍵軟復(fù)位(ONOFF Reset),系統(tǒng)就會(huì)有一定概率起不來(lái)(概率很大,很容易復(fù)現(xiàn)),調(diào)試器連上去會(huì)發(fā)現(xiàn) PC 停留在 BootROM 里,這意味著此時(shí) BootROM 沒(méi)能正常啟動(dòng) L2 loader。
?
二、問(wèn)題分析
讓我們來(lái)分析一下問(wèn)題,這個(gè)問(wèn)題要從兩方面來(lái)考慮:一、板子上芯片的 POR 和軟復(fù)位的區(qū)別;二、軟復(fù)位無(wú)法啟動(dòng)是概率性的,因此痞子衡想到了如下四處疑點(diǎn):
?
兩種復(fù)位下主芯片內(nèi)部非易失寄存器狀態(tài)的區(qū)別是否對(duì) BootROM 運(yùn)行產(chǎn)生了影響?
兩種復(fù)位下主芯片內(nèi) FlexSPI 這個(gè)模塊狀態(tài)是否有區(qū)別?
兩種復(fù)位下外掛 Flash 芯片狀態(tài)是否有區(qū)別?
客戶 App 代碼里是否有某種操作導(dǎo)致了概率性問(wèn)題的發(fā)生?
?
因?yàn)槊看味际擒洀?fù)位重新啟動(dòng)出問(wèn)題,所以客戶板級(jí)供電設(shè)計(jì)不在疑點(diǎn)范圍內(nèi)。雖然問(wèn)題都表現(xiàn)在 BootROM 沒(méi)法加載 L2 loader 執(zhí)行,但 BootROM 本身缺陷也不是我們主要考慮的方向,畢竟 BootROM 是固化在芯片內(nèi)部的,可靠性有一定保證。我們首先要把疑點(diǎn)放在概率性以及兩種復(fù)位的差異上,那么我們從哪里開(kāi)始著手測(cè)試?
?
痞子衡想的是先從第 4 個(gè)疑點(diǎn)開(kāi)始下手,原因是前 3 個(gè)疑點(diǎn)本質(zhì)上都由第 4 個(gè)疑點(diǎn)引起的,客戶代碼的執(zhí)行可能會(huì)改主芯片內(nèi)部非易失性寄存器,也同時(shí)會(huì)操作 FlexSPI 模塊去訪問(wèn)外部 Flash,它是問(wèn)題的引爆點(diǎn)。
?
三、開(kāi)始測(cè)試
3.1 對(duì)比非易失性寄存器
i.MXRT 內(nèi)部有一些非易失性寄存器(比如 IOMUXC_GPR 寄存器組,SRC 寄存器等),這些寄存器僅在 POR 時(shí)才會(huì)被復(fù)位,而普通軟復(fù)位是不會(huì)改變其狀態(tài)的。客戶 App 代碼近 5MB,如果是去肉眼排查是否操作了非易失性寄存器,難免有疏漏。最簡(jiǎn)單的方法就是在正常啟動(dòng)和非正常啟動(dòng)時(shí)分別用調(diào)試器將這些寄存器的值全部保存下來(lái),然后使用文本工具去對(duì)比。經(jīng)測(cè)試,兩種情況下,這些非易失性寄存器并無(wú)區(qū)別,因此這個(gè)疑點(diǎn)被排除。
?
3.2 逐步精簡(jiǎn) App 代碼
現(xiàn)在我們開(kāi)始逐步精簡(jiǎn) App 代碼,由于客戶代碼涉及機(jī)密,所以精簡(jiǎn)的工作由客戶來(lái)做,當(dāng)然客戶也最清楚如何去精簡(jiǎn)他們自己的代碼。一番測(cè)試下來(lái),我們發(fā)現(xiàn) App 代碼里只要不去讀存在 Flash 里的靜態(tài)圖片數(shù)據(jù),就不會(huì)存在軟復(fù)位無(wú)法重新啟動(dòng)問(wèn)題,看起來(lái)我們已經(jīng)找到線索了。
?
四、原因分析
問(wèn)題出在 App 代碼里讀存在 Flash 里的靜態(tài)圖片數(shù)據(jù),這意味著 App 里可能用了特殊的讀 Flash 方法改變了 Flash 狀態(tài),并且這個(gè) Flash 狀態(tài)是非易失性的。謎團(tuán)接近解開(kāi)了,痞子衡讓客戶公布了他們的 L2 loader 里的 FDCB 配置頭以及 App 里的讀 Flash 圖片的代碼實(shí)現(xiàn):
?
4.1 L2 loader 的 FDCB
先來(lái)看客戶的 FDCB 啟動(dòng)頭,客戶僅讓 BootROM 配置 Flash 工作于 50MHz,并且是 1bit SDR Fast Read(命令是 0x0B),這是標(biāo)準(zhǔn) 3 字節(jié)地址讀,因此配置成功后通過(guò) AHB 總線最大可訪問(wèn) 16MB 以內(nèi)的 Flash 空間。因?yàn)榭蛻舻?L2 loader 很小,且存儲(chǔ)在 Flash 的起始地址,所以這樣的配置對(duì)于啟動(dòng)而言沒(méi)有問(wèn)題。
?
?
4.2 App 讀 Flash 實(shí)現(xiàn)
再來(lái)看客戶實(shí)現(xiàn)的讀 Flash 函數(shù) BigCapRead(),根據(jù)前面的介紹,靜態(tài)圖片數(shù)據(jù)是從 0x60800000 處開(kāi)始存儲(chǔ)的,因此 0x60800000 - 0x60FFFFFF 范圍內(nèi)的 8MB 數(shù)據(jù)是可以直接 AHB 讀,但是 0x61000000 地址之后的數(shù)據(jù)在上述 BootROM 的配置下無(wú)法直接訪問(wèn),這也是為什么客戶寫(xiě)了 BigCapRead()函數(shù),這個(gè)函數(shù)會(huì)根據(jù)傳入的地址范圍來(lái)判斷數(shù)據(jù)是在低 16MB 空間還是高 16MB 空間,然后對(duì)地址空間做了一個(gè)切換。
?
#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é)地址
對(duì)于 16MB 以上空間的 Flash,總會(huì)面臨 3/4 字節(jié)地址訪問(wèn)的問(wèn)題,JESD216 規(guī)定了 3/4 字節(jié)地址訪問(wèn)標(biāo)準(zhǔn)命令,對(duì)于 3 字節(jié)地址 Fast Read,其命令是 FRD(0x0B);而對(duì)于四字節(jié)地址 Fast Read,其命令是 4FRD(0x0C)。對(duì)于一個(gè) 32MB 的 Flash,如果僅需要訪問(wèn)低 16MB 空間,可以使用 FRD;如果需要訪問(wèn)高 16MB 空間,則需要使用 4FRD。
?
?
4FRD 相比 FRD 多傳輸了一字節(jié)地址,對(duì)于地址連續(xù)的大塊數(shù)據(jù)訪問(wèn),這個(gè) 1 字節(jié)地址影響不太,但是如果是執(zhí)行代碼或者非連續(xù)數(shù)據(jù)訪問(wèn),4FRD 相比 FRD 還是有效率上的降低的,對(duì)于這個(gè)問(wèn)題,不同的廠家提供了不同的解決方案。
?
客戶選用的這款 Flash 來(lái)自 ISSI,ISSI 的解決方案是在 Flash 內(nèi)部增加一個(gè) Bank Address Register,其 bit0 用于實(shí)時(shí)切換低 Bank 和高 Bank(并且這個(gè)位是非易失性的,僅 POR 才會(huì)復(fù)位,引腳 reset 無(wú)法復(fù)位?。?,當(dāng) bit0 值為 0 時(shí),F(xiàn)RD 命令訪問(wèn)的是低 16MB 空間,而 bit0 置 1 后,F(xiàn)RD 命令此時(shí)實(shí)際訪問(wèn)的是高 16MB 空間(從 AHB 地址上看不出這個(gè)變化)。
?
?
4.4 解決方案
看到這,這個(gè)軟復(fù)位無(wú)法重啟問(wèn)題真相大白了,是由于這顆 Flash 里的內(nèi)部非易失寄存器 BAR[0]的操作導(dǎo)致的,如果軟復(fù)位時(shí)間點(diǎn)恰好在 App 讀了高 16MB 空間(Bank1)里的數(shù)據(jù)之后,此時(shí) Bank 發(fā)生了切換,軟復(fù)位后 BootROM 去啟動(dòng)時(shí)無(wú)法讀到存在低 16MB 空間(Bank0)的有效的 L2 loader。如果軟復(fù)位時(shí)間點(diǎn)發(fā)生在 App 正在讀低 16MB 空間的數(shù)據(jù),那下次還是可以正常啟動(dòng),這就是概率性啟動(dòng)失敗的原因。
?
原因調(diào)查清楚了,問(wèn)題解決方法就很簡(jiǎn)單了,將 L2 loader 里的 FDCB 頭用 4FRD 代替 FRD,這樣 BootROM 配置完成之后,可以直接 AHB 讀全部的 32MB 空間,不需要切換 Bank,因此 App 里的 BigCapRead()函數(shù)里的 Bank 切換操作可以刪掉。
?
這個(gè)經(jīng)驗(yàn)也告訴了我們,當(dāng)使用 16MB 以上 Flash 作為啟動(dòng)設(shè)備時(shí),一定要小心處理好 3/4 字節(jié)地址訪問(wèn)問(wèn)題,不然就可能出現(xiàn)啟動(dòng)問(wèn)題。
?
至此,i.MXRT 上使用 16MB 以上 NOR Flash 軟復(fù)位無(wú)法正常啟動(dòng)問(wèn)題的分析解決經(jīng)驗(yàn)痞子衡便介紹完畢了,掌聲在哪里~~~