大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家分享的是 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]。
2.3 JEDEC 标准复位
i.MXRT1060 在复位 Flash 上多了一个 JEDEC 标准的硬件复位选项,也包含在步骤 1 里面,这个复位仅针对 Adesto ATXP 系列为代表的 Flash 有效,需要 Flash 本身支持 JEDEC 制定的硬件复位功能。
至此,i.MXRT1060 系列 ROM 中串行 NOR Flash 启动初始化流程优化点痞子衡便介绍完毕了,掌声在哪里~~~