当前位置：首页 > news >正文

i.MX RT600串行NOR Flash启动配置全解析：从BootROM原理到XIP映像烧录实战

news 2026/6/8 21:22:57

1. 项目概述

最近在调试一块基于NXP i.MX RT600系列处理器的板子，核心需求是实现从板载的串行NOR Flash（Octal SPI Flash）上电自启动。对于没有内部Flash的i.MX RT系列跨界处理器来说，外部Flash的启动配置是项目初期必须打通的关键一环。这个过程涉及到启动模式的选择、引导映像的生成、Flash配置块的烧写以及最终的验证，任何一个环节出错都可能导致芯片“变砖”或者无法启动。网上关于RT600的资料相对RT1050等热门型号要少一些，官方应用笔记（AN12773）虽然详尽，但更像一份技术规格书，缺乏一些实际动手时的“手感”和避坑指南。我结合官方SDK和EVK板，把从原理到实操的完整流程走了一遍，过程中踩了不少坑，也总结了一些文档里没写的细节。这篇文章就来详细拆解i.MX RT600如何配置从串行NOR Flash启动，我会尽量用直白的语言，把原理、步骤和注意事项讲清楚，目标是让你看完就能在自己的板子上复现。

简单来说，i.MX RT600上电后，固化在芯片内部ROM中的引导加载程序（BootROM）会首先运行。它的任务就是找到你的应用程序代码并跳转执行。代码可以放在哪里呢？对于RT600，主要就是外部的串行NOR Flash（通过FlexSPI接口连接）或者SD卡。所谓“主引导”（Master Boot），就是指BootROM直接从这些预设好的主要存储介质启动，而不是进入等待下载的ISP模式。我们今天聚焦的，就是最常用、性能也较好的FlexSPI NOR Flash启动。这不仅能将代码加载到内部SRAM运行，还能支持XIP（eXecute-In-Place，就地执行）模式，让CPU直接从外部Flash取指运行，这对于代码体积较大、SRAM装不下的应用场景至关重要。

2. i.MX RT600启动机制深度解析

在动手配置之前，必须吃透RT600的启动逻辑。这就像你要去一个陌生的地方，总得先看懂地图和交通规则。RT600的启动流程设计得非常灵活，但也因此增加了一些复杂性。

2.1 启动源决策：OTP与ISP引脚

BootROM上电后第一件事，就是决定去哪儿找启动映像。这个决策链非常清晰，遵循“OTP优先，引脚备用”的原则。

OTP（One-Time Programmable）：这是熔断在芯片内部的一次性可编程存储器。里面有个关键的配置字叫BOOT_CFG[0]。它的低4位（PRIMARY_BOOT_SRC）如果被编程（即不是默认的4‘b0000），那么BootROM就会无条件地使用OTP里设定的启动源，完全忽略外部引脚的状态。OTP一旦烧写就无法更改，所以通常用于产品量产阶段，锁定最终的启动方式，防止被意外修改。

ISP引脚（PIO1_15, PIO1_16, PIO1_17）：如果OTP的PRIMARY_BOOT_SRC位没有被编程（保持默认值），那么BootROM就会去读取这三个引脚在上电复位时的电平状态，根据其组合来决定启动模式。这是我们开发阶段最常用的方式，通过板上的拨码开关就能灵活切换。

官方手册里那个ISP引脚状态表是必看的，但光看表容易懵，我把它翻译成更易懂的决策逻辑：

全为低 (0,0,0)：保留模式，不要用。
FlexSPI Port B启动 (0,1,0)：从FlexSPI接口的B端口连接的Flash启动。这是我们EVK板子的默认配置，因为Octal Flash就挂在Port B。
FlexSPI Port A启动 (0,1,1)：从FlexSPI接口的A端口连接的Flash启动。
串行ISP模式 (1,1,0)：这是下载模式。BootROM会等待通过UART、SPI、I2C或USB-HID等接口连接上位机工具（如blhost），接收命令来编程Flash或进行其他操作。我们烧写Flash映像前，必须先把板子切到这个模式。
其他组合：对应SD卡、eMMC、USB DFU等启动方式，这里不展开。

