趁著我們NB的號稱跨界處理器的i.MXRT系列的推出一睹為快吧（想起當年也是Kinetis剛出來，我在學校正好開始寫它的那一系列技術文檔，這是啥，緣分吶）。其實在發表到AET之前，我先把此文發到阿莫論壇上了試了試水，收到的一句話挺讓我心情激蕩的，就是“FSL又活了”，my answer is “靈魂依在。。。”，哎，啥也不說了，下面開整吧。

在此文正式成型之前，歷經了3個版本的修改和優化，最終fixed掉了已知的bug和穩定性才敢拿出來獻丑，希望讓廣大AET的博友們繼續能有所收獲有所體會，也算為了RT1050的未來發展貢獻點力量吧，貌似不少人在觀望RT系列，也有很多第三方設計公司和開源項目在蠢蠢欲動，所以也希望我拋的這塊磚能在RT的廣泛市場激起一點漣漪多引出幾塊好玉來。。。

2018新年伊始，I.MXRT105x已經推向市場有一段兒時間了，以其極高的性價比引起了不少工業和消費領域客戶的興趣，畢竟相比于目前市場上已有的多數“高價低配”的高端ARM Cortex-M7產品，RT105x最高600MHz主頻、極豐富的外設和3美金起步的定位著實算是業界良心了（還有馬上要面世的LQFP封裝I.MXRT1020更是讓人期待），只是當然這種“低價高配”是有代價的，其內部不自帶Flash需要外掛串行SPI Nand/Nor Flash或者并行的Nand/Nor Flash（貌似一下子給不少心動的人潑了涼水，呵呵），不過這一消息倒是有人歡喜有人憂，對歡喜的客戶來說，他們的應用代碼本身內部Flash就裝不下需要外擴，這一下反倒好了，省的內心糾結了再也不用擔心老板整天催自己優化代碼精簡應用看看能不能只用內部Flash搞定了，哈哈，而且動則幾Mb或者幾十Mb的外部SPI Flash價格便宜以后升級也是綽綽有余，而對憂的客戶來說，外部Flash啟動方式帶來的啟動配置復雜、代碼安全性問題和對系統性能的影響等都是潛在的棘手問題。

關于外部Flash的代碼安全問題和代碼在外部執行對整個系統性能的影響，RT105x的加密啟動（HAB）功能和32KB的L1 ICache/DCache是可以解決的，只是本文先從RT105x的啟動配置問題著手，畢竟系統如果都Boot不起來，其他的問題都是空談了，呵呵。另外，如上面所說，RT105x支持的啟動方式有不少，不過個人覺著外部串行SPI Flash啟動會是大多數人的折中選擇。由于RT105x的官方EVK板上是帶有兩塊串行SPI Nor Flash（一個是Cypress高性能8線高速的Hyper Flash

S26KS512SDPBHI02，一個是ISSI物美價廉的4線QSPI Flash IS25WP064AJBLE），所以咱就手上有啥來啥，以板載的Hyper Flash和QSPI Flash為例詳細說明下串行SPI Nor Flash的啟動流程和具體使用方法。

串行SPI Nor Flash啟動流程1

當RT105x EVK板載的Boot模式選擇開關SW7設定為如下Table1-1所示的前兩者時（其他BOOT_CFG 管腳默認被下拉到地，即OFF狀態），系統會通過片上的FlexSPI接口執行外部串行SPI Nor Flash的啟動，其啟動地址為Table1-2所示的0x6000_0000（如果是從并行的Nor Flash啟動則啟動地址為0x8000_0000），關于其他Boot pin對啟動模式的配置影響，見RT105x的RM手冊8.6章節，這里就不細說了。

Table1-1 典型的啟動模式設定

Table1-2 啟動相關地址

