做过 STM32H5 系列固件升级的朋友大概率见过这类问题芯片在 bootloader 跳转后不定时进入 NMI有时表现为整机复位有时停机在 HardFault反汇编一看PC 往往停在一条 flash 读取指令附近。我这次在 STM32H503 上也中招了项目日志里记的问题就是“STM32H503: random ECC/NMI on flash read after bootloader jump”。这个现象很典型但根因往往不止一个而且十有八九不是你以为的那个。这篇文章我会按实际排查顺序写下来先从现象入手再说 STM32H503 上 flash ECC 和 CPU NMI 到底怎么关联然后把跳转现场常见的几个坑逐个拆开最后给一份能直接抄的排查速查表。适合正在写 H5 系列双区 OTA、或者刚把 bootloader 从 H7/HAL 工程迁移到 H503 的人参考哪怕你只是被“随机 NMI”这五个字折磨过也能从里面找到对应的排查思路。1. 先看现场bootloader 跳转后随机 ECC/NMI 的三种典型表现1.1 现象一运行几百毫秒后突然死掉PC 落在 NMI_Handler这是我这次遇到的最典型情况。bootloader 从 UART 收完固件写进第二区 flashCRC 校验通过然后正常跳转到 app。前 200ms 内 app 跑得好好的串口日志也正常往外打突然就停了。用调试器连上去一看PC 停在 NMI_Handler 里堆栈回溯指向 app 里某个 flash 常量读取或者函数跳转指令比如LDR.W R0, [R1, #4]这种。最迷惑的地方在于问题不是每次都能复现。复现概率大概三分之一而且跟跳转后有没有马上开外设中断关系不大。我最初怀疑是 app 的中断优先级配错了又把 ICACHE 关闭、NVIC 全部清空试了一遍问题依旧浪费了大半天。1.2 现象二插上调试器反而不出现脱机运行必现另一个值得注意的现象是只要用 ST-LINK 连接并全速运行出问题的概率明显降低一旦拔掉调试器、上电循环启动几乎是 100% 跑到一定位置就 NMI。这种情况在很多“时序类”故障里特别常见因为调试器本身会改变 flash 读取的时序也会影响复位后的启动时间有时候还会把供电电压拉高一点让其实已经不稳的 flash 接口暂时稳定下来。如果你遇到这种“带调试器不复现”的随机死机先别急着怀疑软件逻辑先怀疑电源、时钟配置、以及 flash 控制器相关寄存器是否在跳转前被恢复干净了。1.3 现象三取消优化后不复现开 -O2 后稳定复现这个问题尤其坑人。把 app 编译优化等级从 -O0 改成 -O2就可能稳定的复现 NMI。之前我以为是不是编译器生成了什么非对齐访问指令后来才发现优化等级变化会导致 flash 常量地址布局变化最终落到某个 ECC 校验不过的 flash 区域里。这类问题往往说明flash 某个扇区里存的“数据”和它对应的“ECC 校验位”不一致。所以遇到“随机 NMI”时不要只盯代码还要去看 flash 里的数据是不是真的被正常写入。STM32H503 的 flash 是带 ECC 的很多随机读取错误本质上就是数据区域里已经有坏 ECC 标记了。2. 先说清楚原理STM32H503 上 Flash ECC 和 CPU NMI 是怎么关联的2.1 带 ECC 的 Flash什么情况下会在读取时报错STM32H503 这类带 ECCError Correction Code的闪存不是简单的“存 0 存 1”而是把数据按一定长度分组在每个组后面多存几位 ECC 校验位。硬件读取这个组时会同时读出数据位和校验位然后通过 ECC 算法判断这次读取有没有出错。如果只有 1 位数据翻转ECC 可以自动纠正这种叫单错纠正SECSingle Error Correction如果出现了 2 位或以上翻转ECC 纠正不了这种叫双错检测DEDDouble Error Detection通常会直接上报错误事件甚至触发 NMI。在 STM32H503 上flash 接口会把这部分 ECC 事件记录在 flash 控制器的错误寄存器里比如FLASH_ECCR或者对应的状态寄存器。关键是这个错误不一定发生在你写 flash 的时候而是发生在你读 flash 的时候。一旦 CPU 访问到某个 ECC 校验失败的地址硬件就可能把错误挂到 CPU 的 NMI 线上。2.2 什么情况下 ECC 会引发 NMI而不是 HardFault很多从 STM32F1/F4 时代过来的工程师对 ECC 的印象是“纠错”对 NMI 的印象是“看门狗、掉电检测、外部 NMI 引脚”。到了 H5 系列flash 读取阶段的 ECC 错误也可以被路由到 NMI这是由芯片内部互联决定的并不完全由 CPU 核心本身决定。具体来说NMI 触发的路径大概是CPU 从 flash 地址发起读取flash 控制器读出主数据ECC 校验失败且错误级别达到双错或者不可纠正flash 控制器将错误事件发送给中断控制器触发 NMI 请求CPU 跳转到NMI_Handler程序停在那里。如果用的是默认启动文件NMI_Handler往往就是一个死循环B .。你在调试器里看到的现象就是“程序就卡在 NMI_Handler 里怎么也出不来”。如果 firmware 里设置了自己的 NMI 回调可能在 NMI 中断里做复位那外部看到的就是“随机复位”。这里要特别提醒一下NMI 不一定是 ECC 引起的但 ECC 双错确实会让 CPU 进入 NMI。排查时不要一进 NMI 就去查 ECC而是先保存现场、读取寄存器再确定是哪条路径触发的。2.3 Bootloader 跳转在 CPU 层面到底做了什么Bootloader 跳转 app 的本质不是“重新执行一遍 SystemInit”而是直接完成两件事把主栈指针 MSP 设置为 app 向量表第一个 word 的内容把 PC 设置到 app 向量表第二个 word复位向量指向的地址。但问题在于在这两件事之前CPU 还处于 bootloader 的环境里外设中断可能还开着SysTick 还在跑系统时钟可能已经切到 PLLVTOR 还指向 bootloader 的向量表某些外设还在占用 DMATrustZone 的安全/非安全映射也可能还停在 bootloader 期望的状态。这些残留状态加上 flash 读取本身就会产生很多种类的问题。跳转后凡是访问 flash 地址一旦被某个中断打断而中断向量表还没正确切到 appCPU 就可能跑到 bootloader 的旧向量里去执行执行到非法地址后又触发总线错误。如果这个总线错误又被配置成 NMI那就完全是一副“flash 读取随机 ECC/NMI”的样子了。3. 完整排查过程从 NMI_Handler 一路查到 Flash 数据内容3.1 第一步把 NMI_Handler 改成“黑匣子”先保存现场排查随机问题的第一原则就是不能让异常处理程序把现场吃掉。我把默认的NMI_Handler改成一个固定的现场保存函数把关键寄存器写到 RAM 里固定地址然后死循环。注意这里写 RAM 而不是写 flash否则在 NMI 里再去访问 flash很可能触发二次 ECC 错误导致现场又丢了。#define DEBUG_SAVE_ADDR (0x20001000UL) __attribute__((used)) void NMI_Handler(void) { volatile uint32_t *save (volatile uint32_t *)DEBUG_SAVE_ADDR; save[0] __get_MSP(); save[1] __get_PSP(); save[2] SCB-ICSR; save[3] SCB-CFSR; save[4] SCB-HFSR; save[5] FLASH-ECCR; // 以当前项目手册为准 save[6] FLASH-SR; // 部分型号叫 FLASH_SR save[7] RCC-CR; // 时钟配置状态 save[8] (uint32_t)SCB-VTOR; save[9] __get_CONTROL(); while (1) { __NOP(); } }这种做法的好处是复位后可以从 RAM 里把现场数据捞出来快速判断是 ECC 还是总线错误也方便做多轮循环测试。实际调试时可以通过 IDE 的 Memory View 去读0x20001000这块区域。3.2 第二步确认是不是真正的 ECC 错误拿到现场数据后我第一个判断依据是FLASH-ECCR里的标志位。如果错误标志被置位说明这次 NMI 确实来自 flash ECC 事件。同时把FLASH-ECCR里记录的故障地址读出来看看它是落在 bootloader 区域还是 app 区域。读取示范代码大致如下uint32_t ecc_addr 0; uint32_t ecc_sr FLASH-SR; if ((ecc_sr FLASH_SR_ECC_ERROR) ! 0) { ecc_addr FLASH-ECCR FLASH_ECCR_ADDR_MASK; printf(ECC error addr 0x%08X\r\n, ecc_addr); }在这次调试中读出来的故障地址指向 app 区域的一个常量数组而那个数组在镜像里确实存在。按理说这个区域在烧录时应该已经写入了正确的 ECC 校验位怎么还会在读取时报错3.3 第三步怀疑跳转代码没有做干净逐条核对因为故障地址看起来“合理”我一度认为是跳转前中断残留导致 app 异常访问于是写了一个尽可能彻底的跳转函数把所有能想到的状态都清理了一遍。这个函数后来也成了我这边 H5 系列跳转的模板__attribute__((section(.text))) void jump_to_app(uint32_t app_addr) { uint32_t app_sp; uint32_t app_pc; uint32_t i; // 1. 关全局中断 __disable_irq(); // 2. 停掉 SysTick避免跳转后 SysTick 打断向量切换 SysTick-CTRL 0; SysTick-VAL 0; // 3. 关闭并清挂起所有 NVIC 中断 for (i 0; i 8; i) { NVIC-ICER[i] 0xFFFFFFFFUL; NVIC-ICPR[i] 0xFFFFFFFFUL; } // 4. 复位系统时钟到默认 MSI关闭已经使能的 PLL/HSE HAL_RCC_DeInit(); // 5. 关闭所有外设时钟并在必要时重新初始化默认外设 HAL_DeInit(); // 6. 如果 bootloader 开过 cache必须做无效化不能只关闭 SCB_InvalidateICache(); SCB_InvalidateDCache(); __DSB(); __ISB(); // 7. 重新设置 VTOR注意向量表对齐通常 0x400 对齐比较稳 SCB-VTOR app_addr ~0x3FFUL; __DSB(); __ISB(); // 8. 取 app 的初始栈指针和复位向量 app_sp *(volatile uint32_t *)app_addr; app_pc *(volatile uint32_t *)(app_addr 4); // 9. 切换 MSP __set_MSP(app_sp); __set_CONTROL(0); __DSB(); __ISB(); // 10. 跳转 typedef void (*pFunction)(void); pFunction app_reset (pFunction)app_pc; app_reset(); }关键点在于第 6 步如果不执行 cache invalidate跳转后 app 可能命中 bootloader 留下的旧缓存一旦旧缓存里的地址因为映射或者安全属性不匹配就可能出现访问异常表现起来就是随机死机。H503 虽然内部资源比 H7 小但如果你开了 ICACHE这步一定要加。奇怪的是我把跳转函数改成这样以后问题复现的概率有所降低但没有根除。说明至少还存在另一层问题。3.4 第四步检查 flash 里的数据本身是不是 ECC 正常当我再次从 ECC 故障地址周围读取数据时发现了一个更大嫌疑这个镜像并不是用 ST-LINK 整片烧写的而是通过 bootloader 自己的 UART YModem 流程一包一包写入第二区 flash 的。我在写 flash 时做了完整的 8 字节对齐、页擦除、双字编程CRC 也校验通过但问题恰恰出在“CRC 校验通过”上。STM32H5 这类 flashECC 校验位是由硬件在双字/字写入时自动计算的。如果你写入的数据长度不是 flash 写入要求的最小单位或者中间有一次写入没有按边界对齐硬件会把这次写入自动截断、合并或者填充导致最后 flash 里的“数据内容”是连续的但“ECC 校验位”和它并不对应同一个物理行。CRC 只能验证数据内容的一致不能验证 ECC 元数据本身是否正确。检查方法很简单把故障地址所在的 flash 行读出来和工程里生成的 bin 文件对应偏移逐字节对比。如果内容一致但一读就 ECC 报错而且这个区域不是从复位向量开始的那基本可以确定是写 flash 时靠 fill/对齐产生的 ECC 元数据错位。当 flash 写入逻辑不能严格按“8 字节或者 16 字节整块写入”的时候就会留下这种“看不见的坏块”。第一次从 bootloader 跳过去使用它时如果恰好访问到那些区域就会随机 NMI。3.5 第五步TrustZone/安全状态导致的隐蔽 NMI还有一个绕不开的坑STM32H503 是支持 TrustZone 的如果你的 bootloader 是安全状态下跑的而 app 是非安全状态那跳转时对 GTZC、SAU 安全属性的切换就非常关键。跳转后 app 如果访问了被标记为“安全访问”的 flash 区域但代码本身运行在“非安全状态”CPU 会触发安全异常严重时也会被当成 NMI 处理。这种场景的排查特征是进入 NMI 前程序往往刚访问某个全局变量或者 flash 常量但你把地址换成 RAM 里的备份后死机概率立刻下降。处理办法是bootloader 跳转前显式调用TZ_SAU_Update或者参考 STM32Cube 里Secure/NonSecure工程模板把 flash/RAM 的安全属性切到 app 预期状态不要把安全中断和非安全中断混着使能跳转前把安全 NVIC 也清一遍确认SEC_MPU或者 GTZC 的访问策略没有挡住 app 需要访问的外设区域。在纯 bootloader app 的裸机工程里很多人会忽略 TrustZone 相关初始化。但如果你的工程是从 STM32CubeMX 生成的并且勾选了 TrustZone这一条必须纳入排查范围。4. 常见问题与排查速查以及我给自己的几条规定4.1 症状速查表一张表覆盖大多数随机 NMI 情况下面这张表是我这次排障过程中整理出来的也是我后来给团队内部用的速查表。现象主要怀疑方向先检查什么跳转后很快进入 NMIPC 停在 app 前几条指令向量表 VTOR 没切、MSP 不对、app 链接地址与跳转地址不一致读SCB-VTOR、打开反汇编看复位向量是否跳到了预期地址运行几百 ms 后随机 NMI地址指向某个常量区flash 数据区 ECC 元数据不对或 Cache 命中旧数据读FLASH-ECCR故障地址对比 bin 文件该偏移内容开优化等级后稳定复现编译器调整了布局落到坏 ECC 区域对 app 区域做全量 ECC 检查必要时重新整片烧写只有脱机运行复现接调试器不复现电源/时序/等待状态问题增加复位延时检查 VOS 电压等级和 flash 等待周期跳转后第一次访问外设即 NMI外设中断残留在 bootloader 中或者外设时钟未重新配置清空 NVIC、HAL_RCC_DeInit、进入 app 后重新初始化所有外设跳转后访问全局变量即 NMITrustZone 安全属性不匹配检查 SAU/GTZC 对 RAM/flash 区间的安全标记NMI 现场里FLASH-ECCR和CFSR都无有效标志问题可能不是 flash ECC而是电源监控/NMI 引脚查看 EXTICR、电源控制寄存器外部 NMI 引脚是否被拉低4.2 值得保留的几条经验第一跳转代码尽量放到 RAM 里执行。虽然 H503 的 flash 在跳转时通常没有正在执行的写操作但把跳转函数放到 RAM 里可以彻底排除“跳转过程本身访问 flash 触发读取异常”的可能。实现不复杂在链接脚本里划出一小块 RAM 区域把跳转函数放到那边即可。第二生产自检里一定要加 ECC 扫描。 bootloader 里可以做一次后台扫描循环读取 app 区所有地址当 ECC 错误被纠错或者被检测到时记录下来。即使这次随机问题是跳转代码没写干净排查层面也可以靠这种扫描提前发现坏数据区域。第三OTA 后不要只做 CRC再做一次全量读回比对。特别是用自定义通信协议升级时尽量在写入 flash 后把每个 8 字节块再读一次确认硬件写入产生的数据和 bin 完全一致。如果发现不一致优先检查写入长度必须是 flash 编程宽度的整数倍地址也必须按编程宽度对齐。第四把跳转函数里每一步都用__DSB()和__ISB()隔离。不要省这两条指令它们不是“只对 Cortex-A 有用”在 Cortex-M33 上同样影响指令流水线和存储访问顺序。少写一条__ISB()就可能让 VTOR 或 MSP 设置还没有生效的时候app 复位向量就已经被预取出来了。4.3 这个问题的后续扩展思路后来我把这个 bootloader 的跳转流程又做了一层加固每次跳转前先从 bootloader 端读一次 app 的向量表前 8 个 word逐个检查是不是可执行地址并做一次 flash ECC 感知检查。如果发现 ECC 事件就阻止跳转要求重新下载固件。这个逻辑看上去多花了几百毫秒但在量产现场非常有用能避免大量“随机死机返修”的麻烦。还能把 ECC 错误计数的监控放到 app 的周期性任务里定时读取 flash 控制器的 ECC 错误标志并累计。一旦发现某块地址反复出现 ECC 错误哪怕只是单错纠正也可以及时上报业务层。通过这种方式很多潜在的 flash 老化问题都能在彻底死机之前暴露出来。写在最后这次排查给我最大的体会是STML32H503 的随机 ECC/NMI十有八九不是“芯片坏了”而是“跳转前后状态没有对齐”和“flash 数据区域本身存在 ECC 元数据不一致”的叠加。NMI_Handler 里看到 ECC 标志的那一刻要做的不是急着去清标志而是把故障地址、上下文寄存器、时钟状态全部留下来再回头看 bootloader 是怎么跳的固件又是怎么写进去的。如果你也在做类似的 H5 系列 bootloader我建议先把跳转函数做成一个独立模块严格清理中断、时钟、缓存、VTOR再在 app 区写入流程里加上边界检查和读回对比。把这两件事都做干净后这个看起来像随机故障的问题其实是可以稳定消除的。
做过 STM32H5 系列固件升级的朋友大概率见过这类问题芯片在 bootloader 跳转后不定时进入 NMI有时表现为整机复位有时停机在 HardFault反汇编一看PC 往往停在一条 flash 读取指令附近。我这次在 STM32H503 上也中招了项目日志里记的问题就是“STM32H503: random ECC/NMI on flash read after bootloader jump”。这个现象很典型但根因往往不止一个而且十有八九不是你以为的那个。这篇文章我会按实际排查顺序写下来先从现象入手再说 STM32H503 上 flash ECC 和 CPU NMI 到底怎么关联然后把跳转现场常见的几个坑逐个拆开最后给一份能直接抄的排查速查表。适合正在写 H5 系列双区 OTA、或者刚把 bootloader 从 H7/HAL 工程迁移到 H503 的人参考哪怕你只是被“随机 NMI”这五个字折磨过也能从里面找到对应的排查思路。1. 先看现场bootloader 跳转后随机 ECC/NMI 的三种典型表现1.1 现象一运行几百毫秒后突然死掉PC 落在 NMI_Handler这是我这次遇到的最典型情况。bootloader 从 UART 收完固件写进第二区 flashCRC 校验通过然后正常跳转到 app。前 200ms 内 app 跑得好好的串口日志也正常往外打突然就停了。用调试器连上去一看PC 停在 NMI_Handler 里堆栈回溯指向 app 里某个 flash 常量读取或者函数跳转指令比如LDR.W R0, [R1, #4]这种。最迷惑的地方在于问题不是每次都能复现。复现概率大概三分之一而且跟跳转后有没有马上开外设中断关系不大。我最初怀疑是 app 的中断优先级配错了又把 ICACHE 关闭、NVIC 全部清空试了一遍问题依旧浪费了大半天。1.2 现象二插上调试器反而不出现脱机运行必现另一个值得注意的现象是只要用 ST-LINK 连接并全速运行出问题的概率明显降低一旦拔掉调试器、上电循环启动几乎是 100% 跑到一定位置就 NMI。这种情况在很多“时序类”故障里特别常见因为调试器本身会改变 flash 读取的时序也会影响复位后的启动时间有时候还会把供电电压拉高一点让其实已经不稳的 flash 接口暂时稳定下来。如果你遇到这种“带调试器不复现”的随机死机先别急着怀疑软件逻辑先怀疑电源、时钟配置、以及 flash 控制器相关寄存器是否在跳转前被恢复干净了。1.3 现象三取消优化后不复现开 -O2 后稳定复现这个问题尤其坑人。把 app 编译优化等级从 -O0 改成 -O2就可能稳定的复现 NMI。之前我以为是不是编译器生成了什么非对齐访问指令后来才发现优化等级变化会导致 flash 常量地址布局变化最终落到某个 ECC 校验不过的 flash 区域里。这类问题往往说明flash 某个扇区里存的“数据”和它对应的“ECC 校验位”不一致。所以遇到“随机 NMI”时不要只盯代码还要去看 flash 里的数据是不是真的被正常写入。STM32H503 的 flash 是带 ECC 的很多随机读取错误本质上就是数据区域里已经有坏 ECC 标记了。2. 先说清楚原理STM32H503 上 Flash ECC 和 CPU NMI 是怎么关联的2.1 带 ECC 的 Flash什么情况下会在读取时报错STM32H503 这类带 ECCError Correction Code的闪存不是简单的“存 0 存 1”而是把数据按一定长度分组在每个组后面多存几位 ECC 校验位。硬件读取这个组时会同时读出数据位和校验位然后通过 ECC 算法判断这次读取有没有出错。如果只有 1 位数据翻转ECC 可以自动纠正这种叫单错纠正SECSingle Error Correction如果出现了 2 位或以上翻转ECC 纠正不了这种叫双错检测DEDDouble Error Detection通常会直接上报错误事件甚至触发 NMI。在 STM32H503 上flash 接口会把这部分 ECC 事件记录在 flash 控制器的错误寄存器里比如FLASH_ECCR或者对应的状态寄存器。关键是这个错误不一定发生在你写 flash 的时候而是发生在你读 flash 的时候。一旦 CPU 访问到某个 ECC 校验失败的地址硬件就可能把错误挂到 CPU 的 NMI 线上。2.2 什么情况下 ECC 会引发 NMI而不是 HardFault很多从 STM32F1/F4 时代过来的工程师对 ECC 的印象是“纠错”对 NMI 的印象是“看门狗、掉电检测、外部 NMI 引脚”。到了 H5 系列flash 读取阶段的 ECC 错误也可以被路由到 NMI这是由芯片内部互联决定的并不完全由 CPU 核心本身决定。具体来说NMI 触发的路径大概是CPU 从 flash 地址发起读取flash 控制器读出主数据ECC 校验失败且错误级别达到双错或者不可纠正flash 控制器将错误事件发送给中断控制器触发 NMI 请求CPU 跳转到NMI_Handler程序停在那里。如果用的是默认启动文件NMI_Handler往往就是一个死循环B .。你在调试器里看到的现象就是“程序就卡在 NMI_Handler 里怎么也出不来”。如果 firmware 里设置了自己的 NMI 回调可能在 NMI 中断里做复位那外部看到的就是“随机复位”。这里要特别提醒一下NMI 不一定是 ECC 引起的但 ECC 双错确实会让 CPU 进入 NMI。排查时不要一进 NMI 就去查 ECC而是先保存现场、读取寄存器再确定是哪条路径触发的。2.3 Bootloader 跳转在 CPU 层面到底做了什么Bootloader 跳转 app 的本质不是“重新执行一遍 SystemInit”而是直接完成两件事把主栈指针 MSP 设置为 app 向量表第一个 word 的内容把 PC 设置到 app 向量表第二个 word复位向量指向的地址。但问题在于在这两件事之前CPU 还处于 bootloader 的环境里外设中断可能还开着SysTick 还在跑系统时钟可能已经切到 PLLVTOR 还指向 bootloader 的向量表某些外设还在占用 DMATrustZone 的安全/非安全映射也可能还停在 bootloader 期望的状态。这些残留状态加上 flash 读取本身就会产生很多种类的问题。跳转后凡是访问 flash 地址一旦被某个中断打断而中断向量表还没正确切到 appCPU 就可能跑到 bootloader 的旧向量里去执行执行到非法地址后又触发总线错误。如果这个总线错误又被配置成 NMI那就完全是一副“flash 读取随机 ECC/NMI”的样子了。3. 完整排查过程从 NMI_Handler 一路查到 Flash 数据内容3.1 第一步把 NMI_Handler 改成“黑匣子”先保存现场排查随机问题的第一原则就是不能让异常处理程序把现场吃掉。我把默认的NMI_Handler改成一个固定的现场保存函数把关键寄存器写到 RAM 里固定地址然后死循环。注意这里写 RAM 而不是写 flash否则在 NMI 里再去访问 flash很可能触发二次 ECC 错误导致现场又丢了。#define DEBUG_SAVE_ADDR (0x20001000UL) __attribute__((used)) void NMI_Handler(void) { volatile uint32_t *save (volatile uint32_t *)DEBUG_SAVE_ADDR; save[0] __get_MSP(); save[1] __get_PSP(); save[2] SCB-ICSR; save[3] SCB-CFSR; save[4] SCB-HFSR; save[5] FLASH-ECCR; // 以当前项目手册为准 save[6] FLASH-SR; // 部分型号叫 FLASH_SR save[7] RCC-CR; // 时钟配置状态 save[8] (uint32_t)SCB-VTOR; save[9] __get_CONTROL(); while (1) { __NOP(); } }这种做法的好处是复位后可以从 RAM 里把现场数据捞出来快速判断是 ECC 还是总线错误也方便做多轮循环测试。实际调试时可以通过 IDE 的 Memory View 去读0x20001000这块区域。3.2 第二步确认是不是真正的 ECC 错误拿到现场数据后我第一个判断依据是FLASH-ECCR里的标志位。如果错误标志被置位说明这次 NMI 确实来自 flash ECC 事件。同时把FLASH-ECCR里记录的故障地址读出来看看它是落在 bootloader 区域还是 app 区域。读取示范代码大致如下uint32_t ecc_addr 0; uint32_t ecc_sr FLASH-SR; if ((ecc_sr FLASH_SR_ECC_ERROR) ! 0) { ecc_addr FLASH-ECCR FLASH_ECCR_ADDR_MASK; printf(ECC error addr 0x%08X\r\n, ecc_addr); }在这次调试中读出来的故障地址指向 app 区域的一个常量数组而那个数组在镜像里确实存在。按理说这个区域在烧录时应该已经写入了正确的 ECC 校验位怎么还会在读取时报错3.3 第三步怀疑跳转代码没有做干净逐条核对因为故障地址看起来“合理”我一度认为是跳转前中断残留导致 app 异常访问于是写了一个尽可能彻底的跳转函数把所有能想到的状态都清理了一遍。这个函数后来也成了我这边 H5 系列跳转的模板__attribute__((section(.text))) void jump_to_app(uint32_t app_addr) { uint32_t app_sp; uint32_t app_pc; uint32_t i; // 1. 关全局中断 __disable_irq(); // 2. 停掉 SysTick避免跳转后 SysTick 打断向量切换 SysTick-CTRL 0; SysTick-VAL 0; // 3. 关闭并清挂起所有 NVIC 中断 for (i 0; i 8; i) { NVIC-ICER[i] 0xFFFFFFFFUL; NVIC-ICPR[i] 0xFFFFFFFFUL; } // 4. 复位系统时钟到默认 MSI关闭已经使能的 PLL/HSE HAL_RCC_DeInit(); // 5. 关闭所有外设时钟并在必要时重新初始化默认外设 HAL_DeInit(); // 6. 如果 bootloader 开过 cache必须做无效化不能只关闭 SCB_InvalidateICache(); SCB_InvalidateDCache(); __DSB(); __ISB(); // 7. 重新设置 VTOR注意向量表对齐通常 0x400 对齐比较稳 SCB-VTOR app_addr ~0x3FFUL; __DSB(); __ISB(); // 8. 取 app 的初始栈指针和复位向量 app_sp *(volatile uint32_t *)app_addr; app_pc *(volatile uint32_t *)(app_addr 4); // 9. 切换 MSP __set_MSP(app_sp); __set_CONTROL(0); __DSB(); __ISB(); // 10. 跳转 typedef void (*pFunction)(void); pFunction app_reset (pFunction)app_pc; app_reset(); }关键点在于第 6 步如果不执行 cache invalidate跳转后 app 可能命中 bootloader 留下的旧缓存一旦旧缓存里的地址因为映射或者安全属性不匹配就可能出现访问异常表现起来就是随机死机。H503 虽然内部资源比 H7 小但如果你开了 ICACHE这步一定要加。奇怪的是我把跳转函数改成这样以后问题复现的概率有所降低但没有根除。说明至少还存在另一层问题。3.4 第四步检查 flash 里的数据本身是不是 ECC 正常当我再次从 ECC 故障地址周围读取数据时发现了一个更大嫌疑这个镜像并不是用 ST-LINK 整片烧写的而是通过 bootloader 自己的 UART YModem 流程一包一包写入第二区 flash 的。我在写 flash 时做了完整的 8 字节对齐、页擦除、双字编程CRC 也校验通过但问题恰恰出在“CRC 校验通过”上。STM32H5 这类 flashECC 校验位是由硬件在双字/字写入时自动计算的。如果你写入的数据长度不是 flash 写入要求的最小单位或者中间有一次写入没有按边界对齐硬件会把这次写入自动截断、合并或者填充导致最后 flash 里的“数据内容”是连续的但“ECC 校验位”和它并不对应同一个物理行。CRC 只能验证数据内容的一致不能验证 ECC 元数据本身是否正确。检查方法很简单把故障地址所在的 flash 行读出来和工程里生成的 bin 文件对应偏移逐字节对比。如果内容一致但一读就 ECC 报错而且这个区域不是从复位向量开始的那基本可以确定是写 flash 时靠 fill/对齐产生的 ECC 元数据错位。当 flash 写入逻辑不能严格按“8 字节或者 16 字节整块写入”的时候就会留下这种“看不见的坏块”。第一次从 bootloader 跳过去使用它时如果恰好访问到那些区域就会随机 NMI。3.5 第五步TrustZone/安全状态导致的隐蔽 NMI还有一个绕不开的坑STM32H503 是支持 TrustZone 的如果你的 bootloader 是安全状态下跑的而 app 是非安全状态那跳转时对 GTZC、SAU 安全属性的切换就非常关键。跳转后 app 如果访问了被标记为“安全访问”的 flash 区域但代码本身运行在“非安全状态”CPU 会触发安全异常严重时也会被当成 NMI 处理。这种场景的排查特征是进入 NMI 前程序往往刚访问某个全局变量或者 flash 常量但你把地址换成 RAM 里的备份后死机概率立刻下降。处理办法是bootloader 跳转前显式调用TZ_SAU_Update或者参考 STM32Cube 里Secure/NonSecure工程模板把 flash/RAM 的安全属性切到 app 预期状态不要把安全中断和非安全中断混着使能跳转前把安全 NVIC 也清一遍确认SEC_MPU或者 GTZC 的访问策略没有挡住 app 需要访问的外设区域。在纯 bootloader app 的裸机工程里很多人会忽略 TrustZone 相关初始化。但如果你的工程是从 STM32CubeMX 生成的并且勾选了 TrustZone这一条必须纳入排查范围。4. 常见问题与排查速查以及我给自己的几条规定4.1 症状速查表一张表覆盖大多数随机 NMI 情况下面这张表是我这次排障过程中整理出来的也是我后来给团队内部用的速查表。现象主要怀疑方向先检查什么跳转后很快进入 NMIPC 停在 app 前几条指令向量表 VTOR 没切、MSP 不对、app 链接地址与跳转地址不一致读SCB-VTOR、打开反汇编看复位向量是否跳到了预期地址运行几百 ms 后随机 NMI地址指向某个常量区flash 数据区 ECC 元数据不对或 Cache 命中旧数据读FLASH-ECCR故障地址对比 bin 文件该偏移内容开优化等级后稳定复现编译器调整了布局落到坏 ECC 区域对 app 区域做全量 ECC 检查必要时重新整片烧写只有脱机运行复现接调试器不复现电源/时序/等待状态问题增加复位延时检查 VOS 电压等级和 flash 等待周期跳转后第一次访问外设即 NMI外设中断残留在 bootloader 中或者外设时钟未重新配置清空 NVIC、HAL_RCC_DeInit、进入 app 后重新初始化所有外设跳转后访问全局变量即 NMITrustZone 安全属性不匹配检查 SAU/GTZC 对 RAM/flash 区间的安全标记NMI 现场里FLASH-ECCR和CFSR都无有效标志问题可能不是 flash ECC而是电源监控/NMI 引脚查看 EXTICR、电源控制寄存器外部 NMI 引脚是否被拉低4.2 值得保留的几条经验第一跳转代码尽量放到 RAM 里执行。虽然 H503 的 flash 在跳转时通常没有正在执行的写操作但把跳转函数放到 RAM 里可以彻底排除“跳转过程本身访问 flash 触发读取异常”的可能。实现不复杂在链接脚本里划出一小块 RAM 区域把跳转函数放到那边即可。第二生产自检里一定要加 ECC 扫描。 bootloader 里可以做一次后台扫描循环读取 app 区所有地址当 ECC 错误被纠错或者被检测到时记录下来。即使这次随机问题是跳转代码没写干净排查层面也可以靠这种扫描提前发现坏数据区域。第三OTA 后不要只做 CRC再做一次全量读回比对。特别是用自定义通信协议升级时尽量在写入 flash 后把每个 8 字节块再读一次确认硬件写入产生的数据和 bin 完全一致。如果发现不一致优先检查写入长度必须是 flash 编程宽度的整数倍地址也必须按编程宽度对齐。第四把跳转函数里每一步都用__DSB()和__ISB()隔离。不要省这两条指令它们不是“只对 Cortex-A 有用”在 Cortex-M33 上同样影响指令流水线和存储访问顺序。少写一条__ISB()就可能让 VTOR 或 MSP 设置还没有生效的时候app 复位向量就已经被预取出来了。4.3 这个问题的后续扩展思路后来我把这个 bootloader 的跳转流程又做了一层加固每次跳转前先从 bootloader 端读一次 app 的向量表前 8 个 word逐个检查是不是可执行地址并做一次 flash ECC 感知检查。如果发现 ECC 事件就阻止跳转要求重新下载固件。这个逻辑看上去多花了几百毫秒但在量产现场非常有用能避免大量“随机死机返修”的麻烦。还能把 ECC 错误计数的监控放到 app 的周期性任务里定时读取 flash 控制器的 ECC 错误标志并累计。一旦发现某块地址反复出现 ECC 错误哪怕只是单错纠正也可以及时上报业务层。通过这种方式很多潜在的 flash 老化问题都能在彻底死机之前暴露出来。写在最后这次排查给我最大的体会是STML32H503 的随机 ECC/NMI十有八九不是“芯片坏了”而是“跳转前后状态没有对齐”和“flash 数据区域本身存在 ECC 元数据不一致”的叠加。NMI_Handler 里看到 ECC 标志的那一刻要做的不是急着去清标志而是把故障地址、上下文寄存器、时钟状态全部留下来再回头看 bootloader 是怎么跳的固件又是怎么写进去的。如果你也在做类似的 H5 系列 bootloader我建议先把跳转函数做成一个独立模块严格清理中断、时钟、缓存、VTOR再在 app 区写入流程里加上边界检查和读回对比。把这两件事都做干净后这个看起来像随机故障的问题其实是可以稳定消除的。