关键经验：开发过程中，你的拨码开关会在ISP模式（1,1,0）和目标启动模式（如Port B启动的0,1,0）之间来回切换。前者用于烧录，后者用于验证启动。一定要养成“烧录前检查开关，启动前检查开关”的习惯，很多“芯片没反应”的问题根源就在这里。

2.2 引导映像的格式与寻址

BootROM确定了启动源（比如FlexSPI）之后，它就知道该去哪个“地址”找东西了。对于串行NOR Flash，这个固定的偏移地址是0x1000。也就是说，BootROM会直接去Flash的0x1000地址处读取数据。

它期待在这里找到的是一个符合特定格式的“引导映像”。这个映像的开头必须是一个64字节的映像头（Image Header）。你可以把这个头理解为这个映像的“身份证”和“说明书”。BootROM会先把这个头读进来分析，里面有几个关键字段决定了后续行为：

imageType (偏移0x24)：这个字段告诉BootROM这是一个什么类型的映像。对我们最重要两种是：
- 0x0000- 明文映像（Plain Image）：不加密，不签名，无CRC。最简单，用于早期开发。
- 0x0005- 带CRC校验的XIP映像（Plain CRC XIP Image）：支持就地执行，并且有CRC校验保障完整性。这是产品中推荐的类型。
- 其他类型涉及加密和签名，用于安全启动，更复杂。
imageLoadAddress (偏移0x34)：这是整个启动逻辑中的核心指针！它存储了一个地址值。BootROM在初步检查头合法后，会把这个值当作一个指针，去它指向的位置再次寻找一个映像头并进行验证。这个设计实现了类似“二级引导”或“向量表重定位”的机制。
- 对于非XIP映像（代码需拷贝到SRAM运行），imageLoadAddress通常指向内部SRAM的某个地址（如0x00080000），并且那个地址处必须存放着与0x1000处相同的映像头。BootROM验证通过后，会把整个映像从Flash加载到这个地址指向的SRAM区域，然后跳转执行。
- 对于XIP映像（代码在Flash中直接运行），imageLoadAddress必须指向Flash中的一个地址（固定为0x08001000）。0x08000000是FlexSPI接口映射到CPU地址空间的起始地址。BootROM验证通过后，不会搬运代码，而是直接配置好FlexSPI控制器，然后CPU就从0x08001000开始取指执行。
imageLength (偏移0x20)和crcChecksum (偏移0x28)：定义了映像的长度和CRC32校验值。如果映像类型使能了CRC校验，BootROM会计算并比对，确保数据完整。

理解了这个头结构，你就明白了为什么链接脚本和生成最终二进制文件如此重要——工具链必须帮我们把正确的值填到这些固定偏移的位置。

2.3 Flash配置块（FCB）与自动探测（Auto-probe）

BootROM找到了映像头，决定要从Flash里读数据了。但问题来了：它怎么跟这块Flash通信呢？FlexSPI控制器需要正确的配置（时钟频率、命令序列、时序参数等）才能驱动不同厂家、不同型号的NOR Flash。

这里BootROM提供了两种机制来获取这些配置信息：

1. Flash配置块（FCB）：这是最通用、最推荐的方式。BootROM会在Flash物理地址的0x400偏移处寻找一个512字节的数据块。如果这个数据块的前4个字节是魔数0x42464346（即字符“FCFB”），它就会把这512字节全部读入SRAM，并按照其中的参数配置FlexSPI控制器。这个FCB需要我们在编译生成最终烧写文件时，由工具（如elftosb或IDE的插件）根据我们提供的Flash型号信息生成，并放置在二进制文件的0x400偏移处。烧录时，这个FCB会连同应用程序一起被烧写到Flash的0x400地址。

