大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是序列NAND Flash的兩大特性導致其在i.MXRT FlexSPI下無法XiP。
在嵌入式世界裡，當我們提起XiP裝置（支援程式碼原地執行的儲存器），首先想到的應該是NOR Flash。比如中低端MCU內部通常會整合小容量並行NOR Flash（一般2MB以內），用於存放應用程式；而高效能MCU，往往內部不會整合Flash，需要在板級設計時外掛一片稍大容量的NOR Flash（大部分是序列NOR，一般8MB以上）。
恩智浦i.MXRT系列屬於高效能MCU，需要外掛Flash。i.MXRT本身可以支援串/並行NOR、串/並行NAND四類裝置作為啟動裝置，但在官方參考設計板EVK上，推薦的都是序列NOR Flash型號。官方沒有推薦並行NOR/NAND，這是可以理解的，畢竟相比序列介面Flash，引腳佔用略多，這對I/O資源緊張的MCU專案來說不太討喜。那官方為何不推薦序列NAND作為啟動裝置呢？這主要是序列NAND在i.MXRT下無法XiP，這對專案軟體設計來說有一些限制。NAND無法XiP的原因有兩點，既跟NAND自身特性有關，也跟FlexSPI外設特性有關，且聽痞子衡細說：
一、FlexSPI對於NAND的支援
我們知道在i.MXRT中是FlexSPI外設負責實現序列NOR/NAND Flash裝置的讀寫訪問支援，痞子衡寫過一篇文章 《從頭開始認識i.MXRT啟動頭FDCB裡的lookupTable》，文章詳述了FlexSPI是如何通過lookupTable來支援序列NOR Flash裝置XiP啟動的（這裡主要是讀訪問支援）。
在lookupTable設計裡，其實AHB讀訪問並不是NOR Flash裝置的專利，或者這麼說，FlexSPI外設本身並不在乎連線得是什麼型別的裝置，它就是完全根據使用者在lookupTable裡填入的命令時序按部就班工作而已。
對於四線QSPI NOR，僅需要在lookupTable裡填入一條命令時序（Read有很多種，但都能在一條Sequence裡實現）就可以支援AHB讀。而HyperFlash、HyperRAM和序列NAND等裝置，lookupTable裡一條命令時序搞不定完整讀操作，需要多條命令時序組合完成。
FlexSPI外設支援在lookupTable中聯合多條命令時序去實現AHB讀，通過FlexSPI->FLSHxxCR2暫存器裡的如下兩處功能位來實現。ARDSEQID位指明讀訪問時序在lookupTable中的起始位置(index)，ARDSEQNUM位指明讀訪問時序共佔用幾條命令時序（這也意味著幾條命令時序要按序放在一起）。
比如Micron MT29FxG01序列NAND系列，就需要如下三條命令時序（Page Read + Get Feature + Random Data Read）組合完成讀操作。但是理想很豐滿，現實卻骨感，即使組合這三條命令時序也無法在FlexSPI下實現NAND的XiP。
實際應用時，對於NAND的讀訪問，都是在程式程式碼中先通過IPCMD方式手動傳送Page Read和Get Feature命令，然後藉助lookupTable中的Random Data Read命令實現僅一個Page空間大小的AHB讀，做不到全部NAND空間的自動AHB讀（當然如果你覺得一個Page空間的AHB讀太雞肋，完全可以直接用IPCMD方式去讀Page資料）。
- Note: 關於NAND僅一個Page空間的AHB讀支援再作下詳細解釋。比如NAND的Page大小為2KB，那麼系統裡僅需給NAND分配0x60000000 - 0x600007FF的AHB對映空間，每次對這個空間進行AHB讀之前，都需要先通過IPCMD傳送Page Read和Get Feature，確保NAND處於Page資料輸出的Ready狀態，底下FlexSPI就可以完成這個Page內的任意AHB讀訪問支援。而一旦切到新Page訪問，需要重複上述過程，因此NAND所有Page的訪問都可以在這個2KB的對映空間裡完成的。
二、序列NAND阻礙XiP的兩大特性
到底序列NAND的什麼特性阻礙了XiP，現在痞子衡來揭祕，在揭祕前大家先看一下痞子衡的舊文 《Raw NAND簡介》，先對NAND型Flash有個初步瞭解。下面痞子衡以Micron MT29FxG01型號序列NAND為例介紹其阻礙XiP的兩大特性：
2.1 壞塊導致的非線性儲存
凡是NAND型Flash都繞不開壞塊（Bad Block）問題，這也是NAND Flash區別於NOR Flash的一個重要特點。NAND技術上允許壞塊的存在，這降低了NAND生產工藝要求，因此NAND單位容量價格比NOR低。
NAND內部按粒度從大到小劃分依次為Plane、Block、Page、Byte（如下圖所示），因為壞塊導致了一些Block無法有效儲存資料，這些Block會被標記拉黑，所以從主裝置訪問角度來看，NAND中的資料並不是按地址連續儲存的，壞塊佔據的地址均為無效地址，這就是所謂的非線性儲存，而非線性儲存裝置顯然無法作為XiP裝置。
- 非線性儲存器，對於寫入操作，無法保證應用程式一定放在指定連結的地址（即在Flash中的對應偏移地址），寫入過程中遇到壞塊，會跳過壞塊，而那些壞塊佔據的無效地址極有可能就是應用程式實際連結地址。
2.2 ECC校驗導致的Page Read等待
我們現在假設一種理想情況，NAND中不存在任何壞塊，可以強行把NAND當作線性儲存裝置，這種情況下是不是就可以被用作XiP裝置了呢？很遺憾，FlexSPI外設還是不能正面支援（有替代方法來支援）。
我們來看序列NAND的完整讀時序，0x13（Page Read）是FlexSPI傳送的第一個命令，用於通知NAND主裝置想要訪問Page了，隨後傳送列地址，指明要讀的Page位置，此時NAND便會將內部狀態暫存器裡Busy位標誌起來並進入忙狀態。
在忙狀態時間裡，NAND會從記憶體塊裡將指定的Page資料全部拷貝到臨時快取區（Cache memory），對這一整個Page資料進行ECC校驗，校驗完成後將狀態暫存器裡相應ECC標誌起來以及將Busy位清除掉，然後結束忙狀態，進入資料輸出準備狀態。
由於不知道NAND什麼時候會結束忙狀態，因此FlexSPI需要不斷髮送0x0F（Get Feature命令）去讀取狀態暫存器的值，直到狀態暫存器裡Busy位被清零才能去讀取Page資料，這種邏輯判斷行為在lookupTable裡無法自動實現（NOR讀時序裡無需邏輯判斷）。
如果特意省略讀狀態暫存器的步驟，避免邏輯判斷行為，在lookupTable直接填入Dummy週期來代替行不行呢？理論上倒是可以的。我們來算一下，比如NAND典型的50MHz時脈頻率，一個Dummy Cycle週期耗時20ns，NAND Page Read等待典型值是45us，即2250個Dummy Cycle，lookupTable有16條Sequence，每個Seqence支援8個instruction，每個instruction如果都設為CMD_SDR，引數設最大255，則9個instruction就能滿足這個等待時間。
但即使這麼做能勉強實現NAND Flash的XiP，程式碼實際執行效率也是非常低下的，畢竟涉及到跨Page的指令長跳轉（暫不討論Cache因素）就需要等待45us，這在嵌入式世界裡是不短的時間，系統實時性無法保證，又有什麼意義呢？
至此，序列NAND Flash的兩大特性導致其在i.MXRT FlexSPI下無法XiP痞子衡便介紹完畢了，掌聲在哪裡~~~
歡迎訂閱
文章會同時釋出到我的 部落格園主頁、CSDN主頁、知乎主頁、微信公眾號 平臺上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
