i.MX RT600恢复启动功能实现：从原理到实践的嵌入式系统自愈方案

1. 项目概述：为i.MX RT600构建一道“安全门”

在嵌入式产品的生命周期里，最让人头疼的场景之一，莫过于设备在现场因为一次失败的固件升级，或者存储介质意外损坏，直接“变砖”无法启动。对于工业网关、智能仪表这类需要7x24小时稳定运行，且维护成本高昂的设备来说，这几乎是灾难性的。我经历过不止一次，因为一个字节的闪存写入错误，导致整批设备需要返厂用昂贵的编程器重新烧录，费时费力还影响口碑。

后来接触到恩智浦的i.MX RT系列跨界处理器，其内置ROM引导加载程序（BootROM）支持的“恢复启动”（Recovery Boot）功能，让我眼前一亮。这相当于在系统的主入口旁边，悄悄开了一道“安全门”。当主启动路径（比如常规的QSPI闪存）因为映像损坏而无法通行时，系统不会死锁，而是自动转向这道安全门——从一个指定的、独立的SPI NOR闪存中，加载一个预先准备好的、绝对可靠的恢复程序。这个恢复程序可以很简单，比如只是点亮一个状态灯并打开串口等待指令；也可以很复杂，比如自动从网络或USB重新下载一个完好的主程序映像并烧写回去。这个机制的核心价值，在于为产品赋予了“自愈”的潜力，极大地提升了系统的鲁棒性和可维护性。

本文将以i.MX RT600为例，手把手带你完成一次完整的恢复启动功能实现。我们将聚焦于最经典也最实用的场景：将一颗普通的四线SPI NOR闪存配置为恢复启动介质。我会详细拆解其背后的硬件连接原理、BootROM的启动决策逻辑、关键的OTP熔丝配置，并分别使用命令行工具blhost和图形化工具MCUBootUtility，完成从恢复映像生成、编程到最终验证的全流程。无论你是正在评估i.MX RT600的架构师，还是正在调试启动问题的工程师，这篇文章都能为你提供一份可直接落地的参考。

2. i.MX RT600启动流程深度解析

理解恢复启动，必须首先吃透i.MX RT600的标准启动流程。这颗处理器没有片内非易失性存储器（Flash），因此它的“开机第一指令”完全依赖于外部世界。这套机制设计得非常灵活，但也因此带来了配置上的复杂性。

2.1 BootROM：系统的“固件管家”

你可以把BootROM想象成固化在芯片硅片里的一段永不丢失的“出厂程序”。每次芯片上电或复位，CPU第一个执行的就是它。它的核心职责是“找到并加载真正的用户程序”。由于没有内部Flash，用户程序（我们称之为“映像”）必须存放在外部，比如QSPI NOR闪存、SD卡、甚至是串口对端的主机里。

BootROM支持两种主要的启动方式：

1. XiP（就地执行）：直接从外部QSPI闪存中读取指令并执行。优点是启动速度快，无需搬运大量代码；缺点是对闪存性能（读速度）要求高，且无法加密执行（除非闪存本身支持）。
2. 加载到SRAM执行：将外部存储器（如SD卡、SPI NOR）中的映像完整地拷贝到内部SRAM中，然后跳转到SRAM执行。这种方式性能最优（SRAM速度极快），且便于进行完整性校验和解密，但受限于SRAM容量（i.MX RT600有4.5MB）。

BootROM如何决定使用哪种方式、从哪里启动呢？这依赖于一套优先级分明的决策树，其关键输入是OTP熔丝和几个物理引脚的状态。

2.2 启动源决策：OTP熔丝与ISP引脚的博弈

这是整个启动逻辑中最精妙也最容易出错的部分。i.MX RT600上电后，BootROM会按以下顺序决策：

第一步：检查OTP BOOT_CFG[0]字中的PRIMARY_BOOT_SRC字段（位[3:0]）。 OTP（One-Time Programmable）是一次性可编程熔丝，烧写后不可更改，用于存储最终产品的固定配置。