如圖1所示為完整的SPI Nor Flash啟動流程圖，當RT105x的片上ROM在檢測到啟動模式為FlexSPI接口后，會根據Boot Pin的配置信息配置該模式下需要使用的FlexSPI接口管腳的復用模式并將FlexSPI的時鐘配置成默認的低速30MHz，然后會以0x6000_0000為首地址讀取前512個字節作為外部Flash的配置信息（即Flash Configuration Parameters，包括幾線制的SPI Flash，SPI的時鐘頻率，LUT查找表，DDR/SDR模式以及片選CS管腳的Hold/Setup Time等信息，見RM8.6.3章節）并以此來配置FlexSPI模塊以滿足外部Flash的特性，待配置完畢后，RT105x CPU以后即會以AHB總線讀取數據和指令的方式（雖然從外部來看仍然是FlexSPI接口，但是由于LUT查找表讀取數據的指令已經配置好，CPU只是通過AHB總線發送讀取指令即可觸發LUT以操作外部Flash，也就是說在內部對CPU來講已經屏蔽掉了FlexSPI的底層）來讀取接下來的跟用戶Image相關的幾個關鍵信息，即IVT(Image Vector Table)，Boot Data和DCD（Device configuration data）如圖2，其中IVT需要放在外部Flash的固定偏移地址（如圖3，對Nor Flash來說其需要存儲在基地址 + 4KB的偏移地址，比如0x60000000+4*1024）供ROM讀取以便讓系統知道用戶Image的第一條可執行指令放在了哪里以及BootData和DCD的存放地址，BootData則保存了完整Image的首地址和整個image所占的空間大小，而DCD則包含了一些配置命令以便在跳到用戶程序入口之前供ROM調用配置內部外設以更好的匹配外部IC，一般如果系統外掛了SDRAM的情況則需要配置好DCD（因為有時需要主程序在跑起來之前，外部SDRAM就得處在ready狀態，以供CPU把data或者code copy到SDRAM里時不會出錯）。

圖1 SPI Nor Flash啟動流程

圖2 完整Image組成元素

圖3 IVT針對不同存儲介質的存放地址

綜上所述，我們實際上就可以得出結論來，如果要讓系統能正常Boot起來，則燒寫到外部串行SPI Flash里面的完整image必須要包括五個重要元素，即Flash Configuration Parameters，IVT，Boot Data，DCD和用戶image，而其中Flash Configuration Parameters和IVT是存放在固定的地址的，而后三者則由IVT的內容來決定，無論是直接編譯生成或者通過輔助工具手動添加，只要我們最后形成的image里面包含了這幾個元素，CPU就會認可這個image并執行（先不談安全加密的事）。所以我們只要搞清楚這個基本原理了，無論是什么方法，最后都是殊途同歸，下面就可以放心大膽地去解決RT105x的FlesSPI啟動問題了。

SPI Nor Flash啟動配置方法2

前面提到如果想要RT105x能正常從外部串行SPI Nor Flash啟動的話，待燒寫的image是必須要集成五個元素的（Flash Configuration Parameters, IVT, Boot Data, DCD and User Image, 重要事情要多說幾遍 呵呵），那具體的實現方法我目前想到的無非兩種，一種是在編譯鏈接過程中直接把這幾個元素和應用代碼鏈接到一塊，并將這幾個元素指定好鏈接地址，最后通過IDE的Flashloader下載到SPI Flash里，第二種則是通過輔助工具在編譯鏈接好的裸應用代碼前面手動的添加一個信息頭（頭里面包含這幾個元素），然后通過單獨的下載工具或者MCU內部的ROM Bootloader ISP下載進去。這兩種各有優劣勢，前者比較適合在前期調試的時候使用，這樣在IDE里面編輯修改應用代碼后做印證測試的時候可以直接在線download和debug（比如單步，斷點，查看寄存器和Memory等等），我相信這也是目前大家比較迫切需要的，但是缺點的話則是前期配置過程稍微復雜些且需要對Boot過程和外部SPI Flash的Spec有一定了解（當然這些配置是一勞永逸的，配置一次即可），而后者則是客戶不需要關心其他幾個元素的配置只專注用戶應用的開發，待開發完畢后通過輔助工具生成最終的Image用于小批測試或者量產，缺點是前期調試的話會比較麻煩，每次修改完重新編譯生成用戶image還需要用輔助工具手動添加信息頭然后再通過Bootloader下載進去驗證（我想想都有點累的慌。。。這種情況workaround只能是前期先在RAM里調試，待成熟了之后再走這個流程）。

