i.MXRT1060在串行NOR Flash启动初始化流程上做了哪些优化？

NXP管管

i.MXRT1060在串行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处，不需要物理上的实际搬移。

1. fuse 0x6e0[15:13] - xSPI_FLASH_IMAGE_SIZE，第二份App的实际位置，即填入Remap功能的ADDR_END寄存器的值。
   
2. 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. 备注1：这个功能在i.MXRT1010上同样存在，毕竟i.MXRT1010支持Remap。
   
2. 备注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]。

2.3 JEDEC标准复位
i.MXRT1060在复位Flash上多了一个JEDEC标准的硬件复位选项，也包含在步骤1里面，这个复位仅针对Adesto ATXP系列为代表的Flash有效，需要Flash本身支持JEDEC制定的硬件复位功能。

至此，i.MXRT1060系列ROM中串行NOR Flash启动初始化流程优化点痞子衡便介绍完毕了，掌声在哪里~~~

阅读全文