痞子衡剛剛拿到i.MXRT1170 B0版本的晶片，迫不及待地在上面跑了一些A0版本上早已驗證過的demo，功能一切正常，沒有什麼額外遷移工作。因為目前隻有B0版本晶片，沒有配套EVK，是以痞子衡是在RT1170内部Validation闆上做測試的（RT主晶片以及Flash晶片全部放在Socket裡的，非常友善更換），正好痞子衡最近整理工位，找到了非常多來自不同廠家的串行Flash樣片，何不趁此時順便測一下Serial NOR啟動時間，畢竟Serial NOR是i.MXRT啟動首選裝置，啟動時間肯定是大家比較感興趣的。
大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是恩智浦i.MX RT1170 FlexSPI NOR啟動時間。
痞子衡剛剛拿到i.MXRT1170 B0版本的晶片，迫不及待地在上面跑了一些A0版本上早已驗證過的demo，功能一切正常，沒有什麼額外遷移工作。因為目前隻有B0版本晶片，沒有配套EVK，是以痞子衡是在RT1170内部Validation闆上做測試的（RT主晶片以及Flash晶片全部放在Socket裡的，非常友善更換），正好痞子衡最近整理工位，找到了非常多來自不同廠家的串行Flash樣片，何不趁此時順便測一下Serial NOR啟動時間，畢竟Serial NOR是i.MXRT啟動首選裝置，啟動時間肯定是大家比較感興趣的。
關于i.MXRT1170啟動時間，痞子衡之前在A0版本上測過 《SEMC NAND啟動時間》，有了之前的測試基礎，本篇文章就是照葫蘆畫瓢。不過由于Serial NOR的特殊性，本文會同時測XIP和Non-XIP時間，以及兩種典型的Flash工作模式下（四線SDR，八線DDR）的時間，工作量要稍微大一些，讓我們開始吧。
Serial NOR可以說是大家最熟悉的啟動裝置了，雖然這個裝置可以支援兩類App（XIP和Non-XIP）去啟動，但大家用得最多的無疑是XIP App，因為XIP下App代碼長度可以和Flash容量一樣大，這對于複雜功能的應用很重要，但是編寫XIP App代碼也有一些需要注意的地方，比如在配置系統時鐘（不能影響FlexSPI子產品）或者擦寫Flash時（不支援RWW的話需要拷貝到RAM裡執行）有一些限制。
至于Non-XIP，相比XIP會多一個App拷貝過程，啟動時間難免會變長。拷貝目标裝置選擇種類很多，可以是内部RAM（包含TCM和OCRAM），也可以是外部RAM（SDRAM或者HyperRAM）。如果是為了提高代碼執行效率，通常會搬移到内部TCM裡執行。當然也有搬移到外部SDRAM執行的，不過這種情況需要額外利用DCD功能來完成SEMC子產品的初始化之後才能做搬移工作。
關于時間終點，參考《SEMC NAND啟動時間》 裡的1.2節，方法保持一緻。而關于時間起點，本次的測試選點做了一些優化，測NAND啟動時為了圖友善選在了最靠近POR引腳的電壓轉換器NC7SP125P5X的輸入腳（Pin1）所在的Header上，但是我們知道任何一個被動電源器件都有轉換時間，為了盡可能精确測量啟動時間，我們應該消除這種誤差，是以本次選點放在了NC7SP125P5X的輸出腳（Pin4），這個腳與主晶片POR引腳是直連的。
為了讓大家對電源器件轉換時間有個深刻感受，痞子衡這次還特地量了一下Validation闆上原始電源輸入（5V Jack）到POR引腳上電的時間，這個時間足有210ms，根據電源電路設計以及器件選型的不同，這個時間是不同的，是以應該從啟動時間裡抛除出來。
關于應用程式制作，依舊是參考《SEMC NAND啟動時間》 裡的1.3節，隻有一個微小改進，就是把翻轉GPIO的代碼放在SystemInit()函數最前面，盡可能地靠近Reset_Handler。
應用程式的下載下傳需借助痞子衡開發的NXP-MCUBootUtility工具（v2.3版本及以上），本次痞子衡一共測試了兩款Flash，針對不同的Flash，在下載下傳時選擇的模型不一樣：
下面模型适用華邦W25Q256系列，配置成了四線、SDR、133MHz工作模式去啟動：
下面模型适用旺宏MX25UM51345系列，配置成了八線、DDR、166MHz工作模式去啟動：
一切準備就緒，可以用示波器抓Serial NOR啟動時間了。通道一監測原始5V電源輸入信号，通道二監測晶片POR信号，通道三來監測Flash片選信号（FSPI1A_SS0_B），通道四監測LED GPIO信号。
在公布結果之前，痞子衡先帶大家分析一下示波器抓取的啟動時間波形，友善大家了解後續表格裡的各項組成。
先來看大家相對陌生的Non-XIP啟動的波形（MX25UM51345G，247KB App）。通道二連接配接POR引腳，電平拉高是啟動計時的開始，啟動後會先經曆BootROM時間（CM7核心先執行ROM代碼，做一些正常系統初始化，讀取使用者啟動配置，然後配置好FlexSPI子產品），底下再經曆BootFlash時間（還是在ROM裡執行，不過此時開始通路外部Flash，從Flash裡讀取FDCB、IVT、BootData以及搬移App，是以你會看到通道三（Flash的片選信号）上會有持續的波形變化，搬移完成之後便跳轉到App裡執行），最後你會看到通道四電平拉高了（App在執行）。
作為比較，再來看一下XIP啟動的波形（MX25UM51345G，246KB App）。BootROM時間跟Non-XIP基本差不多，這是可以了解的，同樣的ROM代碼在執行，消耗的機器周期是不變的。BootFlash的時間明顯縮短了，Flash片選的波形隻有屈指可數的幾次，這是因為ROM此時隻需要讀取FDCB、IVT、BootData，根據IVT裡的連結位址資訊得知App不需要搬移就直接跳轉了。
分析完了啟動時間組成，讓我們看結果吧。痞子衡基于Flash工作模式、App長度、App執行位址的組合一共做了8個測試，結果如下表所示（注：表中結果都是在1.25M次/秒的采樣率下所得）：
Flash型号
Timing模式
App長度
(bytes)
App執行位置
BootROM時間
BootFlash時間
總啟動時間
W25Q256J
4bit, SDR, 133MHz
16390
XIP
6.926 ms
1.611 ms
8.537 ms
17922
ITCM
6.939 ms
2.203 ms
9.142 ms
251910
6.920 ms
1.612 ms
8.532 ms
253442
6.953 ms
8.795 ms
15.748 ms
MX25UM51345G
8bit, DDR, 166MHz
6.942 ms
1.618 ms
8.560 ms
6.944 ms
2.312 ms
9.256 ms
6.916 ms
1.647 ms
8.563 ms
6.935 ms
8.897 ms
15.832 ms
從上面表格裡的結果我們可以得到如下三個結論：
結論1：不管是哪種Flash連接配接，BootROM時間差不多是固定的，大概在6.9ms 結論2：XIP啟動的情況下，BootFlash時間幾乎也是固定的，跟App長度無關，大概在1.6ms 結論3：Non-XIP啟動的情況下，BootFlash時間跟App長度成正比，但是跟Flash工作模式（速度）不是正比（甚至可以說關系不太大）
關于結論3裡的BootFlash時間跟Flash工作模式（速度）不是正比這點有必要展開研究一下。痞子衡的測試結果是ROM從Flash拷貝247KB資料到ITCM，無論是從QSPI Flash拷貝還是從Octal Flash拷貝所花時間竟然幾乎是一緻的，這個看起來挺奇怪的，畢竟僅從Flash自身讀通路速度而言，Octal Flash應該是QSPI Flash的五倍（8bit x 2 x 166MHz) / (4bit x 1 x 133MHz）。
為了解開謎題，痞子衡對時序圖裡CS信号做了進一步分析，下圖是QSPI Flash的啟動時序圖，ROM拷貝247KB的資料耗時約7.833ms，每個CS周期是114.4us，扣除時序前期的空閑時間以及讀Boot Header，拷貝App期間共有62個CS周期，那麼每個CS周期實際拷貝了4KB資料，這代表ROM配置了FlexSPI prefetch buffer的長度為4KB（RT1170最大是4KB，RT1060最大是1KB）并且使能了Prefetch功能。從QSPI Flash本身速度理論計算，讀4KB資料應該耗時 4KB / (4bit x 133MHz) = 61.59us，這與實際測量的CS信号的低電平時間是吻合的。再來看CS信号周期的高電平(idle)時間足有52.8us，為什麼會有這麼長的空閑時間？疑問先放在這裡。
同樣的方法再來分析一下Octal Flash的啟動時序圖。從Octal Flash本身速度理論計算，讀4KB資料應該耗時 4KB / (8bit x 2 x 166MHz) = 12.33us，這與實際測量的CS信号的低電平時間依然是吻合的。結合上面分析的QSPI Flash CS低有效時間來看，兩者确實是五倍的關系。但是此時的CS信号周期的高電平時間比QSPI Flash下的時間要更長，達到了100.47us，最終導緻兩種不同性能Flash下拷貝時間差不多。
分析到這裡，我們已經找到了線索，ROM從Flash prefetch buffer裡拷貝4KB資料到TCM固定耗時約112us，是以速度瓶頸不在Flash本身讀速率，而在于搬移時的開銷，那麼是什麼導緻了這個固定開銷？
因為ROM代碼是個黑盒子，我們看不見，痞子衡為了找到這個系統開銷，在Octal Flash Non-XIP啟動的App裡用memcpy做了同樣的資料搬移。根據上面表格裡的結果，我們知道ROM裡搬移230KB資料需耗時6.576ms，經測試App裡搬移230KB資料僅需3.265ms，ROM和App的差別主要是執行效率不一樣（ROM預設配置的CPU主頻是400MHz（注：最高可以配到696MHz），App配置的CPU主頻是996MHz），是以CPU主頻是影響固定開銷的因素。
因為Non-XIP App沒有為FlexSPI映射位址開啟cache，痞子衡特地開了cache再次做了測試，這次拷貝230KB資料僅需724us，這個值幾乎已經逼近了理論計算值（230KB/4KB) x 12.33us = 708.9us，是以ROM是在沒有使能cache下做的資料搬移，Cache是否使能也是影響固定開銷的因素。
這個發現也告訴我們使用memcpy()函數搬移Flash資料，是否使能cache對執行效率影響非常大。使能cache之後，做資料搬移時，CPU往TCM寫資料與cache從Flash裡預取資料可以更大程式的并行，并且cache的讀都是burst操作，能加速搬移。而如果不使能cache，下一次的Flash讀需要等待上一次CPU寫完TCM才會開始，搬移時間會長。
因為此次拿到的B0版本晶片是剛出廠的，晶片校正值沒有燒錄（校正值一般放在eFuse裡），而實際晶片POR之後會有校正的過程，會帶來額外的Boot Time開銷。下面是痞子衡此次測試的樣片裡的eFuse值：
至此，恩智浦i.MX RT1170 FlexSPI NOR啟動時間痞子衡便介紹完畢了，掌聲在哪裡~~~
文章會同時釋出到我的 部落格園首頁、CSDN首頁、知乎首頁、微信公衆号 平台上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
最後歡迎關注痞子衡個人微信公衆号【痞子衡嵌入式】，一個專注嵌入式技術的公衆号，跟着痞子衡一起玩轉嵌入式。
衡傑(痞子衡)，目前就職于恩智浦MCU系統部門，擔任嵌入式系統應用工程師。
專欄内所有文章的轉載請注明出處：http://www.cnblogs.com/henjay724/
與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]
可以關注痞子衡的Github首頁 https://github.com/JayHeng，有很多好玩的嵌入式項目。
關于專欄文章有任何疑問請直接在部落格下面留言，痞子衡會及時回複免費(劃重點)答疑。
痞子衡郵箱已被私信擠爆，技術問題不推薦私信，堅持私信請先掃碼付款(5元起步)再發。