第二種使用輔助工具的方法，官方已經提供了一整套工具鏈（可以從RT105x官方主頁的”Flashloader i.MX-RT1050”軟件包里找到）且有了相應的AN應用筆記介紹其具體操作步驟，這里就不再贅述了。本次我們重點介紹第一種方法，即在IDE環境里通過對工程的配置達到生成并下載調試完整image的目的，說到這里我再啰嗦幾句，實際上這種方法做下來不只方便了在線download和debug，好處也不少，一是所有的這幾個元素配置信息都以C語言的常量形式體現在應用工程文件里面，會加深我們對Boot的理解程度不說，這樣的話如果更換外部SPI Flash也可以很方便的更改適配信息，第二呢則是這種方式形成的image文件會是通用的image格式（比如.bin, .hex和.S19），也會兼容市面上大多數可以直接燒寫SPI Flash的量產工具的批量燒寫。好了，不再多說了，再說就有點話癆了，呵呵，因為板載有Hyper Flash和QSPI Flash兩種，下面就分別詳細說明下這兩種Flash在IDE環境下的配置方法（我使用的IAR，Keil的可以參考第四章節自行配置，需要添加的幾個文件是IAR，Keil和GCC三個環境兼容的）。

開發測試環境：

Hardware Platform: MIMRT1050-EVK (SCH-29538 REV A1)

Software Package: SDK_2.3.0_EVK-MIMXRT1050(mcuxpresso.nxp.com)

IDE: IAR_v8.20.1

Debugger: On-Board CMSIS-DAP

2.1 Cypress 1.8v Hyper Flash啟動

RT105x的EVK板子默認是使用Hyper Flash啟動的，所以硬件不需要改動，只需要將SW7啟動模式修改成Table1-1第一行配置使能Hyper Flash啟動即可，如下圖4，然后我們以SDK2.3中的hello world為例介紹具體配置方法。實際上在最新的SDK2.3里面Keil和MCUXpresso版本已經有針對Hyper Flash啟動的hello_world_xip的樣例了，只是IAR反倒是沒有，不過這下正好我們來走一遍完整的配置過程，這樣也可以為下一小節的QSPI啟動打下基礎（官方例程里是沒有QSPI XIP例程的），畢竟大多數客戶估計還是會傾向于選擇QSPI的。

圖4 Hyper Flash啟動模式

（1）打開SDK2.3的hello world例程\boards\evkmimxrt1050\demo_apps\hello_world\iar，在Workspace下可以看到默認是有8種配置的，包括在SDRAM調試，OCRAM調試和spi nor Flash調試，原始的flexspi_nor_debug配置是沒有其他幾種元素的，所以這種配置下當把代碼下進去外部Hyper Flash上的時候可以在線debug但是當重新上電或者外部復位后系統是Boot不起來的，因為沒有其他元素信息RT1050啟動的時候識別不了它的。接下來我們在此配置基礎上新建一個配置出來然后在新的工程配置上添加文件和修改配置，點擊IAR菜單欄Project->Edit Configurations，然后在打開的窗口下選擇New，在新的工程配置下起一個新的名字“HyperFlash_bootok”，Base on Configuration則選擇原有的flexspi_nor_debug以最大限度的保留原有的配置，改好之后點擊Ok即當前工程會進入新添加的HyperFlash_bootok配置狀態；

（2）在此工程配置下，新添加一個Group（右鍵工程->Add->Add Group）并命名為“xip”，然后右鍵該Group->Add->Add Files，找到根目錄\devices\MIMXRT1052\xip路徑下的四個文件，將該四個文件都添加到當前工程上來，如下所示，我們可以打開這兩個.c文件即可看到除了User Image之外的其他四個元素信息都以常量的方式被定義在指定的段地址內，以便在編譯鏈接之后將這幾個元素配置信息分配到指定的地址上以保存在最終的Image上，且這四個文件是可以兼容IAR，Keil和GCC三大編譯器的所以可以隨意Porting，當然不要忘了在工程配置中頭文件搜索路徑上添加那兩個頭文件的路徑，另外如果沒有XIP_EXTERNAL_FLASH這個宏的話也要加上；

