痞子衡嵌入式：瞭解i.MXRT1060系列ROM中序列NOR Flash啟動初始化流程優化點

　　大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家分享的是i.MXRT1060系列ROM中序列NOR Flash啟動初始化流程優化點。

　　前段時間痞子衡寫了一篇《深入i.MXRT1050系列ROM中序列NOR Flash啟動初始化流程》，那篇文章如果你認真讀，你會發現為了能讓i.MXRT系列儘可能地支援來自不同廠商的不同序列NOR Flash型號，而且還得發揮Flash最好效能，BootROM可謂煞費苦心，做了很多精心設計。

　　i.MXRT1060是在i.MXRT1050之後釋出的，相比i.MXRT1050在FlexSPI NOR啟動初始化上有了一些優化點，今天痞子衡就跟大家聊一聊這些優化點（或者說差異的地方）：

備註：本文主角是i.MXRT1060，但內容也基本適用i.MXRT1170，僅細節微小差別。

一、整體初始化流程

　　跟上一篇文章一樣，痞子衡重畫了i.MXRT1060的FlexSPI NOR啟動流程圖，從流程上來看，其和i.MXRT1050有兩處主要差異，第一個是步驟0（冗餘App啟動支援）和步驟X（Auto Probe），除此以外，還有一些微小差異（JEDEC硬體復位，延時等待策略等）。

二、初始化流程差異

　　本文不會介紹步驟X（Auto Probe特性），主要是說一下其他差異，步驟X是個特別重要的改進，痞子衡會另起一文單獨介紹。

2.1 冗餘App啟動

　　第一個要提的便是新增的冗餘App啟動支援，即步驟0，痞子衡之前寫過一篇文章《利用i.MXRT1060,1010上新增的FlexSPI地址重對映(Remap)功能可安全OTA》，這篇文章的第二節講了i.MXRT1060上多了一個Remap功能，這個功能使得Flash裡可以存放多份相同連結地址的XIP App（偏移0x0處固定放App1；偏移0x100000處（這個地址使用者自定義）放了App2），藉助Remap功能可以將Flash裡App2在記憶體對映地址上直接覆蓋到App1處，不需要物理上的實際搬移。

fuse 0x6e0[15:13] - xSPI_FLASH_IMAGE_SIZE，第二份App的實際位置，即填入Remap功能的ADDR_END暫存器的值。
fuse 0x6e0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET，第二份App的實際大小，即填入Remap功能的ADDR_OFFSET暫存器的值。

　　BootROM中支援冗餘App啟動，並不是常見的OTA用意，而是防App誤損壞導致裝置無法啟動，因此App1固定在偏移0x0地址，App2永遠是覆蓋App1，這意味著App2必須跟App1一樣都是包含FDCB, IVT, BootData等完整啟動頭的App。BootROM上電永遠先嚐試啟動App1，如App1無法啟動，則嘗試啟動App2。我們知道，多份App都損壞是小概率事件。

備註1：這個功能在i.MXRT1010上同樣存在，畢竟i.MXRT1010支援Remap。

備註2：這個功能雖存在於i.MXRT1170上，但步驟移到了FlexSPI第二次初始化之後。

2.2 延時等待策略

　　在i.MXRT1050 FlexSPI NOR啟動初始化步驟4裡的善後工作裡，有一個藉助呼叫microseconds_delay()做延時以使FlexSPI外設以及Flash完全準備好的操作，這個操作在i.MXRT1060上被從步驟4移到了步驟1前後，即復位Flash前做一次，復位Flash後再做一次。

備註1：復位Flash前的那一次延時操作，實際hold time要減去3ms（如hold time設定小於3ms，則只減3ms），因為復位Flash前屬於系統上電啟動，ROM本身執行到開始訪問Flash就需要時間，所以Flash差不多有近3ms的上電等待時間了。

備註2： hold time在fuse中的位置從i.MXRT1050上的0x450[3:2]被移到了i.MXRT1060上的0x6e0[5:4]。