1. 项目概述在i.MX RT500/600上实现可靠的固件双备份启动最近在做一个基于恩智浦i.MX RT595芯片的工业控制器项目客户对产品的可靠性提出了硬性要求固件升级过程中万一断电设备不能“变砖”必须能自动回滚到上一个可用的版本。这让我把目光投向了i.MX RT系列MCU内置的“双程序可交替启动”特性。虽然之前在i.MX RT1170上实现过类似功能但这次用的RT500/600系列在细节上有些“小脾气”尤其是它提供了一种不依赖复杂加密签名、仅通过CRC32校验来确保固件完整性的“平民化”方案这对于成本敏感且对启动速度有要求的场景特别友好。折腾了几天把RT500/600上这个特性的里里外外都摸了一遍特别是那个CRC32校验的使能和验证过程有不少官方文档没细说的坑。今天就把从设计思路到实操踩坑的全过程整理出来如果你也在用RT500/600做高可靠性的产品这篇笔记应该能帮你省下不少调试时间。简单来说这个特性允许你在同一片串行NOR Flash里存储两个完整的应用程序镜像Image 0和Image 1。芯片的BootROM在上电时会根据一套既定的策略主要看镜像版本号和完整性自动选择其中一个完好的、版本更高的镜像来启动。如果主镜像损坏它能自动 fallback 到备份镜像从而实现固件的故障恢复和安心的空中升级。整个机制的核心逻辑和i.MX RT1170大同小异但就像不同品牌的手机系统底层功能类似设置菜单和操作细节却各有不同。下面我们就聚焦这些“不同”并重点攻克如何利用CRC32校验来为你的固件加上一道简单的“防盗门”。2. 核心逻辑解析与i.MX RT1170的差异点全拆解在开始动手前必须先把RT500/600和RT1170在双启动机制上的差异点搞清楚。直接照搬RT1170的经验可能会让你在调试时一头雾水。这些差异主要集中在镜像结构、配置位置和状态管理逻辑上。2.1 镜像结构从繁到简告别IVT与BD这是第一个直观的不同点。在i.MX RT1170上一个能被BootROM识别的、最简化的可启动镜像XIP结构包含好几个部分FlexSPI的配置块、镜像版本头、中断向量表、启动数据块最后才是应用程序本身。你可以把它想象成一个搬家包裹外面有好几层包装和清单。而在i.MX RT500/600上事情变得简单多了。一个基本的可启动镜像只需要三部分FDCB必须放在Flash偏移0x0位置。这是FlexSPI外设的配置块告诉BootROM如何正确地初始化并访问这片Flash。没有它BootROM第一步就“懵”了。img_ver镜像版本头。必须放在Flash偏移0x600的位置。这是一个4字节的结构包含一个16位的版本号version和它的按位取反值inversion。BootROM通过检查version ^ inversion是否等于0xFFFF来判断这个版本头是否有效当然RT500/600还有特殊规则后面会讲。Application应用程序本体。对于XIP就地执行镜像其链接地址即中断向量表起始地址必须固定在0x08001000。注意0x08000000是FlexSPI0的AHB映射起始地址所以应用程序在Flash中的实际存储偏移是0x1000。注意RT1170的AHB映射地址通常是0x30000000而RT500/600是0x08000000。这个系统级差异直接影响你的链接脚本和调试器配置千万别搞混。原先RT1170里必需的IVT和BD在这里被省去了。BootROM默认从img_ver之后的位置寻找应用程序的中断向量表。这种简化带来的好处是镜像头更小但同时也意味着一些高级配置如非XIP镜像的加载地址需要通过其他方式如CRC参数区或固定规则来约定。2.2 OTP配置搬家启动参数的“房产证”位置变了启用双程序启动功能需要在一块叫做OTP的“一次可编程”存储区里写入配置信息。这相当于给BootROM颁发了一个“房产证”告诉它“Flash这片地我划成了两个区域这是它们的分界线。”在RT1170和RT500/600上这个“房产证”的格式字段定义是一样的主要包含两个关键信息FlexSPI Remap Size指定了第一个镜像Image 0的最大长度。BootROM会据此计算出Image 0的结束地址。Second Image Offset指定了第二个镜像Image 1在Flash中的起始偏移地址。但是“房产证”登记的地点OTP中的地址变了i.MX RT1170配置在0x9C0和0x9D0等地址。i.MX RT500/600配置在OTP BOOT_CFG2 (0x188)和BOOT_CFG3 (0x18C)。以我使用的MIMXRT595-EVK开发板为例通过恩智浦的MCUBootUtility工具将Second Image Offset设置为0x10这个值需要根据芯片参考手册中的公式计算通常0x10代表偏移为4MBFlexSPI Remap Size保持默认的0。这样BootROM就会认为Image 0 位于 Flash 偏移0x0至0x4000004MB之间。Image 1 位于 Flash 偏移0x400000开始的位置。实操心得在烧写OTP前务必用MCUBootUtility的“Read OTP”功能先读取并确认当前值。OTP位一旦从0烧写成1就无法再改回0错误的配置可能导致芯片无法正常启动。建议先在开发板上用仿真器调试模式充分测试镜像和双启动逻辑确认无误后再进行OTP烧写。2.3 状态寄存器的“升级”从2比特到32比特的豪华套餐双启动需要一个“记忆体”来记录上一次成功启动的是哪个镜像以便本次决定尝试启动另一个如果版本更高。RT1170很“节俭”地使用了系统复位控制器里的一个通用寄存器SRC_GPR10的其中2个比特位来记录。到了RT500/600它用上了SYSCTL0外设中的一个完整的32位非易失性寄存器地址SYSCTL0_BASE 0x384。这个寄存器被设计成一个结构体user_app_boot_invoke_option_t其功能远不止记录启动状态。它实际上融合了ROM API的调用选项包含以下字段boot_image_index记录上次启动的镜像索引0或1这就是我们双启动需要的状态位。boot_interface启动接口类型如FlexSPI, USB等。mode启动模式。tag一个魔术字用于验证该结构是否被有效写入。这意味着在RT500/600上BootROM和应用程序可以通过这个寄存器进行更丰富的“对话”。例如应用程序可以通过设置这个寄存器请求在下一次复位时以特定模式从特定接口启动。对于我们实现双启动而言我们主要关心boot_image_index这个字段BootROM会在启动流程中读取并更新它。2.4 版本号逻辑的微妙变化0xFFFFFFFF成了“天选之子”镜像版本号的判断逻辑是决定启动顺序的核心。两者都检查version和inversion是否互为取反。但RT500/600引入了一个特殊规则它将0xFFFFFFFF即version和inversion均为0xFFFF也视为一个有效的版本号并且将其定义为最低的版本。这个变化直接影响BootROM的决策树有效性判断RT500/600的BootROM只启动含有有效版本号的镜像。有效性定义为a)version ^ inversion 0xFFFF 或 b)version 0xFFFF inversion 0xFFFF。如果一个镜像的版本头无效它会被直接跳过。顺序判断在两个镜像都有效的前提下BootROM会比较版本值version注意是比较version字段不是整个32位值。值更大的被视为更高版本。关键点来了0xFFFF被定义为比任何其他数值如0x0001都小的版本。因此如果你希望Image 1作为主版本除了确保其CRC等完整性还必须将其version设置为一个大于Image 0version的值。我在MIMXRT595-EVK上做了全面测试验证了以下情况镜像0版本 (version, inversion)镜像1版本 (version, inversion)BootROM 启动选择原因分析(0x0001, 0xFFFE)(0x0002, 0xFFFD)镜像1镜像1版本号(0x0002) 镜像0版本号(0x0001)(0x0002, 0xFFFD)(0x0001, 0xFFFE)镜像0镜像0版本号(0x0002) 镜像1版本号(0x0001)(0xFFFF, 0xFFFF)(0x0001, 0xFFFE)镜像1镜像1版本(0x0001)有效且 镜像0版本(0xFFFF最低)(0x0000, 0x0000)(0x0001, 0xFFFE)镜像1镜像0版本头无效(0x0000^0x00000x0000)被跳过(0x0001, 0x1234)(0x0002, 0xFFFD)可能启动失败镜像0版本头无效(取反关系不成立)若镜像1也无效则无有效镜像这个逻辑比RT1170更严格。在RT1170上版本头似乎只用于比较顺序即使无效非取反可能仍会尝试启动如果别无选择。而在RT500/600上版本头有效性是启动的必要条件。这要求我们在生成镜像时必须确保img_ver结构被正确计算和写入。3. 平民化的安全卫士CRC32校验启动详解对于许多不需要高级安全加密但又需要确保固件在存储或传输过程中未被意外破坏的应用场景RT500/600提供的CRC32校验方案是一个极佳的选择。它比数字签名方案更简单计算开销更小启动速度更快。3.1 CRC32参数的三要素藏在中断向量表里的秘密BootROM进行CRC32校验需要三个关键参数从哪里开始算、算多长、正确的值应该是多少。这些参数并没有新增一个单独的结构体而是巧妙地“寄生”在应用程序自身的中断向量表的保留位置里。对于Cortex-M内核中断向量表的前64字节0x3C是标准定义之后的部分是保留的。BootROM就利用了这里的空间。具体位置如下偏移地址均相对于应用程序中断向量表的起始地址即链接地址imageLoadAddress偏移 0x20 (4字节) -imageLength需要计算CRC32的数据的总长度。这通常是你的应用程序代码数据的大小从中断向量表开始imageLoadAddress到程序结束。注意如果这个值为0BootROM会跳过CRC校验。偏移 0x28 (4字节) -crcChecksum正确的CRC32校验值。BootROM会自己计算一遍CRC然后与这个值比较。如果不同则认为镜像损坏。偏移 0x34 (4字节) -imageLoadAddressCRC计算的起始地址也是中断向量表的起始地址。对于XIP镜像这个地址就是固定的0x08001000假设Flash在FlexSPI0。对于Non-XIP镜像需从Flash加载到RAM执行这个地址是应用程序在RAM中的链接地址。CRC计算发生在镜像被加载到RAM之后校验的是RAM中的内容。重要提示BootROM在计算CRC时有两个自动行为1. 如果计算范围包含了crcChecksum自身所在的4字节它会自动跳过这部分避免“自指”导致的校验失败。2. 如果imageLength指定的长度不是4字节的整数倍它会自动在数据末尾补0直到对齐再进行计算。我们在手动计算CRC时必须模仿这个行为。3.2 如何开启CRC32校验一把钥匙开一把锁仅仅在指定位置填上参数还不够还需要一个“开关”来告诉BootROM“请对这个镜像进行CRC校验”。这个开关就是中断向量表偏移0x24处的一个字节imageType[7:0]。当这个字节的值被设置为0x02或0x05并且imageLength不为0时BootROM就会使能CRC32校验流程。0x02和0x05是BootROM定义的镜像类型标识通常0x02用于XIP镜像0x05用于Non-XIP镜像。你需要根据你的应用程序链接方式设置正确的imageType。3.3 BootROM使用的CRC32算法MPEG-2标准CRC有多个标准多项式不同结果天差地别。RT500/600的BootROM使用的是CRC-32/MPEG-2标准。其核心参数如下多项式0x04C11DB7初始值0xFFFFFFFF输入/输出反转无refIn false, refOut false结果异或值0x00000000BootROM内部利用了芯片的硬件CRC模块来计算该模块固定支持几种多项式MPEG-2是其中之一。我们在上位机手动计算CRC时必须使用完全相同的参数。很多CRC计算工具或库默认使用CRC-32即CRC-32/ISO-HDLC其输出会与0xFFFFFFFF异或如果选错标准算出来的值对不上BootROM就会报错。4. 实战演练从零构建带CRC32校验的双启动镜像理论铺垫完毕现在进入实战环节。我们以MIMXRT595-EVK板卡和SDK中的gpio_led_output例程为基础制作两个版本号不同、LED闪烁间隔不同的镜像并启用CRC32校验最终实现双程序交替启动。4.1 准备工作与环境搭建硬件MIMXRT595-EVK开发板。软件MCUXpresso IDE或IAR/Keil用于编译SDK示例工程。我使用的是IAR。恩智浦 MCU Boot Utility (v3.5.0或更高)这是关键工具用于生成启动头、填充CRC参数、烧写OTP和Flash。务必使用v3.5.0以上版本它才支持“Plain CRC Image”类型。芯片SDK确保已安装MIMXRT595的SDK如SDK_2.10.1_EVK-MIMXRT595。目标创建两个镜像。Image 0LED快速闪烁延时200ms版本号设为0x0001。Image 1LED慢速闪烁延时2s版本号设为0x0002。4.2 步骤一编译并获取原始Bin文件打开SDK中的evkmimxrt595\driver_examples\gpio\led_output\iar工程。在main.c中修改延时函数参数分别生成两个工程配置或编译两次手动改代码Delay_ms(200);- 编译生成gpio_led_output_delay200ms.binDelay_ms(2000);- 编译生成gpio_led_output_delay2s.bin从IAR的调试输出目录如Debug\Exe复制出这两个.bin文件。此时它们只是纯粹的应用程序二进制不含任何启动头、版本信息或CRC参数。4.3 步骤二使用MCUBootUtility注入CRC32参数这是最核心的一步工具帮我们完成了繁琐的填充工作。连接板卡将EVK板通过USB线连接到PC并使其进入串行下载模式通常需要按住某个按钮再复位。打开MCUBootUtility在Boot Device选择UART或USB-HID取决于你的连接方式。在Boot Device Memory选择Serial NOR Flash。最关键的一步在Secure Boot Type下拉框中选择Plain CRC Image。这个选项告诉工具我们要生成一个带CRC32校验但不签名的镜像。生成并下载Image 0点击Image File旁边的浏览按钮选择gpio_led_output_delay200ms.bin。点击右下角的All-In-One Action按钮。工具会弹出配置窗口。在这里你需要设置Image Version: 设置为0x0001。工具会自动计算其取反值0xFFFE并填入。其他选项如FlexSPI Configuration、Image Vector Table Offset等工具会根据芯片型号和Plain CRC Image类型自动填充默认值通常无需修改。点击OK工具会执行一系列操作生成FDCB、插入img_ver、计算CRC32并填入中断向量表保留区、最后通过UART/USB将完整的镜像烧写到Flash的0x0地址。读回并保存Image 0为了得到包含了所有启动头和CRC参数的“完整镜像文件”我们需要把它从Flash里读回来。在MCUBootUtility主界面切换到Boot Device Memory标签页。在Start Address输入0x0。我们需要知道读取的长度。工具在下载时会在0x08001020地址即中断向量表起始0x080010000x20写入imageLength。我们可以在“通用编程器”模式下先连接板卡读取0x08001020处的4字节值。假设读到的imageLength 0x36E8。那么整个镜像文件大小 imageLoadAddress - 0x08000000 imageLength0x1000 0x36E8 0x46E8字节。在Length输入0x46E8点击Read。读取完成后点击Save将其保存为gpio_led_output_delay200ms_crc.bin。重复步骤生成Image 1回到All-In-One标签页。选择gpio_led_output_delay2s.binImage Version设置为0x0002。这次在下载配置窗口里你需要手动指定Destination Address为0x400000即我们OTP中设置的Image 1偏移地址。执行下载。同样在Boot Device Memory标签页从0x400000地址读取0x46E8字节假设长度相同保存为gpio_led_output_delay2s_crc.bin。现在你得到了两个“武装到牙齿”的、支持CRC32校验的完整镜像文件。4.4 步骤三手动验证CRC32值可选但推荐在依赖BootROM校验之前自己先验算一遍可以极大增强信心。我们以gpio_led_output_delay200ms_crc.bin为例。提取待计算数据用二进制查看工具如HxD打开gpio_led_output_delay200ms_crc.bin。我们需要计算从imageLoadAddress开始长度为imageLength的数据的CRC32。文件偏移0x20处是imageLength假设为0x000036E8。文件偏移0x34处是imageLoadAddress对于XIP镜像这里应该是0x08001000。但计算时我们关心的是数据在文件内的偏移。因为FDCB和img_ver共占0x1000字节所以应用程序数据在文件内的偏移就是从0x1000开始。因此待计算数据范围是文件偏移0x1000至0x1000 0x36E8 - 1 0x46E7。关键操作CRC计算必须排除crcChecksum自身的4个字节。这4个字节位于imageLoadAddress 0x28对应文件偏移0x1000 0x28 0x1028到0x102B。在提取数据时需要将这4个字节剔除或置零BootROM是跳过。使用在线工具计算访问一个可靠的在线CRC计算网站如sunshine2k.de的CRC工具。参数设置CRC algorithm: 选择CRC-32/MPEG-2。如果找不到选择CRC-32并确保参数为Polynomial0x04C11DB7, Initial Value0xFFFFFFFF, Final XOR0x00000000, Input/Output ReflectedFalse。Data format: 选择Hex。从你的bin文件中复制从0x1000到0x1027的字节再复制从0x102C到0x46E7的字节合并成一个连续的Hex字符串粘贴到输入框。点击计算。得到的CRC32结果应该与你bin文件中0x1028开始的4字节值小端格式完全一致。例如我计算得到的0x4D8957D8与文件中的值匹配。这一步验证成功说明我们的镜像结构和CRC参数填充是正确的。4.5 步骤四烧写OTP并测试双启动烧写OTP配置如果尚未烧写在MCUBootUtility的All-In-One或专用OTP工具界面找到Boot CFG2和Boot CFG3的配置。将Second Image Offset设置为0x10代表4MB偏移。将FlexSPI Remap Size设置为0代表Image 0大小为4MB。烧写OTP前务必确认然后执行烧写。烧写后需要给芯片完全断电再上电新的OTP配置才能生效。烧写两个镜像使用MCUBootUtility的Boot Device Memory通用编程器功能。连接板卡擦除整个Flash或相关扇区。将gpio_led_output_delay200ms_crc.bin下载到地址0x0。将gpio_led_output_delay2s_crc.bin下载到地址0x400000。功能测试复位板卡观察LED闪烁频率。应该启动版本号更高的Image 12秒间隔。手动修改Image 1的CRC值在bin文件中0x400000 0x1028的位置改一个字节或者用编程器擦除Image 1的一小部分然后再次复位。BootROM在检查Image 1时CRC校验会失败版本头虽然有效但镜像无效因此会fallback到版本号更低但完好的Image 0200ms间隔。LED闪烁应变为快速。修复Image 1后再次复位应该又能切回Image 1启动。5. 避坑指南与高级技巧在实际操作中我遇到了不少问题这里总结一下希望你能绕开这些坑。5.1 链接地址的“铁律”对于XIP应用程序其链接地址即中断向量表起始地址必须严格设置为0x08001000对于FlexSPI0。这个0x1000的偏移是留给FDCB和img_ver的。在IAR或Keil的链接脚本中务必检查.intvec段或VECTOR_TABLE的起始地址是否正确。如果链接地址错误BootROM将无法正确找到中断向量表和CRC参数导致启动失败。5.2 Non-XIP镜像的特殊处理如果你的应用程序太大或需要更快执行速度需要配置为Non-XIP从Flash加载到RAM运行流程会复杂一些链接地址应用程序需链接到RAM地址如0x20000000。imageLoadAddress在中断向量表偏移0x34处填入的必须是RAM中的链接地址如0x20000000因为CRC校验发生在加载之后。生成含启动头的BinarySDK编译通常只生成纯应用bin。你需要借助MCUBootUtility的All-In-One操作选择正确的imageType如0x05让它帮你生成包含FDCB、img_ver和正确CRC参数的完整镜像然后再读回保存。无法通过简单修改链接脚本直接生成。5.3 CRC校验失败的可能原因如果BootROM因CRC错误拒绝启动镜像请按以下顺序排查算法标准确认手动计算CRC时使用的多项式、初始值等参数与BootROM的MPEG-2标准完全一致。计算范围确认计算的数据范围是[imageLoadAddress, imageLoadAddress imageLength)并且排除了crcChecksum所在的4字节。数据对齐确认imageLength不是4字节对齐时手动计算是否在数据末尾补了0。参数位置确认imageLength,crcChecksum,imageLoadAddress这三个值是否正确写入了中断向量表偏移0x20,0x28,0x34的位置。用二进制工具打开最终bin文件检查。imageType确认中断向量表偏移0x24处的字节是0x02XIP或0x05Non-XIP。5.4 版本号管理的建议在双启动设计中版本号是控制启动顺序的唯一手段。建议版本号递增每次发布新固件务必提高版本号。版本号规划预留出版本号区间。例如将稳定版版本号设为偶数0x0002, 0x0004...测试版版本号设为奇数0x0001, 0x0003...方便管理。出厂设置出厂时两个镜像槽应烧写相同的、版本号较高的稳定版本。这样任何一个槽位升级失败都能回退到另一个相同的稳定版本。5.5 调试手段读取状态寄存器当双启动行为不符合预期时可以通过调试器在应用程序启动后读取SYSCTL0-BOOT_OPTION寄存器地址0x4000_4384。解析其中的boot_image_index字段可以确认BootROM上一次启动的是哪个镜像。这是一个非常有效的调试手段。通过以上步骤你应该能够在i.MX RT500/600平台上稳健地实现基于CRC32校验的双程序交替启动。这套方案在保证一定固件完整性的同时兼顾了简单性和启动速度非常适合对成本和实时性有要求的工业应用。
i.MX RT500/600双备份启动与CRC32校验实现详解
发布时间：2026/5/19 14:53:17
1. 项目概述在i.MX RT500/600上实现可靠的固件双备份启动最近在做一个基于恩智浦i.MX RT595芯片的工业控制器项目客户对产品的可靠性提出了硬性要求固件升级过程中万一断电设备不能“变砖”必须能自动回滚到上一个可用的版本。这让我把目光投向了i.MX RT系列MCU内置的“双程序可交替启动”特性。虽然之前在i.MX RT1170上实现过类似功能但这次用的RT500/600系列在细节上有些“小脾气”尤其是它提供了一种不依赖复杂加密签名、仅通过CRC32校验来确保固件完整性的“平民化”方案这对于成本敏感且对启动速度有要求的场景特别友好。折腾了几天把RT500/600上这个特性的里里外外都摸了一遍特别是那个CRC32校验的使能和验证过程有不少官方文档没细说的坑。今天就把从设计思路到实操踩坑的全过程整理出来如果你也在用RT500/600做高可靠性的产品这篇笔记应该能帮你省下不少调试时间。简单来说这个特性允许你在同一片串行NOR Flash里存储两个完整的应用程序镜像Image 0和Image 1。芯片的BootROM在上电时会根据一套既定的策略主要看镜像版本号和完整性自动选择其中一个完好的、版本更高的镜像来启动。如果主镜像损坏它能自动 fallback 到备份镜像从而实现固件的故障恢复和安心的空中升级。整个机制的核心逻辑和i.MX RT1170大同小异但就像不同品牌的手机系统底层功能类似设置菜单和操作细节却各有不同。下面我们就聚焦这些“不同”并重点攻克如何利用CRC32校验来为你的固件加上一道简单的“防盗门”。2. 核心逻辑解析与i.MX RT1170的差异点全拆解在开始动手前必须先把RT500/600和RT1170在双启动机制上的差异点搞清楚。直接照搬RT1170的经验可能会让你在调试时一头雾水。这些差异主要集中在镜像结构、配置位置和状态管理逻辑上。2.1 镜像结构从繁到简告别IVT与BD这是第一个直观的不同点。在i.MX RT1170上一个能被BootROM识别的、最简化的可启动镜像XIP结构包含好几个部分FlexSPI的配置块、镜像版本头、中断向量表、启动数据块最后才是应用程序本身。你可以把它想象成一个搬家包裹外面有好几层包装和清单。而在i.MX RT500/600上事情变得简单多了。一个基本的可启动镜像只需要三部分FDCB必须放在Flash偏移0x0位置。这是FlexSPI外设的配置块告诉BootROM如何正确地初始化并访问这片Flash。没有它BootROM第一步就“懵”了。img_ver镜像版本头。必须放在Flash偏移0x600的位置。这是一个4字节的结构包含一个16位的版本号version和它的按位取反值inversion。BootROM通过检查version ^ inversion是否等于0xFFFF来判断这个版本头是否有效当然RT500/600还有特殊规则后面会讲。Application应用程序本体。对于XIP就地执行镜像其链接地址即中断向量表起始地址必须固定在0x08001000。注意0x08000000是FlexSPI0的AHB映射起始地址所以应用程序在Flash中的实际存储偏移是0x1000。注意RT1170的AHB映射地址通常是0x30000000而RT500/600是0x08000000。这个系统级差异直接影响你的链接脚本和调试器配置千万别搞混。原先RT1170里必需的IVT和BD在这里被省去了。BootROM默认从img_ver之后的位置寻找应用程序的中断向量表。这种简化带来的好处是镜像头更小但同时也意味着一些高级配置如非XIP镜像的加载地址需要通过其他方式如CRC参数区或固定规则来约定。2.2 OTP配置搬家启动参数的“房产证”位置变了启用双程序启动功能需要在一块叫做OTP的“一次可编程”存储区里写入配置信息。这相当于给BootROM颁发了一个“房产证”告诉它“Flash这片地我划成了两个区域这是它们的分界线。”在RT1170和RT500/600上这个“房产证”的格式字段定义是一样的主要包含两个关键信息FlexSPI Remap Size指定了第一个镜像Image 0的最大长度。BootROM会据此计算出Image 0的结束地址。Second Image Offset指定了第二个镜像Image 1在Flash中的起始偏移地址。但是“房产证”登记的地点OTP中的地址变了i.MX RT1170配置在0x9C0和0x9D0等地址。i.MX RT500/600配置在OTP BOOT_CFG2 (0x188)和BOOT_CFG3 (0x18C)。以我使用的MIMXRT595-EVK开发板为例通过恩智浦的MCUBootUtility工具将Second Image Offset设置为0x10这个值需要根据芯片参考手册中的公式计算通常0x10代表偏移为4MBFlexSPI Remap Size保持默认的0。这样BootROM就会认为Image 0 位于 Flash 偏移0x0至0x4000004MB之间。Image 1 位于 Flash 偏移0x400000开始的位置。实操心得在烧写OTP前务必用MCUBootUtility的“Read OTP”功能先读取并确认当前值。OTP位一旦从0烧写成1就无法再改回0错误的配置可能导致芯片无法正常启动。建议先在开发板上用仿真器调试模式充分测试镜像和双启动逻辑确认无误后再进行OTP烧写。2.3 状态寄存器的“升级”从2比特到32比特的豪华套餐双启动需要一个“记忆体”来记录上一次成功启动的是哪个镜像以便本次决定尝试启动另一个如果版本更高。RT1170很“节俭”地使用了系统复位控制器里的一个通用寄存器SRC_GPR10的其中2个比特位来记录。到了RT500/600它用上了SYSCTL0外设中的一个完整的32位非易失性寄存器地址SYSCTL0_BASE 0x384。这个寄存器被设计成一个结构体user_app_boot_invoke_option_t其功能远不止记录启动状态。它实际上融合了ROM API的调用选项包含以下字段boot_image_index记录上次启动的镜像索引0或1这就是我们双启动需要的状态位。boot_interface启动接口类型如FlexSPI, USB等。mode启动模式。tag一个魔术字用于验证该结构是否被有效写入。这意味着在RT500/600上BootROM和应用程序可以通过这个寄存器进行更丰富的“对话”。例如应用程序可以通过设置这个寄存器请求在下一次复位时以特定模式从特定接口启动。对于我们实现双启动而言我们主要关心boot_image_index这个字段BootROM会在启动流程中读取并更新它。2.4 版本号逻辑的微妙变化0xFFFFFFFF成了“天选之子”镜像版本号的判断逻辑是决定启动顺序的核心。两者都检查version和inversion是否互为取反。但RT500/600引入了一个特殊规则它将0xFFFFFFFF即version和inversion均为0xFFFF也视为一个有效的版本号并且将其定义为最低的版本。这个变化直接影响BootROM的决策树有效性判断RT500/600的BootROM只启动含有有效版本号的镜像。有效性定义为a)version ^ inversion 0xFFFF 或 b)version 0xFFFF inversion 0xFFFF。如果一个镜像的版本头无效它会被直接跳过。顺序判断在两个镜像都有效的前提下BootROM会比较版本值version注意是比较version字段不是整个32位值。值更大的被视为更高版本。关键点来了0xFFFF被定义为比任何其他数值如0x0001都小的版本。因此如果你希望Image 1作为主版本除了确保其CRC等完整性还必须将其version设置为一个大于Image 0version的值。我在MIMXRT595-EVK上做了全面测试验证了以下情况镜像0版本 (version, inversion)镜像1版本 (version, inversion)BootROM 启动选择原因分析(0x0001, 0xFFFE)(0x0002, 0xFFFD)镜像1镜像1版本号(0x0002) 镜像0版本号(0x0001)(0x0002, 0xFFFD)(0x0001, 0xFFFE)镜像0镜像0版本号(0x0002) 镜像1版本号(0x0001)(0xFFFF, 0xFFFF)(0x0001, 0xFFFE)镜像1镜像1版本(0x0001)有效且 镜像0版本(0xFFFF最低)(0x0000, 0x0000)(0x0001, 0xFFFE)镜像1镜像0版本头无效(0x0000^0x00000x0000)被跳过(0x0001, 0x1234)(0x0002, 0xFFFD)可能启动失败镜像0版本头无效(取反关系不成立)若镜像1也无效则无有效镜像这个逻辑比RT1170更严格。在RT1170上版本头似乎只用于比较顺序即使无效非取反可能仍会尝试启动如果别无选择。而在RT500/600上版本头有效性是启动的必要条件。这要求我们在生成镜像时必须确保img_ver结构被正确计算和写入。3. 平民化的安全卫士CRC32校验启动详解对于许多不需要高级安全加密但又需要确保固件在存储或传输过程中未被意外破坏的应用场景RT500/600提供的CRC32校验方案是一个极佳的选择。它比数字签名方案更简单计算开销更小启动速度更快。3.1 CRC32参数的三要素藏在中断向量表里的秘密BootROM进行CRC32校验需要三个关键参数从哪里开始算、算多长、正确的值应该是多少。这些参数并没有新增一个单独的结构体而是巧妙地“寄生”在应用程序自身的中断向量表的保留位置里。对于Cortex-M内核中断向量表的前64字节0x3C是标准定义之后的部分是保留的。BootROM就利用了这里的空间。具体位置如下偏移地址均相对于应用程序中断向量表的起始地址即链接地址imageLoadAddress偏移 0x20 (4字节) -imageLength需要计算CRC32的数据的总长度。这通常是你的应用程序代码数据的大小从中断向量表开始imageLoadAddress到程序结束。注意如果这个值为0BootROM会跳过CRC校验。偏移 0x28 (4字节) -crcChecksum正确的CRC32校验值。BootROM会自己计算一遍CRC然后与这个值比较。如果不同则认为镜像损坏。偏移 0x34 (4字节) -imageLoadAddressCRC计算的起始地址也是中断向量表的起始地址。对于XIP镜像这个地址就是固定的0x08001000假设Flash在FlexSPI0。对于Non-XIP镜像需从Flash加载到RAM执行这个地址是应用程序在RAM中的链接地址。CRC计算发生在镜像被加载到RAM之后校验的是RAM中的内容。重要提示BootROM在计算CRC时有两个自动行为1. 如果计算范围包含了crcChecksum自身所在的4字节它会自动跳过这部分避免“自指”导致的校验失败。2. 如果imageLength指定的长度不是4字节的整数倍它会自动在数据末尾补0直到对齐再进行计算。我们在手动计算CRC时必须模仿这个行为。3.2 如何开启CRC32校验一把钥匙开一把锁仅仅在指定位置填上参数还不够还需要一个“开关”来告诉BootROM“请对这个镜像进行CRC校验”。这个开关就是中断向量表偏移0x24处的一个字节imageType[7:0]。当这个字节的值被设置为0x02或0x05并且imageLength不为0时BootROM就会使能CRC32校验流程。0x02和0x05是BootROM定义的镜像类型标识通常0x02用于XIP镜像0x05用于Non-XIP镜像。你需要根据你的应用程序链接方式设置正确的imageType。3.3 BootROM使用的CRC32算法MPEG-2标准CRC有多个标准多项式不同结果天差地别。RT500/600的BootROM使用的是CRC-32/MPEG-2标准。其核心参数如下多项式0x04C11DB7初始值0xFFFFFFFF输入/输出反转无refIn false, refOut false结果异或值0x00000000BootROM内部利用了芯片的硬件CRC模块来计算该模块固定支持几种多项式MPEG-2是其中之一。我们在上位机手动计算CRC时必须使用完全相同的参数。很多CRC计算工具或库默认使用CRC-32即CRC-32/ISO-HDLC其输出会与0xFFFFFFFF异或如果选错标准算出来的值对不上BootROM就会报错。4. 实战演练从零构建带CRC32校验的双启动镜像理论铺垫完毕现在进入实战环节。我们以MIMXRT595-EVK板卡和SDK中的gpio_led_output例程为基础制作两个版本号不同、LED闪烁间隔不同的镜像并启用CRC32校验最终实现双程序交替启动。4.1 准备工作与环境搭建硬件MIMXRT595-EVK开发板。软件MCUXpresso IDE或IAR/Keil用于编译SDK示例工程。我使用的是IAR。恩智浦 MCU Boot Utility (v3.5.0或更高)这是关键工具用于生成启动头、填充CRC参数、烧写OTP和Flash。务必使用v3.5.0以上版本它才支持“Plain CRC Image”类型。芯片SDK确保已安装MIMXRT595的SDK如SDK_2.10.1_EVK-MIMXRT595。目标创建两个镜像。Image 0LED快速闪烁延时200ms版本号设为0x0001。Image 1LED慢速闪烁延时2s版本号设为0x0002。4.2 步骤一编译并获取原始Bin文件打开SDK中的evkmimxrt595\driver_examples\gpio\led_output\iar工程。在main.c中修改延时函数参数分别生成两个工程配置或编译两次手动改代码Delay_ms(200);- 编译生成gpio_led_output_delay200ms.binDelay_ms(2000);- 编译生成gpio_led_output_delay2s.bin从IAR的调试输出目录如Debug\Exe复制出这两个.bin文件。此时它们只是纯粹的应用程序二进制不含任何启动头、版本信息或CRC参数。4.3 步骤二使用MCUBootUtility注入CRC32参数这是最核心的一步工具帮我们完成了繁琐的填充工作。连接板卡将EVK板通过USB线连接到PC并使其进入串行下载模式通常需要按住某个按钮再复位。打开MCUBootUtility在Boot Device选择UART或USB-HID取决于你的连接方式。在Boot Device Memory选择Serial NOR Flash。最关键的一步在Secure Boot Type下拉框中选择Plain CRC Image。这个选项告诉工具我们要生成一个带CRC32校验但不签名的镜像。生成并下载Image 0点击Image File旁边的浏览按钮选择gpio_led_output_delay200ms.bin。点击右下角的All-In-One Action按钮。工具会弹出配置窗口。在这里你需要设置Image Version: 设置为0x0001。工具会自动计算其取反值0xFFFE并填入。其他选项如FlexSPI Configuration、Image Vector Table Offset等工具会根据芯片型号和Plain CRC Image类型自动填充默认值通常无需修改。点击OK工具会执行一系列操作生成FDCB、插入img_ver、计算CRC32并填入中断向量表保留区、最后通过UART/USB将完整的镜像烧写到Flash的0x0地址。读回并保存Image 0为了得到包含了所有启动头和CRC参数的“完整镜像文件”我们需要把它从Flash里读回来。在MCUBootUtility主界面切换到Boot Device Memory标签页。在Start Address输入0x0。我们需要知道读取的长度。工具在下载时会在0x08001020地址即中断向量表起始0x080010000x20写入imageLength。我们可以在“通用编程器”模式下先连接板卡读取0x08001020处的4字节值。假设读到的imageLength 0x36E8。那么整个镜像文件大小 imageLoadAddress - 0x08000000 imageLength0x1000 0x36E8 0x46E8字节。在Length输入0x46E8点击Read。读取完成后点击Save将其保存为gpio_led_output_delay200ms_crc.bin。重复步骤生成Image 1回到All-In-One标签页。选择gpio_led_output_delay2s.binImage Version设置为0x0002。这次在下载配置窗口里你需要手动指定Destination Address为0x400000即我们OTP中设置的Image 1偏移地址。执行下载。同样在Boot Device Memory标签页从0x400000地址读取0x46E8字节假设长度相同保存为gpio_led_output_delay2s_crc.bin。现在你得到了两个“武装到牙齿”的、支持CRC32校验的完整镜像文件。4.4 步骤三手动验证CRC32值可选但推荐在依赖BootROM校验之前自己先验算一遍可以极大增强信心。我们以gpio_led_output_delay200ms_crc.bin为例。提取待计算数据用二进制查看工具如HxD打开gpio_led_output_delay200ms_crc.bin。我们需要计算从imageLoadAddress开始长度为imageLength的数据的CRC32。文件偏移0x20处是imageLength假设为0x000036E8。文件偏移0x34处是imageLoadAddress对于XIP镜像这里应该是0x08001000。但计算时我们关心的是数据在文件内的偏移。因为FDCB和img_ver共占0x1000字节所以应用程序数据在文件内的偏移就是从0x1000开始。因此待计算数据范围是文件偏移0x1000至0x1000 0x36E8 - 1 0x46E7。关键操作CRC计算必须排除crcChecksum自身的4个字节。这4个字节位于imageLoadAddress 0x28对应文件偏移0x1000 0x28 0x1028到0x102B。在提取数据时需要将这4个字节剔除或置零BootROM是跳过。使用在线工具计算访问一个可靠的在线CRC计算网站如sunshine2k.de的CRC工具。参数设置CRC algorithm: 选择CRC-32/MPEG-2。如果找不到选择CRC-32并确保参数为Polynomial0x04C11DB7, Initial Value0xFFFFFFFF, Final XOR0x00000000, Input/Output ReflectedFalse。Data format: 选择Hex。从你的bin文件中复制从0x1000到0x1027的字节再复制从0x102C到0x46E7的字节合并成一个连续的Hex字符串粘贴到输入框。点击计算。得到的CRC32结果应该与你bin文件中0x1028开始的4字节值小端格式完全一致。例如我计算得到的0x4D8957D8与文件中的值匹配。这一步验证成功说明我们的镜像结构和CRC参数填充是正确的。4.5 步骤四烧写OTP并测试双启动烧写OTP配置如果尚未烧写在MCUBootUtility的All-In-One或专用OTP工具界面找到Boot CFG2和Boot CFG3的配置。将Second Image Offset设置为0x10代表4MB偏移。将FlexSPI Remap Size设置为0代表Image 0大小为4MB。烧写OTP前务必确认然后执行烧写。烧写后需要给芯片完全断电再上电新的OTP配置才能生效。烧写两个镜像使用MCUBootUtility的Boot Device Memory通用编程器功能。连接板卡擦除整个Flash或相关扇区。将gpio_led_output_delay200ms_crc.bin下载到地址0x0。将gpio_led_output_delay2s_crc.bin下载到地址0x400000。功能测试复位板卡观察LED闪烁频率。应该启动版本号更高的Image 12秒间隔。手动修改Image 1的CRC值在bin文件中0x400000 0x1028的位置改一个字节或者用编程器擦除Image 1的一小部分然后再次复位。BootROM在检查Image 1时CRC校验会失败版本头虽然有效但镜像无效因此会fallback到版本号更低但完好的Image 0200ms间隔。LED闪烁应变为快速。修复Image 1后再次复位应该又能切回Image 1启动。5. 避坑指南与高级技巧在实际操作中我遇到了不少问题这里总结一下希望你能绕开这些坑。5.1 链接地址的“铁律”对于XIP应用程序其链接地址即中断向量表起始地址必须严格设置为0x08001000对于FlexSPI0。这个0x1000的偏移是留给FDCB和img_ver的。在IAR或Keil的链接脚本中务必检查.intvec段或VECTOR_TABLE的起始地址是否正确。如果链接地址错误BootROM将无法正确找到中断向量表和CRC参数导致启动失败。5.2 Non-XIP镜像的特殊处理如果你的应用程序太大或需要更快执行速度需要配置为Non-XIP从Flash加载到RAM运行流程会复杂一些链接地址应用程序需链接到RAM地址如0x20000000。imageLoadAddress在中断向量表偏移0x34处填入的必须是RAM中的链接地址如0x20000000因为CRC校验发生在加载之后。生成含启动头的BinarySDK编译通常只生成纯应用bin。你需要借助MCUBootUtility的All-In-One操作选择正确的imageType如0x05让它帮你生成包含FDCB、img_ver和正确CRC参数的完整镜像然后再读回保存。无法通过简单修改链接脚本直接生成。5.3 CRC校验失败的可能原因如果BootROM因CRC错误拒绝启动镜像请按以下顺序排查算法标准确认手动计算CRC时使用的多项式、初始值等参数与BootROM的MPEG-2标准完全一致。计算范围确认计算的数据范围是[imageLoadAddress, imageLoadAddress imageLength)并且排除了crcChecksum所在的4字节。数据对齐确认imageLength不是4字节对齐时手动计算是否在数据末尾补了0。参数位置确认imageLength,crcChecksum,imageLoadAddress这三个值是否正确写入了中断向量表偏移0x20,0x28,0x34的位置。用二进制工具打开最终bin文件检查。imageType确认中断向量表偏移0x24处的字节是0x02XIP或0x05Non-XIP。5.4 版本号管理的建议在双启动设计中版本号是控制启动顺序的唯一手段。建议版本号递增每次发布新固件务必提高版本号。版本号规划预留出版本号区间。例如将稳定版版本号设为偶数0x0002, 0x0004...测试版版本号设为奇数0x0001, 0x0003...方便管理。出厂设置出厂时两个镜像槽应烧写相同的、版本号较高的稳定版本。这样任何一个槽位升级失败都能回退到另一个相同的稳定版本。5.5 调试手段读取状态寄存器当双启动行为不符合预期时可以通过调试器在应用程序启动后读取SYSCTL0-BOOT_OPTION寄存器地址0x4000_4384。解析其中的boot_image_index字段可以确认BootROM上一次启动的是哪个镜像。这是一个非常有效的调试手段。通过以上步骤你应该能够在i.MX RT500/600平台上稳健地实现基于CRC32校验的双程序交替启动。这套方案在保证一定固件完整性的同时兼顾了简单性和启动速度非常适合对成本和实时性有要求的工业应用。