（3）由于四個元素被分別定義到指定的段內，但是默認的原始工程里面的鏈接文件是沒有這幾個段的定義的（Keil和MCUXpresso由于有xip的樣例，它們是定義好的了），所以還需要在原始的鏈接文件基礎上添加這幾個段的定義并分配好地址，我們將原來的鏈接文件MIMXRT1052xxxxx_flexspi_nor.icf復制一份重命名為MIMXRT1052xxxxx_hyperflash_nor_bootok.icf（名字倒是無所謂），然后打開該文件，添加這幾個段的定義和地址分配如下（修改好的源文件見隨本文檔附帶的壓縮包），然后在工程配置Options->Linker里選擇新修改的鏈接文件，最后點擊確認；

（4）不要以為這樣就結束了，呵呵，我們這兩步說到幾個重要的元素信息是以常量的形式通過鏈接文件保存在指定的地址段內，不過我們的應用工程卻沒有調用它們，在編譯的時候編譯器會默認把他們又給優化掉了搞的最后沒有體現在Image里面，前面的工作白搭了，所以還需要額外一步告訴編譯器把這幾個常量給Keep住，具體配置如下圖，然后點擊確認；

（5）這樣工程配置就結束了，我們重新編譯整個工程，然后在生成的.map文件里即可看到如下這四個元素信息都已經正確的分配到指定地址了，這樣就萬事俱備，就差IDE IAR的Flashloader這個“東風”了；

（6）在IAR v8.20.1以上的版本已經有HyperFlash的Flashloader了，我們在Options->Debugger選項下選擇CMSIS-DAP，然后接下來需要注意的是在Options->CMSIS-DAP選項下，Reset類型需要選擇Core Reset（CMSIS-DAP默認的Reset方式會導致調試的時候打不了斷點，J-link倒是沒有這個問題），然后點擊Ok保持配置，最后開始Debug即可完美的把帶有幾個重要元素信息的配置數據都下載到外部Hyper Flash里面并進入Debug模式，正常單步或者斷點，并且按鍵復位或者重新給板子上電都可以讓RT105x正常Boot起來，最后有圖有真相，發個串口打印的結果“hello world”, Enjoy it…

2.2 ISSI 1.8v QSPI啟動

上面說完Hyper Flash的啟動方法，接下來繼續說說QSPI啟動。由于板子上的Hyper Flash和QSPI時鐘、片選和部分數據線是共用的，所以在測試QSPI啟動的時候需要把Hyper Flash焊掉（跟板子硬件設計有關系，不焊掉會影響時序，稍微有點心疼，畢竟Hyper Flash比較貴而且又是BGA的焊下來就焊不上去了，當然，如果是客戶自己設計的板子只會有一種SPI Nor Flash，那就沒這個問題了），然后將下圖中DNP的0歐姆電阻焊上，最后特別注意的是需要在QSPI Flash的第7腳和3腳即Reset和WP管腳上拉4.7k的電阻到電源Flash_VCC。因為我發現有個別型號的QSPI Flash，比如板子用的ISSI這個，在系統啟動的時候Reset和WP這兩個腳是懸空態，而QSPI Flash默認上電都是單線方式，這樣的話Reset和WP如果是低電平則QSPI一直處于復位和寫保護狀態，從而造成系統RT1050讀取QSPI信息失敗進而導致啟動失敗，所以需要在這兩個腳上加個上拉電阻給它有效的高電平，后來我測試的QD和Winbond的QSPI這兩個腳里面是有上拉電阻的，系統啟動后是固定的高電平就沒有問題了，不過我的建議是最好外部再加一個保證可靠，也不會影響后續的4線通信。另外，別忘了SW7啟動模式需要修改成Table1-1第二行配置使能QSPI Flash啟動，如下圖5：

圖5 QSPI Flash啟動模式

（1）我們仍然以上面的hello world工程為例，有前面章節打基礎，本章說起來就輕松不少了，在當前工程下，點擊IAR菜單欄Project->Edit Configurations繼續新建一個工程配置并以HyperFlash_bootok為藍本將新的配置命名為“Qspi_nor_bootok”如下圖，然后點擊Ok進入該配置模式下；

