痞子衡嵌入式：恩智浦i.MX RT1xxx系列MCU啓動那些事（11.A）- FlexSPI NOR啓動時間(RT1170)

---

　　你們好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給你們介紹的是恩智浦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）的時間，工做量要稍微大一些，讓咱們開始吧。

1、準備工做

1.1 知識儲備

　　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模塊的初始化以後才能作搬移工做。

1.2 時間界定

　　關於時間終點，參考《SEMC NAND啓動時間》 裏的1.2節，方法保持一致。而關於時間起點，本次的測試選點作了一些優化，測NAND啓動時爲了圖方便選在了最靠近POR引腳的電壓轉換器NC7SP125P5X的輸入腳（Pin1）所在的Header上，可是咱們知道任何一個被動電源器件都有轉換時間，爲了儘量精確測量啓動時間，咱們應該消除這種偏差，所以本次選點放在了NC7SP125P5X的輸出腳（Pin4），這個腳與主芯片POR引腳是直連的。

　　爲了讓你們對電源器件轉換時間有個深入感覺，痞子衡此次還特意量了一下Validation板上原始電源輸入（5V Jack）到POR引腳上電的時間，這個時間足有210ms，根據電源電路設計以及器件選型的不一樣，這個時間是不一樣的，因此應該從啓動時間裏拋除出來。

1.3 製做應用程序

　　關於應用程序製做，依舊是參考《SEMC NAND啓動時間》 裏的1.3節，只有一個微小改進，就是把翻轉GPIO的代碼放在SystemInit()函數最前面，儘量地靠近Reset_Handler。

void SystemInit (void) {
    {
        CLOCK_EnableClock(kCLOCK_Iomuxc);
        gpio_pin_config_t led_config = {kGPIO_DigitalOutput, 0, kGPIO_NoIntmode};
        IOMUXC_SetPinMux(IOMUXC_GPIO_AD_03_GPIO9_IO02, 0U);
        GPIO_PinInit(GPIO9, 2, &led_config);
        GPIO_PinWrite(GPIO9, 2, 1u);
    }

	// 關開門狗和SysTick

    while (1);

    // ...
}

1.4 下載應用程序

　　應用程序的下載需藉助痞子衡開發的NXP-MCUBootUtility工具（v2.3版本及以上），本次痞子衡一共測試了兩款Flash，針對不一樣的Flash，在下載時選擇的模型不同：

　　下面模型適用華邦W25Q256系列，配置成了四線、SDR、133MHz工做模式去啓動：

　　下面模型適用旺宏MX25UM51345系列，配置成了八線、DDR、166MHz工做模式去啓動：

1.5 示波器抓取信號

　　一切準備就緒，能夠用示波器抓Serial NOR啓動時間了。通道一監測原始5V電源輸入信號，通道二監測芯片POR信號，通道三來監測Flash片選信號（FSPI1A_SS0_B），通道四監測LED GPIO信號。

2、開始測試

2.1 測試結果

　　在公佈結果以前，痞子衡先帶你們分析一下示波器抓取的啓動時間波形，方便你們理解後續表格裏的各項組成。

　　先來看你們相對陌生的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	XIP	6.920 ms	1.612 ms	8.532 ms
	253442	ITCM	6.953 ms	8.795 ms	15.748 ms
MX25UM51345G 8bit, DDR, 166MHz	16390	XIP	6.942 ms	1.618 ms	8.560 ms
	17922	ITCM	6.944 ms	2.312 ms	9.256 ms
	251910	XIP	6.916 ms	1.647 ms	8.563 ms
	253442	ITCM	6.935 ms	8.897 ms	15.832 ms

2.2 結果分析

　　從上面表格裏的結果咱們能夠獲得以下三個結論：

• 結論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主頻是影響固定開銷的因素。

memcpy((void *)0x6000, (const void *)0x30002000, 230 * 1024);

　　由於Non-XIP App沒有爲FlexSPI映射地址開啓cache，痞子衡特意開了cache再次作了測試，此次拷貝230KB數據僅需724us，這個值幾乎已經逼近了理論計算值（230KB/4KB) x 12.33us = 708.9us，因此ROM是在沒有使能cache下作的數據搬移，Cache是否使能也是影響固定開銷的因素。

//#if defined(XIP_EXTERNAL_FLASH) && (XIP_EXTERNAL_FLASH == 1)
    /* Region 7 setting: Memory with Normal type, not shareable, outer/inner write back. */
    MPU->RBAR = ARM_MPU_RBAR(7, 0x30000000U);
    MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_RO, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_16MB);
//#endif

　　這個發現也告訴咱們使用memcpy()函數搬移Flash數據，是否使能cache對執行效率影響很是大。使能cache以後，作數據搬移時，CPU往TCM寫數據與cache從Flash裏預取數據能夠更大程序的並行，而且cache的讀都是burst操做，能加速搬移。而若是不使能cache，下一次的Flash讀須要等待上一次CPU寫完TCM纔會開始，搬移時間會長。

　　至此，恩智浦i.MX RT1170 FlexSPI NOR啓動時間痞子衡便介紹完畢了，掌聲在哪裏~~~

歡迎訂閱

文章會同時發佈到個人 博客園主頁、CSDN主頁、微信公衆號 平臺上。

微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就能夠在手機上第一時間看了哦。