• 如果PRIMARY_BOOT_SRC已被编程为一个非零的有效值（例如0b1011代表从FlexSPI端口B启动），那么BootROM将无视所有ISP引脚的状态，直接尝试从该OTP指定的介质启动。这是产品量产时的标准配置。
• 如果PRIMARY_BOOT_SRC未被编程（保持为0b0000），那么BootROM进入“开发调试模式”，转而进行第二步。

第二步：读取ISP[2:0]引脚（PIO1_17, PIO1_16, PIO1_15）的电平状态。 这三个引脚在上电复位时的电平，直接映射到一张启动模式表中。开发板通常通过跳线（如DIP开关）来设置这些引脚。

实操心得：模式选择跳线在MIMXRT685-EVK评估板上，这对应着开关SW5。例如，将SW5设置为1-OFF, 2-ON, 3-ON（即低，高，高），就选择了FlexSPI端口A启动。而设置为1-ON, 2-ON, 3-OFF（即高，高，低），则进入了至关重要的串行ISP模式，这是我们后续使用blhost或MCUBootUtility与BootROM通信、编程闪存的前提。务必在板卡原理图上确认好这几个引脚对应的开关。

第三步：尝试启动与故障转移。BootROM根据确定的启动源，去对应的存储介质（如QSPI Flash）的固定偏移地址（通常是0x1000）查找有效的映像文件头。如果找到并验证通过，则加载/执行。如果找不到或验证失败，则启动流程并不会立刻结束，而是会触发“恢复启动”检查（如果已配置），或者进入ISP模式等待主机连接。

2.3 映像文件头：BootROM的“交接清单”

BootROM在存储介质上并非盲目地读取数据，它首先寻找的是一个格式严格的“文件头”（Image Header），这个头就像是用户程序递给BootROM的“交接清单”。头的前64个字节包含了关键信息：

注意事项：imageLoadAddress的坑这个地址必须4KB对齐。更重要的是，它指向的位置必须存放着另一个完全相同的映像头。这是一种双重校验机制：BootROM先读介质上的头（第一重），然后根据imageLoadAddress去SRAM里找第二个头（第二重），比对关键字段。因此，在链接脚本里，你的程序起始段必须就是这个头结构体。很多启动失败的问题，根源就在于链接地址没设对，或者启动文件里没有正确初始化这个头结构。

3. 恢复启动模式的原理与硬件设计

理解了主启动流程，恢复启动就很好理解了。它本质上是主启动流程的一个“备份路径”。当主路径失效时，系统自动切换到这个备份路径。

3.1 恢复启动的触发条件与流程

恢复启动的触发，是BootROM内部逻辑自动完成的，无需用户程序干预。其完整流程如下图所示（概念流程）：

1. 上电/复位：BootROM开始执行。
2. 检查主启动源：根据OTP或ISP引脚，尝试从主启动设备（如主QSPI Flash）加载映像。
3. 主启动失败：如果主设备中没有找到有效映像，或者映像校验失败（CRC错误、签名无效等）。
4. 检查恢复启动使能：BootROM检查OTP中是否配置了恢复启动源（PRIMARY_BOOT_SRC字段的某些特定值隐含了恢复使能）。
5. 探测恢复设备：如果使能，BootROM会切换到指定的FlexComm SPI接口（例如SPI5），并使用一个较低的时钟（如24MHz），向连接的SPI NOR Flash发送0x9F（读ID）命令，探测器件是否存在。
6. 加载恢复映像：如果探测成功，BootROM会从该Flash的0x1000偏移地址处，读取恢复映像的头，并进行校验。
7. 执行或降级：
   • 如果恢复映像校验通过，则将其加载到SRAM并跳转执行。
   • 如果恢复映像也不存在或校验失败，则BootROM最终会降级进入串行ISP模式，等待主机通过UART/USB等接口连接，进行最后的“抢救”。