2. OTP自动探测（Auto-probe）：这是一种简化的方式。你可以烧写OTP中的FLEXSPI_AUTO_PROBE_EN等字段，告诉BootROM：“我的Flash是某大厂（如Micron、Macronix）的某类标准型号（如Octal DDR）”。BootROM内部预置了几组针对这些标准Flash的配置参数，上电时会尝试用这些参数去探测和初始化Flash。这种方式省去了在Flash中存储FCB的步骤，但灵活性差，只支持有限的几种预设Flash型号，且OTP一旦烧写不可更改。

实操心得：强烈建议所有开发阶段都使用FCB方式。这样你可以自由更换Flash型号，只需更新工程配置重新生成FCB即可。把Auto-probe留给对成本极其敏感、Flash型号绝对固定的大批量量产环节，并且要经过充分测试。在EVK上，我们用的Macronix MX25UM51345 Octal Flash就需要FCB。

3. 实战：从零构建并烧写XIP引导映像

理论铺垫完毕，现在进入实战环节。我们以NXP官方EVK-MIMXRT685开发板为例，使用IAR Embedded Workbench和SDK中的gpio_led_output例程，演示如何生成一个可以从Octal Flash启动的XIP映像，并用两种方法烧录。

3.1 开发环境与工程准备

首先确保你的环境就绪：

硬件：EVK-MIMXRT685开发板（Rev.E及以上），USB线（用于供电和串口/调试），拨码开关SW5。
软件：
- MCUXpresso SDK for RT685：版本2.7.0或更高。确保已下载并解压。
- IAR Embedded Workbench for Arm：版本8.40.2或更高。其他IDE如Keil MDK原理类似。
- NXP MCUBootUtility：图形化烧录工具，v2.3以上。对于不熟悉命令行的开发者非常友好。
- blhost命令行工具：通常包含在SDK的tools目录下。适合喜欢脚本化、自动化操作的开发者。

打开SDK中的示例工程：\SDK_2.7.0_EVK-MIMXRT685\boards\evkmimxrt685\driver_examples\gpio\led_output\iar。

3.2 关键工程配置详解

在IAR中打开工程后，不要急着编译。有几个关键配置决定了最终生成的二进制文件是否能被正确引导。

1. 项目配置选择：在IAR的Workspace下拉菜单中，选择flash_debug配置。这个配置已经预设好了针对外部Flash调试和运行所需的编译、链接选项。debug或release配置可能是针对RAM运行的，不适用。

2. 预处理器定义：这是最至关重要的一步。打开项目选项，找到C/C++ Compiler->Preprocessor页面。查看Defined symbols列表。你必须确认BOOT_HEADER_ENABLE=1这个宏定义存在。

作用：这个宏会启用SDK中与启动头（Boot Header）和FCB相关的代码。在链接阶段，链接器会根据这个宏，将Flash配置块（FCB）和映像头数据整合到最终的可执行文件（.out）中。没有它，生成的.bin文件将缺少BootROM赖以启动的“钥匙”。
检查：如果列表里没有，你需要手动添加BOOT_HEADER_ENABLE=1。

3. 链接脚本（.icf文件）检查：flash_debug配置使用的链接脚本（通常是evkmimxrt685_flexspi.icf）决定了代码和数据在内存中的布局。对于XIP映像，关键点在于：

FCB位置：链接脚本必须确保FCB被放置在输出文件的0x400偏移处，并且最终在Flash中也被烧录到物理地址0x400。
代码起始地址：应用程序的入口（通常Reset_Handler）应该被链接到0x08001000（即FlexSPI映射地址0x08000000+ 映像偏移0x1000）。SDK的示例链接脚本已经处理好了这些，通常无需修改，但了解其原理有助于排查诡异问题。

3.3 编译与生成烧录文件

配置无误后，编译工程。编译成功后，在输出目录（如Flash_Debug\Exe）下，你会找到gpio_led_output.out文件。

我们需要的是能被烧录器识别的二进制格式。在IAR中，你可以通过Project->Options->Output Converter来配置生成.bin或.hex文件。更简单的方法是使用IAR的ielftool命令行工具，或者使用我们后面会用的MCUBootUtility直接处理.out或.srec文件。