（2）此時xip的Group文件組仍然有效，不過由于Boot的Flash類型發生了變化，所以需要修改外部SPI Flash的前512字節的Flash Configuration Parameters元素信息（其他幾個元素無需修改）。打開fsl_flexspi_nor_flash.c文件，然后在hyperflash_config常量前面添加如下圖Qspiflash_config的常量（修改后的源文件見隨本文檔附帶的壓縮包），實際上只是修改了外部SPI Flash的Pads類型、SPI時鐘頻率、Flash的大小（包括總大小以及page和sector的大小）和最重要的LUT查找表指令，這里我使用了外部QSPI Flash的四線Quad I/O Read模式（即0xEB），此模式下SPI的時鐘頻率可以跑到133MHz，總帶寬可以達到532Mbps即66.5MByte/s（實際上很多MCU片內的Flash時鐘也差不多這個頻率甚至比這個低，不過內部的Flash線寬會大些），這個速度雖然相比于CPU 600MHz的主頻慢很多，但是實際上RT1050的一級緩存ICache和DCache各有32KB且在程序里默認是打開的，實測下來對大部分代碼來說外部SPI Flash的帶寬幾乎不會拖累CPU性能，針對特定應用的復雜代碼留待大家自行測試（實測Opus音頻編解碼，跑在外部QSPI Flash上的性能大概為跑在內部SRAM上的70%~80%）；

（3）上一步通過預編譯QSPI_BOOT宏來使能QspiFlash的配置信息主要是為方便跟前面HyperFlash啟動兼容，只需在當前工程配置下添加QSPI_BOOT宏即可，如下圖所示，這樣即使再跳回HyperFlash_bootok工程時也不必麻煩地來回修改Flash Configuration Parameters元素信息了，同時該工程配置下的鏈接文件由于各個段地址沒有變化則不用修改，只是需要Keep的常量記得替換成Qspiflash_config，然后點擊確認保存；

（4）此時整個工程的配置工作就完成了，點擊Build完成對整個工程的編譯和鏈接，查看.map文件也可以看到其他4個主要元素配置信息也都鏈接到整個image里了。不過接下來需要解決的是QSPI Flash的Flashloader問題了。在IAR For ARM v8.20.2以上的版本的Flashloader里已經加入了對QSPI Flash的支持了，但是該Flashloader只支持ISSI的QSPI Flash，我在此基礎上做了修改和優化加入了對GD和Winbond QSPI Flash的支持，該新的Flashloader見隨本文檔附帶的壓縮包文件，將壓縮包路徑Firmware\IAR_8.20_Flashloader下的四個文件copy到IAR安裝目錄下C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\config\flashloader\NXP并覆蓋源文件。此外，該修改后的Flashloader同時支持HyperFlash和QSPI Flash的download和debug（通過查詢外部Boot模式來切換這兩種燒寫算法）；

（5）一切準備就緒，在點擊debug之前記得確認options->debugger下選擇好CMSIS-DAP并且確保Reset類型必須要選擇Core Reset，然后點擊確認保存，最后debug將代碼下載到外部QSPI Flash里并調試或者重新上電測試，hello world仍然讓人激動不已，不容易啊不容易。

上述兩種外部SPI Nor Flash的啟動配置方式僅僅是以hello world工程為例了，實際上大家可以參照如上幾個步驟任意porting到SDK的其他工程實例里面去，而且由于SDK_2.3.0_EVK-MIMXRT1050\devices\MIMXRT1052\xip目錄是共享的文件（包括Flashloader也是共享的），所以添加的那四個文件內容不需要再修改了，只需要手動添加文件到工程和配置IAR相關選項即可，操作起來還是比較快的。

代碼跑在SPI Flash數據跑在SDRAM的使用方法3

前面比較詳細的講了HyperFlash和QSPI Flash的啟動方式，趁著興致尚在我們再加點餐。我相信在很多客戶開發RT105x過程中，將code跑在外部SPI Flash里，而數據存放在外部SDRAM里面會是比較常用的一種選擇（比如一些會用到高分辨率的GUI顯示方面，內部RAM不夠用了）。雖然前面提到的xip那四個文件（兩個.c和兩個.h）里面的fsl_flexspi_nor_boot.c文件有定義dcd_sdram這個常量，不過很快就會發現這個常量數組里面的數據很大且看不出什么意義來（看不出意義就意味著不知道怎么修改），這是因為這個常量數組里面是編譯后的可執行命令，它是根據不同的SDRAM編譯后的結果，也就意味著不同的SDRAM這個數組是不一樣的，這就尷尬了，客戶如果不是使用EVK板載的SDRAM的話該怎么搞呢？哈哈，這個倒是不用擔心，官方很快會推出一個輔助工具來生成不同SDRAM的DCD常量數組，不過在此之前我們也不能干等著吧，所以本章節的“加餐”就是提出一種workaround先提前解決下這個問題。