这个流程为系统提供了两级保障：主Flash -> 恢复Flash -> ISP模式。只要恢复Flash中的程序是好的，设备就至少能进入一个可控的状态。

3.2 硬件连接：为RT600添加“安全芯片”

i.MX RT600的恢复启动必须使用标准的SPI接口（1位或4位），而不能使用更快的Octal/ HyperBus接口。它支持FlexComm0~7中的任意一个SPI接口。在MIMXRT685-EVK上，默认没有焊接恢复用的SPI Flash，我们需要自己动手。

核心连接如下：

1. 选择SPI接口：例如选择FlexComm5 (SPI5)。对应的引脚是：
   • PIO1_3-> SPI5_SCK
   • PIO1_4-> SPI5_MISO
   • PIO1_5-> SPI5_MOSI
   • PIO1_6-> SPI5_SSEL
2. 连接SPI NOR Flash：你需要一颗3.3V供电的SPI NOR Flash（如Winbond W25Q16JV）。将它的CLK,DI(IO0),DO(IO1),CS#分别连接到上述四个引脚。
   • 特别注意：即使你使用QSPI模式（4线），在恢复启动的探测阶段，BootROM也只使用标准的1位SPI模式。因此，Flash的WP#和HOLD#引脚建议上拉，IO2和IO3在硬件上必须上拉到高电平（通过10K电阻接VCC），以确保器件在1位SPI模式下正常工作。
3. 电源与电平匹配：确保Flash的VCC接3.3V。检查评估板JP12跳线，需要连接2-3脚，将对应Bank的GPIO电压设置为3.3V，以匹配Flash的电平。

硬件设计避坑指南

• 引脚冲突：FlexComm接口是复用的，确保你选择的SPI引脚没有被板上的其他外设（如以太网、音频编解码器）占用。
• 布线长度：SPI时钟频率在恢复模式虽然不高（24MHz），但仍建议SCK、CS、数据线走线等长，减少信号完整性问题。
• 上拉电阻：CS#、WP#、HOLD#以及未用的IO2/IO3的上拉电阻（4.7K~10K）必不可少，这是很多“探测不到Flash”问题的根源。

3.3 OTP熔丝配置：锁定启动路径

OTP配置是恢复启动功能的“开关”和“路标”。相关熔丝主要位于BOOT_CFG[0]这个OTP字（地址0x60）中。

1. PRIMARY_BOOT_SRC (位[3:0])：这个字段不仅指定了主启动源，某些值还隐含了恢复启动的使能和源。

关键点：当PRIMARY_BOOT_SRC设置为0b1011或0b1100时，意味着“主启动从FlexSPI Flash，如果失败，则尝试从恢复SPI Flash启动”。

2. REDUNDANT_SPI_PORT (位[19:17])：当恢复启动使能时，这个3位字段指定具体使用哪个FlexComm SPI接口。

• 3'b000: FC0 (SPI0)
• 3'b001: FC1 (SPI1)
• ...
• 3'b101:FC5 (SPI5)<- 我们示例的选择
• 3'b110: FC6 (SPI6)
• 3'b111: FC7 (SPI7)

3. DEFAULT_ISP_MODE (位[6:4])：这个字段定义了当所有启动尝试都失败后，进入ISP模式时，默认使用哪个串行接口（UART/SPI/I2C/USB）。这算是最后一道保险。

警告：OTP烧写是一次性的OTP字一旦从0编程为1，就无法再改回0。在开发阶段，强烈建议通过ISP引脚来选择启动模式，而不是烧写OTP。只有在产品定型、量产前，才进行OTP的烧写。烧写OTP有风险，务必先确认配置值无误。

4. 恢复映像的创建与链接配置

恢复映像本身就是一个普通的应用程序，但它有一些特殊要求，主要体现在链接地址上。

4.1 链接地址规划：避开SRAM的“系统区”