对于blhost方式，我们需要.bin文件。你可以使用IAR安装目录下的ielftool.exe进行转换：

ielftool.exe --bin gpio_led_output.out gpio_led_output.bin

转换后得到的gpio_led_output.bin文件，其内容布局应该如下：

偏移 0x000: [可能的填充或向量表，BootROM不关心] 偏移 0x400: [512字节的Flash配置块 (FCB)，以‘FCFB’开头] 偏移 0x600: ... (FCB后续部分及填充) 偏移 0x1000: [64字节的映像头，包含imageType, imageLoadAddress等] 偏移 0x1040: [应用程序代码和数据开始]

这个.bin文件就是我们要烧写到Flash0x00000000地址的完整映像。BootROM会从Flash的0x400读FCB，从0x1000读映像头。

3.4 方法一：使用blhost命令行工具烧录

blhost是NXP提供的命令行工具，功能强大，适合集成到脚本中。操作流程讲究一个顺序。

步骤1：进入串行ISP模式

将开发板上的拨码开关SW5设置为：1-ON, 2-OFF, 3-OFF。对照前面的表，这就是(1,1,0)，即串行ISP模式。
通过USB线连接板子的J7(OpenSDA USB) 到电脑。
给板上电或复位。此时BootROM正在等待上位机命令。

步骤2：使用blhost连接与擦除打开命令行终端，进入blhost.exe所在目录。

连接：首先尝试与BootROM建立连接。通常使用UART或USB-HID接口。对于EVK，USB-HID更方便。
```
blhost -u -- get-property 1
```
-u表示使用USB HID接口。get-property 1是获取芯片属性的一般命令，用于测试连接。如果成功，会返回芯片的版本信息。
填充Flash配置参数：在烧写用户映像之前，我们需要先通过BootROM，将Flash的配置信息写入到SRAM的特定位置，以便后续烧写操作使用。这个配置信息就是之前提到的“FlexSPI boot config option block”。
```
blhost -u -- fill-memory 0x20000014 4 0xc1503051 blhost -u -- fill-memory 0x20000018 4 0x00000000
```
这里的0xc1503051和0x00000000是两个32位的配置数据，它们共同描述了连接到FlexSPI Port B的Octal Flash的特定参数（如设备类型为Macronix Octal DDR，频率等）。这些值需要根据你实际使用的Flash型号从SDK或参考手册中查找。EVK板上的MX25UM51345使用这个值。
擦除Flash：擦除Flash中将要存放映像的区域。
```
blhost -u -- flash-erase-region 0x0 0x20000
```
这个命令擦除从Flash地址0x0开始的0x20000（128KB）区域。擦除大小应略大于你的.bin文件。

步骤3：烧写引导映像将之前生成的gpio_led_output.bin文件烧写到Flash的起始地址。

blhost -u -- write-memory 0x0 gpio_led_output.bin

这个命令会将.bin文件的内容写入到Flash从0x0开始的位置。BootROM会自动识别其中的FCB（在0x400）和引导映像（从0x1000开始）。

步骤4：切换至FlexSPI启动模式并验证

断开板子USB连接（重要，确保完全断电）。
将拨码开关SW5设置为：1-ON, 2-OFF, 3-ON。对照表，这是(0,1,0)，即从FlexSPI Port B启动。
重新连接USB或使用电源适配器给板上电，然后按一下复位键。
如果一切配置正确，你应该能看到板载的LED开始按照程序设定的节奏闪烁，这标志着从Octal Flash启动成功！

3.5 方法二：使用NXP MCUBootUtility图形化工具烧录

对于不熟悉命令行的开发者，MCUBootUtility是福音。它把上述命令行的步骤封装成了一个直观的图形界面。

步骤1：准备映像文件使用IAR生成gpio_led_output.srec或gpio_led_output.hex文件。.srec是Motorola S-Record格式，也是一种常见的烧录格式。在IAR输出转换器中配置即可。

步骤2：连接并配置工具