我們要知道，在系統上電前無論代碼還是數據都是存在SPI Flash這些非易失存儲介質里面的，待上電后程序會有一個Copy過程將數據或者想要在RAM里執行的代碼copy到RAM里面去，對內部RAM來講無所謂（因為一上電內部的SRAM就已經初始化完成了）而對外部SDRAM來說是需要事先初始化RT105x的SDRAM控制器才能往該SDRAM可尋址的空間copy內容的。幸運的是在Copy之前我們是有段緩沖時間的，恰恰就是這段緩沖時間給了我們有可以不使用DCD配置的機會（實際上DCD也是ROM在跳到應用代碼之前讀取其內容對SDRAM進行初始化）。以IAR的啟動代碼為例，打開startup_MIMXRT1052.s文件找到CPU的起始入口Reset_Handler如下圖，執行的Copy過程實際上是在__iar_program_start這個函數里面實現的（具體內容使用的是IAR自己的庫, Keil是在__main里實現的），而在該函數之前（即在SystemInit函數里面）我們只需要將SDRAM初始化好讓其Ready了就不會影響后續數據的copy和使用，所以下面我就簡單介紹下具體操作方法。

（1）仍然是在當前hello world工程下，點擊IAR菜單欄Project->Edit Configurations繼續新建一個工程配置并以上面的HyperFlash_bootok為藍本將新的配置命名為“flexspi_code_sdram_data”如下圖，然后點擊Ok進入該配置模式下；

（2）打開system_MIMXRT1052.c系統配置文件，也就是SystemInit函數所在的文件里面添加如下圖所示SDRAM初始化相關的函數并在SystemInit的最后調用就可以在使用SDRAM之前將其初始化（具體修改后的源文件見隨文檔附帶的壓縮包），而且初始化函數均是以C語言形式讀寫配置SDRAM相關寄存器，這樣的話即使SDRAM更換了也可以隨時修改初始化寄存器配置以適配不同的SDRAM了，俗話說未知是最可怕的，而一旦都是開放的話就沒那么難了。至于SDRAM這塊的初始化是怎么找到的呢，實際上就是將SDRAM的預處理文件（當前目錄下的evkmimxrt1050_sdram_init.mac）里面的命令用C語言實現了而已；

（3）由于仍然是為了兼容性問題，上面使用了預編譯命令判斷HYBERFLASH_SDRAM宏來決定是否初始化SDRAM，所以在當前工程配置下需要添加HYBERFLASH_SDRAM宏聲明以使在當前工程配置下SDRAM初始化生效；

（4）然后需要修改下鏈接文件，將數據都分配到SDRAM地址范圍內，將MIMXRT1052xxxxx_hyperflash_nor_bootok.icf復制后重命名為MIMXRT1052xxxxx_flexspi_code_sdram_data.icf，打開該文件，添加data3相關信息之后保存該鏈接文件，并在Options->Linker文件里選擇新的鏈接文件（源文件見隨文檔附帶的壓縮包），點擊確定保存配置；

（5）一切都修改完畢之后，點擊編譯鏈接，再打開.map文件即可看到所有的數據變量已經被分配到外部SDRAM的尋址空間里面了，最后再點擊debug將代碼下載到外部SPI Flash里面（注意SW7啟動模式記得修改成HyperFlash啟動，因為本例子演示的是code跑在HyperFlash里，數據跑在SDRAM里），這樣就完美實現代碼在SPI Flash里執行而數據跑在SDRAM里。當然，hello world本身沒多少數據，大家可以把該功能照本宣科的poring到復雜一點的應用里面或者在當前工程里面自己memory alloc一段足夠大的數據區，然后讀修改寫的去操作以測試該方法的可靠性，我這里就不多說了。

GD和Winbond 3.3v QSPI Flash啟動4