i.MX RT600内部有4.5MB的SRAM，但这片内存并非全部可供应用程序自由使用。BootROM、DSP内核等会占用一部分。对于恢复映像，我们必须确保它被加载到一个“安全”且“空闲”的区域。

• 必须是非XIP映像：恢复映像必须被加载到SRAM中运行，因此imageType不能是XIP类型（如0x0004）。
• 加载地址：参考官方建议，SRAM的前512KB（0x0000_0000~0x0007_FFFF）最好避开。一个常用且安全的起始地址是0x0008_0000。
• 映像头地址：如前所述，imageLoadAddress指向的SRAM地址处必须存有映像头。因此，在链接脚本（如MIMXRT685Sxxxxx_cm33.icffor IAR）中，需要将包含映像头（通常是Reset_Handler所在的启动代码段）的初始段放在这个地址。

IAR链接脚本关键修改示例：

define symbol m_text_start = 0x00080000; /* 恢复映像起始地址 */ define symbol m_text_size = 0x00080000; /* 为恢复程序分配512KB空间 */ define region TEXT_region = mem:[from m_text_start to m_text_start+m_text_size-1]; place at address mem:0x00080000 { readonly section .intvec }; /* 中断向量表（包含映像头）放在开头 */ place in TEXT_region { readonly };

MCUXpresso IDE (GCC) 链接脚本关键修改示例：需要修改MIMXRT685Sxxxxx_cm33.ld文件，调整m_text段的起始地址和长度。

4.2 修改启动文件：填写正确的映像长度

BootROM需要知道映像的确切长度以进行CRC校验。这个长度值imageLength需要我们在编译时计算，并填写到启动汇编文件中的特定位置。

在IAR的startup_MIMXRT685S_cm33.s文件中，你会找到类似下面的代码段：

.section .boot_hdr, “a” .word 0x5A5A5A5A /* 前4个字通常是保留或特定标识 */ .word 0x5A5A5A5A .word 0x5A5A5A5A .word 0x5A5A5A5A .word __image_size /* 这个符号链接器会计算，对应imageLength */ .word 0x00020000 /* imageType: 0x0002 表示明文CRC映像 */ .word __crc32 /* 链接器计算的CRC32值，对应crcChecksum */ ... .word 0x00080000 /* imageLoadAddress: 必须与链接地址一致 */

你需要确保：

1. __image_size和__crc32这些符号在链接脚本中正确定义，并由链接器自动填充。
2. imageLoadAddress的值（示例中的0x00080000）与你的链接脚本起始地址完全一致。
3. imageType字段符合你的需求（0x0002用于带CRC的恢复映像是稳妥的选择）。

实操心得：如何获取正确的imageLength最可靠的方法不是手动计算，而是让工具链帮你完成。在IAR中，你可以在项目选项的Linker -> Advanced -> Enable image length calculation中勾选相关选项，并确保在汇编文件中引用了正确的符号。编译后，通过查看生成的.map文件，确认__image_size符号的值是否合理（应接近你的.bin文件大小）。一个常见的错误是imageLength填得太大，导致CRC校验范围超出实际映像，计算出的CRC值与头中存储的不匹配，从而启动失败。

5. 使用Blhost命令行工具进行编程与验证

blhost是恩智浦提供的命令行工具，它直接与芯片的BootROM通信，功能强大且适合自动化脚本。我们用它来完成恢复映像的编程和OTP配置。

5.1 环境准备与连接

1. 获取工具：从恩智浦官网下载并安装MCUXpresso Secure Provisioning Tool或SDK，其中包含blhost。确保版本在v2.3以上。
2. 硬件设置：
   • 将评估板SW5开关设置为1-ON, 2-ON, 3-OFF（即高，高，低），使芯片进入串行ISP模式。
   • 通过USB线连接评估板的J7 (USB HS)端口到电脑。
3. 编译恢复映像：使用前一章的方法，修改链接脚本和启动文件，编译一个简单的测试程序（如LED闪烁），并生成.bin文件（例如recovery_led.bin）。

