Hubris嵌入式系统SP更新失败问题分析与解决方案

问题现象

在Hubris嵌入式系统的实际部署中，特别是在colo和dogfood环境中，系统平台(SP)在更新至R11版本时出现了间歇性的更新失败问题。故障表现为更新过程中返回错误代码7，对应UpdateError::ReadProtErr错误类型。

通过分析系统日志和Hubris内存转储数据，可以观察到更新过程在EraseEnd阶段后停滞不前。系统内存转储显示，FLASH_SR2寄存器中的RDPERR位被意外置位，导致闪存操作失败。

技术背景

该问题涉及STM32H7系列微控制器的闪存子系统特性。该系列芯片采用双bank闪存架构，具有以下关键特性：

1. 闪存状态寄存器分为FLASH_SR1和FLASH_SR2，具体使用哪个寄存器取决于bank交换模式
2. 专有代码读取保护(RDP)功能会在读取受保护区域时设置错误标志而不触发总线错误
3. Cortex-M7内核具有指令预取机制，可能对系统内存区域进行推测性访问

问题根源分析

经过深入调查，发现问题根源在于Cortex-M7内核的指令预取单元行为。该单元会对系统内存区域(0x1FF00000-0x1FF7FFFF)进行推测性指令获取，而这一区域由闪存控制器解码。当发生此类访问时，闪存控制器会设置RDSERR标志表示异常。

在Hubris系统中，我们观察到的是RDPERR而非RDSERR标志被置位，但两者可能具有相似的根源。值得注意的是：

1. 系统并未主动启用读取保护功能
2. 错误仅间歇性出现，表明与运行时条件相关
3. 长时间运行的系统更容易出现此问题

验证实验

为验证问题假设，我们进行了以下实验：

1. 通过humility工具直接读取系统闪存区域(0x1FF02000)，观察到FLASH_SR2寄存器中的RDSERRIE位被置位
2. 在bank交换模式下，相同的操作会置位FLASH_SR1寄存器中的标志位
3. 发现Hubris原有的闪存状态检查逻辑存在缺陷，总是检查FLASH_SR2而忽略了bank交换情况

我们还发现：

1. 简单的电源循环(ignition)不能可靠清除错误标志
2. 组件重置(component-reset)能够可靠清除错误状态
3. 在部分设备上观察到不同的错误代码(如代码6)

解决方案

基于问题分析，我们确定了两种解决路径：

1. 临时解决方案：通过组件重置清除错误状态后重试更新
2. 根本解决方案：修改内存保护单元(MPU)配置，阻止对系统内存区域的推测性访问

最终采用了第二种方案，通过配置MPU将系统内存区域标记为Execute-Never，有效阻止了Cortex-M7内核对该区域的推测性访问。这一修改已通过PR#1905合并到主分支。

技术启示

该案例提供了几个重要的嵌入式系统开发经验：

1. 现代微控制器架构的复杂行为(如推测执行)可能引发非预期的硬件交互
2. 长时间运行的系统可能表现出与冷启动测试不同的行为特征
3. 硬件文档中未明确说明的特性可能对系统稳定性产生重大影响
4. 内存保护单元的正确配置对于系统可靠性至关重要

此问题的解决不仅修复了SP更新失败的问题，也为处理类似硬件特性引发的边缘情况提供了参考模式。