大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是一種靈活的i.MXRT下多串列NOR Flash型號選擇的量產方案。 對於以 i.MXRT 這類沒有內部 NVM (Non-Volatile Memory) 的 MCU 為主控的項目來說，為其選配一顆 NVM 作為代碼存儲器是頭等大事， ...
大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是一種靈活的i.MXRT下多串列NOR Flash型號選擇的量產方案。
對於以 i.MXRT 這類沒有內部 NVM (Non-Volatile Memory) 的 MCU 為主控的項目來說，為其選配一顆 NVM 作為代碼存儲器是頭等大事，而串列 NOR Flash 是最常見的 NVM 選擇。串列 NOR Flash 要能被 i.MXRT 正常啟動，其固定偏移處（0x0/0x400）一般要求放置一個配套啟動頭（FDCB），系統上電 BootROM 會用 30MHz 1bit SPI SDR 時序模式去讀取這個啟動頭來獲取當前 Flash 的相關屬性（主要是用戶設定的時序模式）從而進一步配置片內 FlexSPI 模塊以指定的時序模式去啟動 Flash 里的固件應用程式。
到了項目量產階段，尤其是出貨量大的消費類產品，我們往往不會僅選擇某一 Flash 廠商產品（價格因素，供貨因素等），這時候就不得不考慮一個問題，如果選擇的是特性不完全一致的兩顆 Flash，那麼下載進 Flash 的固件應用程式能不能保持一樣（其實主要就是下圖中的 FDCB1/2 差異問題怎麼解決）？今天痞子衡就跟大家討論一下這個問題：
- Note：本文主要針對的是普通四線 QuadSPI / 八線 OctalSPI 類型的串列 NOR Flash。
一、影響多Flash型號量產的因素
我們知道導致下載進不同 Flash 里的固件程式有差異的主要原因是 i.MXRT 配套啟動頭（FDCB），這個 FDCB 描述了 Flash 的基本信息（Device 容量、速度、讀模式命令等），Flash 屬性不同，FDCB 也會跟著變化，所以我們先來介紹下有哪些可能的因素會影響 FDCB 內容：
1.1 QE bit位置
首先是 QE bit 使能操作的差異。很多 Flash 出廠時 QE bit 並沒有被使能，量產過程中燒錄器有時候也未必去使能 QE bit（一線模式編程相比 Multi I/O 模式編程對量產時間影響不大），這種情況在 FDCB 里需要加上使能 QE bit 操作，而 QE bit 在 Flash 內部寄存器里的定義以及寫入命令有好幾種，詳見痞子衡舊文《影響下載/啟動的常見因素之QE bit》。
1.2 READ命令中Dummy Cycles數
使能 QE bit 是為了能讓 Flash 工作在 Multi I/O Fast READ 模式，但這時候 READ 時序里會有 Dummy Cycles 周期（即 Flash 接收到主設備發來的讀命令從而準備相應數據的反應時間）。Flash 的不同工作頻率對應的最小 Dummy Cycles 不同，不同廠商關於 Dummy Cycles 數要求也不同，此外如果 Flash 里的預設 Dummy Cycle 不是對應最高工作頻率的話，要想讓 Flash 工作在最高頻率還需要額外設置 Flash 相應寄存器來修改 Dummy Cycle（這裡的設置方法也不同），這些 Dummy Cycle 設定都要體現在 FDCB 里，詳見痞子衡舊文《調整Flash工作頻率也需同步設Dummy Cycle》。
1.3 地址3B/4B模式切換
對於不高於 16MB 容量的 Flash，在 READ 時序里一般使用三位元組地址就行了，但是超過 16MB 的 Flash ，對其訪問就會涉及三位元組地址以及四位元組地址選擇問題，因此避不可免地要考慮 Flash 地址模式切換問題，不同廠商的地址模式設計以及切換操作也略有不同，FDCB 里同樣要考慮這些，詳見痞子衡舊文 《16MB以上NOR Flash使用註意》。
1.4 QPI/OPI模式進入
如果為了追求極限執行性能，一般還會考慮將 Flash 從 SPI 模式切換到 QPI/OPI 模式，這裡不同廠商的模式切換設計也可能略有不同，FDCB 也要負責這個工作，詳見痞子衡舊文《使能串列NOR Flash的QPI/OPI模式》。
1.5 DTR/Continuous read性能模式
當然還有一些其它關於 Flash 性能模式考量，比如 DTR 模式、Continuous read 模式，要想使能這些模式也都需要在 FDCB 里做文章，詳見痞子衡舊文 《使能串列NOR Flash的DTR模式》、《使能串列NOR Flash的Continuous read模式》。
二、多Flash型號量產的解決方案
上一節介紹了有很多因素會導致 FDCB 不同，這些因素都是多 Flash 型號量產路上的攔路虎，我們有什麼方法能規避這些因素差異帶來的問題呢？主要有如下兩個方案：
2.1 BootROM自識別方案
第一個方案是利用 i.MXRT 晶元 BootROM 里的功能，詳見痞子衡舊文 《自識別特性(Auto Probe)可以無需FDCB也能從NOR Flash啟動》。這個特性可以讓我們不用提供 FDCB，晶元也能正常從 Flash 里啟動固件應用程式，這樣也就自然不存在量產過程中不同 Flash 里固件差異問題。但是這個方案也有幾個明顯的缺點：
- 缺點一：Auto Probe 特性在 i.MXRT1010/1020/1050 上不可用，僅在 i.MXRT1060/1170/500/600 上可以用。
- 缺點二：Auto Probe 特性對於不同 Flash 的支持（尤其是 OctalSPI Flash）可能需要通過燒寫 i.MXRT 晶元 OTP 來實現，這樣實際上是把 FDCB 差異轉化到 OTP 差異上了。
- 缺點三：Auto Probe 特性僅能處理基本的 FDCB 差異（比如 QE，比如 Dummy Cycle），但是一些性能模式相關的差異不能很好地處理，拓展性不足。
2.2 一線模式FDCB啟動+二級Configurer程式
第二個方案主要是為瞭解決方案一里的全部缺點，即使用通用的一線低速模式的 FDCB 啟動頭給 BootROM 去讀取啟動，然後再設計一個二級的 Configurer 程式（被 BootROM 啟動的代碼），在這個 Configurer 程式里去做 Flash 差異化的相關事情並將 FlexSPI 模塊配置到指定時序模式，最後再由這個 Configurer 程式去啟動固件應用程式。
這裡的 Configurer 程式設計是關鍵，而其中最核心的是如何識別當前 Flash 型號，這裡要感謝 JEDEC 組織，目前幾乎全部主流 Flash 都支持一線模式下 Read JEDEC 命令(0x9F)，返回的 Manufacturer ID 就是每個 Flash 廠商向 JEDEC 組織申請的識別碼，然後 Memory Type 是各廠商自己定義的型號系列分類。Configurer 程式結合這兩個參數就可以識別當前 Flash 具體型號，底下就是做不同的代碼分支去處理不同的 Flash 配置即可。
二級 Configurer 程式說起來很簡單，其實具體設計起來還是有很多細節要考量的（比如 FlexSPI 多次配置中系統時鐘切換問題、應用程式跳轉等），因此痞子衡開源了這個項目（RT-MFB），並且會長期維護下去，希望將來能支持儘可能多的 Flash 型號。第一版是以 MIMXRT595-EVK 上的兩顆 Flash 為原型（IS25WP064A / MX25UW51345G）來做的。
至此，一種靈活的i.MXRT下多串列NOR Flash型號選擇的量產方案痞子衡便介紹完畢了，掌聲在哪裡~~~
歡迎訂閱
文章會同時發佈到我的 博客園主頁、CSDN主頁、知乎主頁、微信公眾號 平臺上。
微信搜索"痞子衡嵌入式"或者掃描下麵二維碼，就可以在手機上第一時間看了哦。
最後歡迎關註痞子衡個人微信公眾號【痞子衡嵌入式】，一個專註嵌入式技術的公眾號，跟著痞子衡一起玩轉嵌入式。
衡傑(痞子衡)，目前就職於恩智浦MCU系統部門，擔任嵌入式系統應用工程師。
專欄內所有文章的轉載請註明出處：http://www.cnblogs.com/henjay724/
與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]
可以關註痞子衡的Github主頁 https://github.com/JayHeng，有很多好玩的嵌入式項目。
關於專欄文章有任何疑問請直接在博客下麵留言，痞子衡會及時回覆免費(劃重點)答疑。
痞子衡郵箱已被私信擠爆，技術問題不推薦私信，堅持私信請先掃碼付款(5元起步)再發。