5.2 编程恢复Flash：关键命令详解

打开命令行，进入blhost所在目录。以下命令序列需要按顺序执行：

# 1. 枚举并连接到设备。通常使用USB HID接口。 blhost -u -- get-property 1 # 如果连接成功，会返回芯片的版本信息。 # 2. 配置Flash参数。这是最关键的一步，告诉BootROM要操作的SPI Flash信息。 # 命令：fill-memory <地址> <长度> <数据> # 地址 0xc0500000 是BootROM内部用于传递配置块的特殊内存地址。 # 数据是一个32位的配置字，其格式必须严格按照表4来构造。 blhost -u -- fill-memory 0xc0500000 4 0xC0500005 # 让我们拆解这个魔数 0xC0500005： # - 0xC: 标签，固定。 # - 0x0: 保留位。 # - 0x5: SPI索引。0x5 代表使用 FlexComm5 (SPI5)。 # - 0x0: 保留位。 # - 0x0: 存储器类型。0x0 代表“手动NOR闪存”，即使用我们提供的参数，而非SFDP自动读取。 # - 0x0: 内存大小。0x0 代表 512KB * 2^0 = 512KB。如果你的Flash是1MB，这里应填0x1。 # - 0x0: 扇区大小。0x0 代表 4KB * 2^0 = 4KB。这是大多数SPI NOR Flash的擦除扇区大小。 # - 0x5: 页面大小。0x5 ？等等，这里有个坑！根据文档，3<=n<=5时，size = 32 Bytes * 2^(n-3)。 # n=5, 则 size = 32 * 2^(2) = 128 Bytes。但常见的Flash页编程大小是256字节。 # 实际上，对于W25Q系列，页大小是256字节，对应n=2 (256=256*2^0)。所以这里应该用0x2。 # 因此，更准确的配置值可能是 0xC0500002。 # **重要**：这个配置值必须与你的实际Flash型号匹配！最好查阅Flash数据手册。 # 3. 擦除Flash。将恢复映像所在的区域擦除。 # 假设我们从偏移0x1000开始存放，擦除0x1000字节（4KB扇区）通常足够。 blhost -u -- flash-erase-region 0x1000 0x1000 5 # 参数：起始地址，长度，Flash索引（5代表SPI5）。 # 4. 写入恢复映像。 blhost -u -- write-memory 0x1000 recovery_led.bin 5 # 参数：Flash中的起始地址，本地.bin文件路径，Flash索引。 # 5. (可选) 读取验证。 blhost -u -- read-memory 0x1000 0x400 read_back.bin 5 # 读取刚写入的1KB数据，与原始文件对比。

踩坑实录：fill-memory配置值这是我踩过最深的坑。官方文档表格里的“页面大小”描述容易让人误解。对于最常见的256字节页编程的SPI NOR Flash（如W25Q16/32/64/128），页面大小字段应设置为0x2。如果你设置为0x5，BootROM会以128字节的页去操作Flash，导致编程错位，最终CRC校验失败。最佳实践是：先用一个已知正确的配置（例如MCUBootUtility生成的）通过blhost读出来，再依葫芦画瓢。

5.3 配置OTP并验证恢复启动

恢复映像烧写成功后，我们需要配置OTP，让BootROM知道“主启动失败时，请去找SPI5”。

