痞子衡嵌入式：RT-MFB - 一种灵活的i.MXRT下多串行NOR Flash型号选择的量产方案-CSDN博客

本文链接：https://blog.csdn.net/Henjay724/article/details/127219242

　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是一种灵活的i.MXRT下多串行NOR Flash型号选择的量产方案。

　　对于以 i.MXRT 这类没有内部 NVM (Non-Volatile Memory) 的 MCU 为主控的项目来说，为其选配一颗 NVM 作为代码存储器是头等大事，而串行 NOR Flash 是最常见的 NVM 选择。串行 NOR Flash 要能被 i.MXRT 正常启动，其固定偏移处(0x0/0x400)一般要求放置一个配套启动头(FDCB)，系统上电 BootROM 会用 30MHz 1bit SPI SDR 时序模式去读取这个启动头来获取当前 Flash 的相关属性(主要是用户设定的时序模式)从而进一步配置片内 FlexSPI 模块以指定的时序模式去启动 Flash 里的固件应用程序。

　　到了项目量产阶段，尤其是出货量大的消费类产品，我们往往不会仅选择某一 Flash 厂商产品(价格因素，供货因素等)，这时候就不得不考虑一个问题，如果选择的是特性不完全一致的两颗 Flash，那么下载进 Flash 的固件应用程序能不能保持一样(其实主要就是下图中的 FDCB1/2 差异问题怎么解决)？今天痞子衡就跟大家讨论一下这个问题：

Note：本文主要针对的是普通四线 QuadSPI / 八线 OctalSPI 类型的串行 NOR Flash。

一、影响多Flash型号量产的因素

　　我们知道导致下载进不同 Flash 里的固件程序有差异的主要原因是 i.MXRT 配套启动头(FDCB)，这个 FDCB 描述了 Flash 的基本信息(Device 容量、速度、读模式命令等)，Flash 属性不同，FDCB 也会跟着变化，所以我们先来介绍下有哪些可能的因素会影响 FDCB 内容：

1.1 QE bit位置

　　首先是 QE bit 使能操作的差异。很多 Flash 出厂时 QE bit 并没有被使能，量产过程中烧录器有时候也未必去使能 QE bit(一线模式编程相比 Multi I/O 模式编程对量产时间影响不大)，这种情况在 FDCB 里需要加上使能 QE bit 操作，而 QE bit 在 Flash 内部寄存器里的定义以及写入命令有好几种，详见痞子衡旧文《影响下载/启动的常见因素之QE bit》。

1.2 READ命令中Dummy Cycles数

　　使能 QE bit 是为了能让 Flash 工作在 Multi I/O Fast READ 模式，但这时候 READ 时序里会有 Dummy Cycles 周期(即 Flash 接收到主设备发来的读命令从而准备相应数据的反应时间)。Flash 的不同工作频率对应的最小 Dummy Cycles 不同，不同厂商关于 Dummy Cycles 数要求也不同，此外如果 Flash 里的默认 Dummy Cycle 不是对应最高工作频率的话，要想让 Flash 工作在最高频率还需要额外设置 Flash 相应寄存器来修改 Dummy Cycle(这里的设置方法也不同)，这些 Dummy Cycle 设定都要体现在 FDCB 里，详见痞子衡旧文《调整Flash工作频率也需同步设Dummy Cycle》。

1.3 地址3B/4B模式切换

　　对于不高于 16MB 容量的 Flash，在 READ 时序里一般使用三字节地址就行了，但是超过 16MB 的 Flash ，对其访问就会涉及三字节地址以及四字节地址选择问题，因此避不可免地要考虑 Flash 地址模式切换问题，不同厂商的地址模式设计以及切换操作也略有不同，FDCB 里同样要考虑这些，详见痞子衡旧文《16MB以上NOR Flash使用注意》。

1.4 QPI/OPI模式进入

　　如果为了追求极限执行性能，一般还会考虑将 Flash 从 SPI 模式切换到 QPI/OPI 模式，这里不同厂商的模式切换设计也可能略有不同，FDCB 也要负责这个工作，详见痞子衡旧文《使能串行NOR Flash的QPI/OPI模式》。

1.5 DTR/Continuous read性能模式

　　当然还有一些其它关于 Flash 性能模式考量，比如 DTR 模式、Continuous read 模式，要想使能这些模式也都需要在 FDCB 里做文章，详见痞子衡旧文《使能串行NOR Flash的DTR模式》、《使能串行NOR Flash的Continuous read模式》。

二、多Flash型号量产的解决方案

　　上一节介绍了有很多因素会导致 FDCB 不同，这些因素都是多 Flash 型号量产路上的拦路虎，我们有什么方法能规避这些因素差异带来的问题呢？主要有如下两个方案：

2.1 BootROM自识别方案

　　第一个方案是利用 i.MXRT 芯片 BootROM 里的功能，详见痞子衡旧文《自识别特性(Auto Probe)可以无需FDCB也能从NOR Flash启动》。这个特性可以让我们不用提供 FDCB，芯片也能正常从 Flash 里启动固件应用程序，这样也就自然不存在量产过程中不同 Flash 里固件差异问题。但是这个方案也有几个明显的缺点：

缺点一：Auto Probe 特性在 i.MXRT1010/1020/1050 上不可用，仅在 i.MXRT1060/1170/500/600 上可以用。
缺点二：Auto Probe 特性对于不同 Flash 的支持(尤其是 OctalSPI Flash)可能需要通过烧写 i.MXRT 芯片 OTP 来实现，这样实际上是把 FDCB 差异转化到 OTP 差异上了。
缺点三：Auto Probe 特性仅能处理基本的 FDCB 差异(比如 QE，比如 Dummy Cycle)，但是一些性能模式相关的差异不能很好地处理，拓展性不足。

2.2 一线模式FDCB启动+二级Configurer程序

　　第二个方案主要是为了解决方案一里的全部缺点，即使用通用的一线低速模式的 FDCB 启动头给 BootROM 去读取启动，然后再设计一个二级的 Configurer 程序(被 BootROM 启动的代码)，在这个 Configurer 程序里去做 Flash 差异化的相关事情并将 FlexSPI 模块配置到指定时序模式，最后再由这个 Configurer 程序去启动固件应用程序。

　　这里的 Configurer 程序设计是关键，而其中最核心的是如何识别当前 Flash 型号，这里要感谢 JEDEC 组织，目前几乎全部主流 Flash 都支持一线模式下 Read JEDEC 命令(0x9F)，返回的 Manufacturer ID 就是每个 Flash 厂商向 JEDEC 组织申请的识别码，然后 Memory Type 是各厂商自己定义的型号系列分类。Configurer 程序结合这两个参数就可以识别当前 Flash 具体型号，底下就是做不同的代码分支去处理不同的 Flash 配置即可。

　　二级 Configurer 程序说起来很简单，其实具体设计起来还是有很多细节要考量的(比如 FlexSPI 多次配置中系统时钟切换问题、应用程序跳转等)，因此痞子衡开源了这个项目(RT-MFB)，并且会长期维护下去，希望将来能支持尽可能多的 Flash 型号。第一版是以 MIMXRT595-EVK 上的两颗 Flash 为原型(IS25WP064A / MX25UW51345G)来做的。