在第2.2章節里我已經介紹了RT1050 EVK板載1.8v ISSI的QSPI Flash的啟動方法，不過經過一段時間客戶的反饋，實際上市面上常用的QSPI Flash目前以GD和Winbond的3.3v產品居多，物美價廉且采購渠道豐富，所以我特意增加了第4章用來專門介紹下GD和Winbond 3.3v QSPI Flash啟動方法并修改優化了Keil下對這兩家QSPI Flash的燒寫算法供客戶在keil下擦寫和debug。

硬件上仍然是以我們官方RT1050的EVK板子為調試平臺，在2.2章節的硬件改動基礎上焊掉ISSI的QSPI Flash，換成GD的GD25Q32CSIG 3.3v QSPI Flash（3腳和7腳仍然上拉電阻到VDD），然后將下圖中EVK板子R49的0歐姆電阻去掉，R301用0歐姆電阻短接，即將Flash電源由之前的1.8v改成3.3v，其他部分硬件與2.2章節保持一致，接下來我介紹Keil環境下的配置方法（前面的示例用的IAR，這次用keil讓大家對IAR和keil下的開發配置都熟悉一遍）：

（1）首先打開Keil下SDK開發包的hello_world_xip工程（路徑demo_apps\hello_world_xip\mdk，Keil自帶xip的工程），默認只有hello_world_xip Flexspi_nor_debug和hello_world_xip Flexspi_nor_release兩個跑在板載HyperFlash的工程配置，點擊Keil菜單欄Project->Manage->Project Items，我們新添加一個工程配置hello_world_xip Qspi_nor_debug如下圖，然后選擇該工程配置為當前工程，最后點擊OK確認：

（2）在新建的工程配置里，右鍵工程Options->C/C++，添加QSPI_BOOT和XIP_EXTERNAL_FLASH這兩個宏如下圖1，然后打開工程目錄下xip->fsl_flexspi_nor_flash.c文件，參考2.2章節中（2）點，手動添加QSPI的Flash Configuration Parameters元素信息如下圖2，有一點不同的是我們官方板子的ISSI QSPI Flash的最高時鐘可以到133MHz，而Winbond的QSPI最高到80MHz，GD QSPI最高到120MHz，我板子上自己焊了一塊GD的GD32Q32CSIG QSPI Flash，所以將serialClkFreq設定為kFlexSpiSerialClk_100MHz，然后sflashA1Size改成4M Bytes；

（3）由于keil下自帶了xip的工程，所以我們就直接復用其現成的.scf鏈接文件即可不用做修改，如下圖Options->Linker。而且keil下也已經添加了Keep變量以防止xip這幾個元素信息因為程序里沒有調用而自動被編譯器優化掉（注意：下圖顯示窗口有限，實際上要keep的信息段包括.boot_hdr.ivt，.boot_hdr.boot_data，.boot_hdr.dcd_data和.boot_hdr.conf，格式參考下圖）；

（4）至此我們編譯整個工程，最后打開生成的.map文件如下圖可以看到我們想要的幾個QSPI啟動必須的元素信息頭都已經正確的分配到image文件里了；

（5）支持QSPI啟動的完整image文件通過以上幾步我們已經解決了，接下來要解決keil下download、Erase和debug需要的QSPI Flash燒寫算法問題，本文檔附帶的壓縮包文件里路徑Firmware\Keil_Algorithm下MIMXRT_QSPIFLASH.FLM文件為我已經優化修改好的可以支持ISSI，GD和Winbond燒寫的Flash算法，將其copy到keil安裝路徑下C:\Keil_v5\ARM\Flash即可，然后右鍵工程options->Debug-> CMSIS-DAP debugger，進入settings->Flash Download，點擊Add找到如下圖所示的MIMXRT_QSPIFLASH（4KB Sec），另外建議給Flash算法預留的RAM空間大一些否則可能會導致算法運行失敗，因為這個flash算法比較占空間，我這里修改成了0x4000大小是沒有問題的；

（6）設置完畢之后，我們再次重新編譯整個工程，然后點擊F8或者keil菜單欄Flash->Download即可完成對外部QSPI的擦除和寫入，待燒寫完畢之后我們點擊debug即可正常調試（建議：如果程序做了修改，在編譯之后進入debug之前先Download一次，再點debug），重新斷電之后程序也可以。