# 6. 烧写OTP，配置PRIMARY_BOOT_SRC。 # 命令：efuse-program-once <地址> <值> # 地址 0x60 对应 BOOT_CFG[0] OTP字。 # 我们想设置主启动为 FlexSPI0 Port B，并启用恢复启动（SPI5）。 # PRIMARY_BOOT_SRC = 0b1011 (0xB) # REDUNDANT_SPI_PORT = 0b101 (0x5) 对应SPI5，位于位[19:17]。 # 因此，我们需要向0x60地址写入的值是：0x005B0000。 # (REDUNDANT_SPI_PORT=5 << 17) | (PRIMARY_BOOT_SRC=0xB) # 计算: (0x5 << 17) = 0x000A0000 # 0x000A0000 | 0xB = 0x000A000B? 不对，PRIMARY_BOOT_SRC在低4位。 # 正确值应为: 0x000A000B # 但注意：OTP是按位编程，只能将0变为1。初始值为0，我们可以直接写入最终值。 blhost -u -- efuse-program-once 0x60 0x000A000B # 7. 验证OTP。 blhost -u -- efuse-read-once 0x60 # 返回的值应该是你写入的值。

最终验证：

1. 将SW5开关设置回主启动模式（例如低，高，低对应FlexSPI Port B）。
2. 确保你的主Flash（FlexSPI Port B连接的那个）里没有有效的启动映像（可以临时擦除）。
3. 复位或重新上电评估板。
4. 观察现象：如果一切顺利，BootROM在主Flash找不到有效映像，会触发恢复启动流程，从SPI5 Flash加载你刚刚烧写的LED闪烁程序，并开始运行。你就能看到LED开始闪烁，证明恢复启动成功！

6. 使用NXP-MCUBootUtility图形化工具进行编程

对于不熟悉命令行的开发者，NXP-MCUBootUtility图形化工具是更友好的选择。它封装了底层命令，提供了直观的配置界面。

6.1 工具配置与连接

1. 启动工具并选择芯片：打开MCUBootUtility，在MCU下拉框中选择i.MXRT6xx。
2. 选择Boot Device：在Boot Device中选择FLEXCOMM SPI NOR。这会告诉工具我们将通过一个FlexComm SPI接口来操作Flash。
3. 配置SPI参数：点击Boot Device Configuration按钮，在弹出的对话框中：
   • Spi Instance: 选择5（对应SPI5）。
   • Memory Type: 选择Manual。
   • 根据你的Flash型号，填写Size、Sector Size、Page Size。例如对于W25Q32JV (4MB)，可以填0x400000，0x1000，0x100。
4. 连接板卡：确保评估板处于串行ISP模式（SW5:1-ON, 2-ON, 3-OFF），并连接USB。点击Connect按钮。如果成功，下方状态栏会显示芯片信息。

6.2 一键烧写与OTP配置

1. 加载映像文件：在Image File区域，点击浏览，选择你编译生成的.srec或.bin文件。对于恢复映像，建议使用.srec格式，因为它包含地址信息。
2. 执行All-in-One Action：点击All-in-One Action按钮。工具会自动执行以下操作：
   • 擦除Flash相应区域。
   • 编程Flash。
   • 验证编程内容。
   • 计算并填充映像头中的CRC值（这是比手动使用blhost更方便的一点）。
3. 配置OTP：在工具界面上方找到Fuse或OTP相关标签页。
   • 找到BOOT_CFG0字段。
   • 在PRIMARY_BOOT_SRC下拉框中，选择FLEX_SPI_REC_BOOT_PORTB (0xB)。
   • 在REDUNDANT_SPI_PORT下拉框中，选择FC5 (0x5)。
   • 点击Program按钮烧写OTP。烧写前请再三确认！
4. 验证：与blhost验证步骤相同，切换回主启动模式，确保主Flash无有效映像，复位后观察恢复程序是否运行。

图形化工具的优势与局限MCUBootUtility极大简化了操作，特别是自动处理CRC和映像头，避免了手动计算的错误。它的Fuse配置界面也非常直观。但是，它有时对非标Flash的支持不如命令行灵活，且操作日志不如命令行直观。在量产或自动化脚本中，blhost仍然是不可替代的。建议两者结合使用，用图形化工具验证流程和参数，再用blhost编写生产脚本。

7. 调试技巧与常见问题排查

即使按照步骤操作，恢复启动也可能失败。以下是几个常见的“症状”和排查思路。

