1. 问题现象一个看似“玄学”的启动失败最近在调试一块基于 i.MXRT1060 的板子遇到了一个相当棘手的问题。板载的是一颗 128Mb16MB的 NOR Flash型号是 W25Q128JV。在开发过程中一切功能都运行正常程序下载、调试、运行都没问题。但只要我在应用程序里执行一次软复位比如通过看门狗复位或者直接写内核的复位控制寄存器系统就再也启动不起来了。上电冷启动完全正常唯独软复位后会“变砖”。最让人头疼的是调试器在软复位后也无法连接仿佛芯片“死”了一样。但用万用表量一下电源和复位引脚电压都正常晶振也在起振。问题显然出在芯片启动的最初阶段在它还没来得及执行我的第一行代码之前就卡住了。排查过程一度陷入僵局直到我把目光投向了那颗 NOR Flash。我注意到在正常的冷启动和失败的软复位启动之间有一个关键区别冷启动时Flash 处于默认的 3 字节地址模式而我的应用程序在运行时为了提高大数据量读写的效率将其切换到了 4 字节地址模式。软复位并不会复位 Flash 本身的状态这就导致芯片在复位后试图从 4 字节地址模式的 Flash 中读取启动数据而此时的 BootROM 可能并没有做好处理这种模式的准备。这个问题的核心正是标题所指对于容量大于 16MB即 128Mb的 NOR Flash在运行时切换其地址模式从 3-Byte 切换到 4-Byte Address可能导致后续的软复位Soft Reset无法正常启动。这不是芯片的硬件缺陷而是一个由 BootROM、Flash 配置以及系统复位特性共同作用下的“陷阱”。2. 追根溯源NOR Flash 地址模式与 i.MXRT 启动机制的碰撞要理解这个问题我们必须拆解两个关键角色大容量 NOR Flash 的工作模式以及 i.MXRT 系列芯片的启动流程。2.1 NOR Flash 的地址模式3-Byte vs 4-ByteNOR Flash 通过 SPI 接口与主控通信。对于容量小于或等于 16MB128Mb的 Flash其存储空间可以用 3 个字节24位的地址来寻址因为 2^24 16,777,216正好是 16MB。这是最经典、最兼容的模式。当 Flash 容量超过 16MB比如 32MB256Mb、64MB512Mb甚至更大时3 字节地址就不够用了。这时Flash 支持一种扩展的4 字节地址模式4-Byte Address Mode。在此模式下读写命令后需要跟随 4 个字节的地址数据。关键在于这种模式通常不是默认开启的。小容量 Flash 上电后永远处于 3 字节模式。而大容量 Flash如 W25Q256, MT25QL256ABA 等上电后可能处于一种“兼容模式”即它将自己“伪装”成一个 16MB 的设备只响应低 16MB 空间的访问。要访问高地址空间必须通过特定的命令如Enter 4-Byte Address Mode指令码通常是0xB7显式地切换到 4 字节模式。一旦切换Flash 会保持这个状态直到发生断电、硬件复位或收到退出该模式的命令如Exit 4-Byte Address Mode指令码0xE9。软复位Soft Reset不会切断 Flash 的电源因此无法清除这个状态。2.2 i.MXRT BootROM 的启动探针过程i.MXRT 芯片没有内部非易失性存储器必须从外部设备启动。芯片上电或复位后首先运行的是固化在 ROM 中的 BootloaderBootROM。BootROM 的任务是找到有效的程序映像并跳转执行。其启动流程简化后如下初始化基本系统时钟、GPIO等。根据 BOOT_CFG 引脚或 eFUSE确定要扫描的启动设备类型和接口如 FlexSPI NOR Flash。对指定的启动设备进行“探针Probing”按照预定义的配置时钟频率、CS 极性、采样模式等尝试初始化该接口并尝试从该设备的固定起始地址通常是 0x0 或 0x1000读取数据。解析读取到的数据寻找有效的映像头如 IVT, Boot Data。如果找到就配置相应的硬件如 FlexSPI 的 LUT并加载程序如果找不到就尝试下一个启动设备或配置。问题的症结就在第 3 步BootROM 在探针 FlexSPI NOR Flash 时它发出的初始读命令是什么根据我的实测和对参考手册的解读BootROM 在最初的探针阶段很可能是以最基础的、兼容性最强的 3 字节地址模式来发送读命令的例如0x03命令。它不会也没有义务去主动发送0x13Fast Read with 4-Byte Address或先发一个0xB7进入 4 字节模式。2.3 冲突的形成状态不匹配导致启动失败现在让我们把时间线串起来看看软复位后启动失败的场景上电/冷启动Flash 处于默认状态3 字节模式。BootROM 用 3 字节地址模式命令成功读取到映像头启动成功。应用程序运行为了访问全部 Flash 空间16MB应用程序初始化 FlexSPI 驱动并发送0xB7命令将 Flash 切换到 4 字节地址模式。此后所有读写操作都使用 4 字节地址。触发软复位看门狗溢出、NVIC 系统复位等事件发生CPU 复位重新从 BootROM 开始执行。但 Flash 芯片本身没有复位它依然保持在 4 字节地址模式。BootROM 再次探针BootROM 依旧使用它预设的 3 字节地址模式命令去读取 Flash 的起始地址。读取失败对于处于 4 字节模式的 Flash收到一个 3 字节地址的命令其行为是未定义的。它可能忽略该命令可能返回错误数据也可能根本不响应。结果就是 BootROM 无法从预期的地址读到有效的 IVT 数据。启动流程中止BootROM 认为在这个配置下没有找到有效启动设备它可能会尝试其他配置如降低时钟频率但如果所有预设配置都失败则启动流程挂起芯片表现为“死机”。这就完美解释了为何调试器无法连接芯片在 BootROM 阶段就卡住了根本没有加载并执行用户程序自然也就无法运行调试器所需的驻留代码。注意这个问题并非在所有 i.MXRT 型号或所有 Flash 型号上必然发生。它取决于两个因素一是 BootROM 探针阶段命令序列的具体实现不同芯片型号、不同版本的 BootROM 可能有差异二是 Flash 芯片在收到不匹配模式命令时的具体行为。但这是一个已知的风险点在设计中必须考虑。3. 解决方案在软复位前将 Flash 恢复至安全状态既然知道了问题的根源是 Flash 的状态与 BootROM 的预期不匹配那么解决方案就很清晰了在应用程序中在执行任何可能触发软复位的操作之前必须先将 NOR Flash 切换回 BootROM 能够识别的状态。通常这个安全状态就是3 字节地址模式。对于支持“退出4字节模式”命令0xE9的 Flash这是最直接的方法。对于某些 Flash可能需要通过写使能后发送特定命令序列来重置。下面是一个针对常见 SPI NOR Flash如 Winbond、Macronix 系列的示例处理流程。这段代码应该放在你的系统复位函数、看门狗复位处理函数或者任何可能导致软复位的代码路径之前。/** * brief 将外部 SPI NOR Flash 切换至 3-Byte 地址模式确保软复位后能正常启动。 * note 此函数应在执行软复位如 NVIC_SystemReset前调用。 * param flexspi_base FlexSPI 外设基地址如 FLEXSPI1。 * param lut_seq_index 用于发送命令的 LUT 序列索引。需提前在 LUT 表中配置好。 */ void flash_Ensure3ByteModeBeforeReset(FLEXSPI_Type *flexspi_base, uint8_t lut_seq_index) { flexspi_transfer_t flashXfer; uint32_t dummy_data 0; // 1. 写使能 (Write Enable, 0x06) flashXfer.deviceAddress 0; flashXfer.port kFLEXSPI_PortA1; flashXfer.cmdType kFLEXSPI_Command; flashXfer.SeqNumber 1; // 假设 LUT 序列1是写使能命令 flashXfer.seqIndex 1; FLEXSPI_TransferBlocking(flexspi_base, flashXfer); // 2. 发送退出 4-Byte 地址模式命令 (Exit 4-Byte Address Mode, 0xE9) // 如果 Flash 不支持 0xE9可能需要发送其他复位命令如 Enable Reset (0x66) Reset (0x99) flashXfer.cmdType kFLEXSPI_Command; flashXfer.SeqNumber 1; flashXfer.seqIndex lut_seq_index; // 此索引对应的 LUT 应配置为发送 0xE9 命令 FLEXSPI_TransferBlocking(flexspi_base, flashXfer); // 3. 可选增加一个小的延时确保 Flash 内部状态稳定 SDK_DelayAtLeastUs(10, SystemCoreClock); // 4. 验证尝试以 3-Byte 模式读取 Flash ID (JEDEC ID) // 这是一个好习惯可以确认模式切换是否成功 uint8_t jedec_id[3] {0}; flashXfer.cmdType kFLEXSPI_Read; flashXfer.seqIndex ...; // 配置为发送 0x9F (Read JEDEC ID) 命令的 LUT 序列 flashXfer.data jedec_id; flashXfer.dataSize 3; FLEXSPI_TransferBlocking(flexspi_base, flashXfer); // 可以在这里检查 jedec_id 是否与预期相符 // if (jedec_id[0] ! MANUFACTURER_ID) { /* 处理错误 */ } }关键实现细节与避坑指南LUT 配置是核心FlexSPI 的所有通信都通过查找表LUT定义序列。你必须提前在 FlexSPI 的初始化代码中为“退出4字节模式”命令0xE9和后续的验证命令如读ID0x9F配置好独立的 LUT 序列。不能直接使用运行时读写数据的序列因为那些序列可能依赖于4字节模式。命令序列的完整性有些 Flash 退出4字节模式需要先写使能0x06。务必查阅你的 Flash 数据手册严格按照时序要求操作。复位命令的替代方案如果 Flash 不支持0xE9命令有些较新的 Flash 使用0x660x99的复位序列来达到类似效果复位后 Flash 会恢复到上电默认状态包括地址模式。最保险的方法是直接使用硬件复位引脚复位 Flash但这需要额外的 GPIO 控制增加了硬件复杂度。调用时机这个函数必须在任何软复位发生前被调用。最稳妥的位置是看门狗刷新函数如果看门狗用于复位的最末尾在刷新操作之前。自定义NVIC_SystemReset()封装函数内部的第一行。如果系统有“重启”按钮或命令处理该事件的函数中。验证环节必不可少仅仅发送命令是不够的。通过读取 Flash 的 JEDEC ID 或状态寄存器来验证它确实回到了 3 字节模式可以避免因命令发送失败而导致的隐性故障。在生产测试中这可以作为一个诊断项。4. 更优的架构设计从根源上避免状态冲突上述解决方案是“补救式”的需要在代码中小心地插入状态恢复逻辑。一个更健壮的设计是从系统架构层面减少或消除这种状态冲突的可能性。4.1 策略一坚持使用 3-Byte 只读模式启动如果你的应用程序不需要访问 16MB 以上的 Flash 空间那么最简单的方法就是永远不切换至 4 字节模式。所有操作都基于 3 字节地址。这完全避免了状态不一致的问题。对于很多应用来说16MB 的代码空间已经绰绰有余。4.2 策略二利用 FlexSPI 的 AHB 命令与 IP 命令分离特性i.MXRT 的 FlexSPI 模块有一个高级特性它可以配置两套命令序列——一套用于 AHB 总线访问即 CPU 指令/数据取指另一套用于 IP 命令即通过寄存器触发的自定义序列。一个巧妙的做法是AHB 命令序列LUT始终配置为 3 字节地址模式。这保证了 BootROM 和 CPU 的常规取指操作永远使用兼容模式。当需要访问高地址16MB时不使用 AHB 映射地址直接访问而是通过 FlexSPI 的 IP 接口执行一个特殊的、配置为 4 字节地址模式的自定义序列Custom Sequence来完成读写。这样Flash 器件本身可能被我们通过 IP 命令临时切到了 4 字节模式但负责启动和常规取指的 AHB 通道发出的永远是 3 字节命令。这需要对 FlexSPI 驱动进行更精细的设计但一劳永逸地解决了启动兼容性问题。4.3 策略三在 Bootloader 中统一管理 Flash 状态如果你的系统有二级 Bootloader比如用于固件升级的 MCUBoot 或自定义 Bootloader可以将 Flash 状态管理职责上交给 Bootloader。Bootloader 永远以 3 字节模式运行它负责硬件初始化和应用程序映像的验证。在跳转到应用程序之前Bootloader 根据应用程序头信息中的某个标志位判断该应用程序是否需要 4 字节模式。如果需要Bootloader 在跳转前将 Flash 切换到 4 字节模式并将这个信息通过参数如某个寄存器传递给应用程序。应用程序被设计为“只进不退”它假设自己运行在 4 字节模式下并且不再切换回去。任何复位操作都被视为“冷复位”由 Bootloader 重新接管并决定模式。应用程序如果需要复位不再使用软复位而是控制一个 GPIO 去触发硬件复位电路实现真正的“冷启动”让 Bootloader 重新开始整个流程。这种策略将模式切换的时机提前到了安全的 Bootloader 阶段并且将复位策略从“软复位”改为“硬复位”虽然增加了些许启动时间但系统状态更加清晰和可控。5. 调试与诊断当问题发生时如何定位如果你已经遇到了软复位启动失败的问题并且怀疑是 Flash 地址模式导致的可以按以下步骤进行诊断确认 Flash 型号与容量首先检查原理图和芯片丝印确认你使用的 NOR Flash 容量是否确实大于 16MB128Mb。检查应用程序代码在代码中全局搜索0xB7Enter 4-Byte Address、0xE9Exit 4-Byte、0x13Fast Read 4-Byte等命令码或者搜索FLEXSPI初始化的代码看是否有配置 4 字节模式的逻辑。使用逻辑分析仪或示波器这是最直接的证据。在软复位触发瞬间和之后抓取 FlexSPI 的 CLK、CS#、SI、SO 信号。正常冷启动你应该能看到 BootROM 发出的第一个读命令很可能是0x03的波形地址是0x000000。失败的软复位启动抓取复位后的同样时间段。观察 BootROM 发出的第一个命令是什么如果 Flash 处于 4 字节模式这个命令可能会被 Flash 误解导致返回的数据异常全0、全F或随机值。你可以对比两次抓取的命令码和数据线波形。编写一个简单的诊断程序在应用程序中在准备复位前先读取 Flash 的状态寄存器如 Status Register 3其中往往有一个位例如ADS指示当前是否处于 4 字节地址模式。将这个信息通过 LED、串口或者保存在某个不会被复位清除的寄存器如 i.MXRT 的 GPR中以便在复位后检查。利用芯片的启动配置有些 i.MXRT 芯片支持从多个 FlexSPI 配置启动。你可以尝试在 BootROM 探针阶段使用不同的时钟频率或采样模式有时更保守的配置更低频率可能对非标准 Flash 状态有更好的容错性。但这只是权宜之计根本问题仍需解决。通过以上方法你可以准确地定位问题是否由地址模式冲突引起。记住嵌入式系统调试中“状态”是最容易忽略的敌人。任何在复位过程中保持不变的设备状态都可能成为下一次启动的绊脚石。NOR Flash 的地址模式正是这样一个典型的“状态陷阱”。解决它需要我们对整个启动链路上的每一个环节都了如指掌。