确保板子仍在串行ISP模式（SW5: 1-ON,2-OFF,3-OFF）。
打开MCUBootUtility。
MCU Device选择i.MXRT6xx。
Boot Device选择FLEXSPI NOR。
点击Boot Device Configuration按钮，在弹出的窗口中，你需要根据板载Flash型号选择正确的配置。对于EVK-MIMXRT685，通常选择MXIC Octal DDR相关的配置。确认后关闭。
点击Connect to ROM。如果连接成功，下方日志窗口会显示设备信息，并且Device Status会更新。

步骤3：一键烧录

在Image File区域，点击浏览按钮，选择你生成的gpio_led_output.srec文件。
最激动人心的步骤：直接点击All-In-One Action按钮。这个按钮会智能地执行一系列操作：擦除必要的Flash区域、编程FCB、烧写应用程序映像、必要时还会进行验证。
等待进度条完成，日志显示成功。

步骤4：验证启动

同样，断开USB供电。
将拨码开关SW5切换至FlexSPI Port B启动模式(1-ON,2-OFF,3-ON)。
重新上电并复位。观察LED是否正常运行。

避坑指南：使用MCUBootUtility时，最常见的失败原因是Boot Device Configuration选错。务必根据板载Flash的具体型号和连接方式（Port A/Port B）选择正确的配置模板。如果模板不完全匹配，你可能需要手动编辑FCB的详细参数，这需要查阅Flash的数据手册和RT600的参考手册。

4. 常见问题排查与深度优化建议

即使按照步骤操作，也可能会遇到问题。下面是我在多次实践中总结的常见故障点及排查思路。

4.1 启动失败的诊断流程

如果板子没有任何反应（LED不亮，调试器连不上），可以按以下顺序排查：

确认电源和复位：最基础的往往最容易忽略。用万用表测量核心电压是否稳定。确保复位引脚在上电后处于高电平。
确认启动模式：反复检查SW5拨码开关的状态。用肉眼确认并最好用万用表测量PIO1_15/16/17三个引脚的电平，确保与期望的启动模式完全一致。开关接触不良是常见问题。
确认映像是否成功烧录：
- 将板子切回ISP模式，使用blhost的read-memory命令读取Flash内容。
```
blhost -u -- read-memory 0x400 0x10
```
查看0x400地址读出的数据，前4字节应该是46 43 46 42（即FCFB的十六进制）。再读取0x1000地址，看是否有非全FF或全00的数据（即有效的映像头）。
- 使用MCUBootUtility的Read Memory功能，可视化地检查Flash内容。
确认FCB和映像头内容：如果烧录了但数据不对，问题可能出在生成环节。
- 用二进制查看工具（如hexdump或HxD）打开你生成的.bin文件，检查偏移0x400和0x1000处的内容是否符合预期。
- 检查BOOT_HEADER_ENABLE宏是否正确定义。
- 检查链接脚本是否适用于XIP配置。
使用调试器进行最后救援：如果上述都正常，但依然不启动，可以尝试通过调试器（如J-Link）连接芯片，在复位后暂停CPU，查看PC指针。如果BootROM正常工作，PC应该指向ROM地址区域（如0x0300xxxx）。如果PC停在0xFFFFFFFE等异常地址，可能意味着BootROM在早期就出错了，重点检查电源、时钟和启动引脚。

4.2 FCB配置不匹配导致的疑难杂症

FCB配置错误不会总是导致完全无法启动，但会引起一些诡异现象：

现象：程序似乎启动了（比如调试器能连接），但运行不久就HardFault，或者XIP模式下代码执行异常。
根因：FCB中配置的Flash访问参数（如时钟频率freq、读命令序列readSampleClkSrc、dummyCycles等）与实际Flash型号不匹配。特别是dummyCycles（空周期），如果设置过小，FlexSPI控制器会在Flash数据还没稳定就读走，导致读到错误代码或数据。
解决方案：
1. 找到你所使用Flash型号的官方数据手册。
2. 查阅其“高速读”（Fast Read）或“Octal DDR读”命令的时序图，确定在目标频率下所需的dummy cycles数量。
3. 在SDK中，FCB通常由flexspi_nor_config.c或类似的配置文件生成。修改其中的memConfig.readCommand相关的dummyCycles字段。
4. 重新编译工程，生成新的.bin文件并烧录测试。