7.1 问题：BootROM完全无法进入ISP模式（blhost连接失败）

• 可能原因1：ISP引脚设置错误。
  • 排查：用万用表测量PIO1_15, PIO1_16, PIO1_17三个引脚在上电瞬间的电平，确保与SW5设置一致。注意开关的ON/OFF与电平高低的对应关系（查看板卡手册）。
• 可能原因2：USB端口或驱动问题。
  • 排查：尝试不同的USB口，检查设备管理器中是否有未识别的设备或USB HID设备。RT600在ISP模式下通过USB HID类与主机通信。
• 可能原因3：板卡未正确复位。
  • 排查：在点击blhost连接命令的瞬间，手动按下板卡的复位键。有时BootROM的ISP窗口期很短。

7.2 问题：恢复Flash编程成功，但恢复启动不执行（直接进了ISP模式）

• 可能原因1：主Flash中存在有效映像。
  • 排查：BootROM的流程是先尝试主启动，失败后才尝试恢复启动。如果你主Flash里有一个能正常启动的旧程序，BootROM会直接执行它，根本不会走到恢复流程。验证时务必擦除或破坏主Flash的映像头。
• 可能原因2：OTP配置错误。
  • 排查：使用blhost -u -- efuse-read-once 0x60命令，读出OTP值。确认PRIMARY_BOOT_SRC是0xB或0xC，并且REDUNDANT_SPI_PORT字段正确指向了你连接的SPI接口（如0x5）。注意OTP位是“与”的关系，错误的位被编程为1可能导致意外行为。
• 可能原因3：恢复映像链接地址或映像头错误。
  • 排查：这是最常见的原因。使用仿真器（如J-Link）连接芯片，在BootROM初始化后、跳转前设置断点，或者通过串口打印BootROM的调试信息（如果使能了）。检查BootROM从恢复Flash读取的数据。重点核对imageLoadAddress和imageType。确保你的.bin文件开头64字节是符合格式的映像头。
  • 技巧：可以用blhost的read-memory命令把Flash里0x1000开始的数据读出来，用二进制编辑器查看，并与你生成的.bin文件开头对比。

7.3 问题：BootROM能探测到恢复Flash，但CRC校验失败

• 可能原因1：fill-memory命令中的Flash参数（页大小、扇区大小）设置错误。
  • 排查：这是重中之重。错误的页大小会导致BootROM以错误的边界读写Flash，使得读出的数据和编程进去的数据对不上，CRC自然失败。仔细对照Flash数据手册，确认Page Program大小（通常是256字节）和Sector Erase大小（通常是4KB）。MCUBootUtility的预设型号库通常更准确。
• 可能原因2：Flash硬件连接问题。
  • 排查：检查WP#和HOLD#引脚是否已上拉。检查IO2和IO3在硬件上是否上拉到高电平（对于QSPI Flash用作标准SPI时必需）。用示波器测量SPI的CLK、CS、MOSI信号，看BootROM在探测阶段（上电后不久）是否有波形发出。

7.4 问题：恢复程序运行不稳定或死机

• 可能原因1：恢复程序本身有bug。
  • 排查：恢复程序只是一个普通程序。首先确保这个程序在主启动方式下（即直接烧写到主Flash并从那里启动）能稳定运行。排除程序本身的逻辑错误、栈溢出、时钟配置错误等问题。
• 可能原因2：中断向量表重映射问题。
  • 排查：程序在SRAM中运行，中断向量表必须是可写的，且地址可能需要在运行时重映射。检查你的系统初始化代码，是否正确地设置了VTOR寄存器指向SRAM中的向量表。

最后的救命稻草：串口日志在开发恢复程序时，第一件事就是初始化一个串口并打印日志。哪怕只是打印“Recovery Boot Entered!”这样一句话，也能让你立刻知道BootROM已经成功跳转到了你的恢复程序，极大缩小问题范围。将日志输出到某个固定的UART引脚，用USB转串口工具连接电脑查看。