4.3 从调试（SRAM运行）到发布（Flash XIP）的平滑过渡

在项目早期，我们习惯在SRAM中调试程序，因为下载速度快。但最终产品需要从Flash XIP启动。如何无缝切换？

链接地址切换：SRAM调试时，链接地址是0x00080000（内部SRAM）。XIP时，链接地址是0x08001000（FlexSPI映射地址）。这需要在IDE中切换不同的链接脚本或目标配置（如flash_debug）。
初始化代码差异：SRAM中运行不需要初始化Flash。但XIP时，在main()函数执行前，启动代码（startup_*.s和system_*.c）必须包含初始化FlexSPI控制器的代码，这部分代码通常由BOOT_HEADER_ENABLE宏控制生成。确保你的XIP配置启用了它。
调试器配置：当从Flash XIP调试时，需要告诉调试器：
- 加载地址：仍然是.out或.elf文件，调试器会智能地只加载符号信息。
- 复位后的PC指针：芯片复位后，BootROM会完成Flash初始化并跳转到0x08001000。调试器需要知道这一点，以便在复位后正确设置断点。在IAR或Keil的调试器设置中，通常需要取消“在复位后运行到main”的选项，或者手动设置初始PC值。
性能考量：XIP模式下的代码执行速度受Flash本身速度和FlexSPI时钟限制。对于性能敏感的函数，可以考虑将其拷贝到SRAM中执行。这可以通过链接器特性（如IAR的#pragma location或GCC的__attribute__((section(".ram_code")))）实现，并在启动代码中增加相应的数据拷贝操作。

4.4 量产阶段的考量

当产品进入量产阶段，启动配置需要更加稳固和高效。

启用OTP锁定启动源：在确认使用FlexSPI Port B启动无误后，可以考虑烧写OTP中的PRIMARY_BOOT_SRC字段，将其永久设置为FlexSPI启动。这样即使板上的启动拨码开关被意外改动，芯片也会强制从Flash启动，提高了产品的抗干扰能力。注意：OTP烧写是不可逆的！
使用Auto-probe简化流程：对于固定Flash型号的大批量生产，可以烧写FLEXSPI_AUTO_PROBE_EN等OTP位。这样Flash中就不再需要存储FCB块，可以节省512字节，并略微加快BootROM的初始化速度。但务必在多种温度和电压下充分测试Auto-probe的可靠性。
生成单一烧录文件：量产烧录时，应该使用一个包含了FCB（如果需要）、应用程序、甚至可能包含校准数据、序列号等所有信息的单一二进制文件。使用elftosb工具可以灵活地生成这种复杂的、带有多段数据的“超级映像”。
安全启动：如果产品涉及知识产权保护或防止固件篡改，需要研究i.MX RT600的HAB（High-Assurance Boot）功能。这涉及到对引导映像进行加密和签名，BootROM在启动时会进行严格的验证。这部分配置非常复杂，需要提前规划。

配置i.MX RT600从串行NOR Flash启动，是一个融合了硬件知识、启动原理和工具链使用的过程。最关键的体会是理解BootROM的“期望”——它期望在固定的地址找到特定格式的数据（FCB和映像头）。我们的所有工作，无论是工程配置、编译链接还是烧录工具，都是为了满足这个期望。从最初的ISP模式烧录，到最终切换开关验证启动，每一步都环环相扣。建议在项目初期就建立好一套可靠的编译-烧录-验证流程，并善用blhost读内存的功能来验证Flash中的内容，这能节省大量调试时间。当LED第一次按照你的程序从Flash中点亮时，这种对硬件底层掌控的感觉，正是嵌入式开发的乐趣所在。

查看全文

http://www.cnnetsun.cn/news/2832333.html