[参考译文] LAUNCHXL-F2800157：参考设计请求 — 双映像/闪存标志/固件验证 (TMS320F2800157)

您好 Matt、

感谢您的解释。

我知道 F280015x 是一款单闪存组器件、完全支持双映像很困难。 我将介绍您提到的闪存内核和 LFU 示例。

但是、我仍然希望使固件更新 具有失效防护功能、尤其是在出现电源故障的情况下。

我有几个澄清:

1. 由于无法完全实现双映像、 建议的安全方法是什么？

   • 我们应该使用：
     • 闪存标志（正在更新/有效映像）？
     • 跳转到应用程序之前进行 CRC 验证？

2. 要将标志存储在闪存中：

   • 是否有任何推荐的结构？
   • 我们是否应该使用单独的闪存扇区？

3. 对于固件验证：

   • 更适合生产：
     • VCU CRC 示例
     • 由链接器生成的 CRC

4. 如果固件损坏：

   • 我们是否应该始终依赖 ROM 引导模式（SCI 引导） 进行恢复？
   • 还是有更好的方法？

我的目标是构建一个 能够在断电后安全恢复的强大固件更新系统。

请针对此器件提供建议的最佳方法。

此致、
Kamarudheen MD

您好 Matt、

感谢您的详细答复、并向我指出 LFU 示例、CRC 资源和推荐的多层恢复策略。 有关使用 状态标志+ CRC 验证+ ROM 引导回退的说明 非常有用。

根据您的建议、我将继续使用以下架构：

• 元数据专用闪存扇区 (STATUS 标志+ CRC)
• 由链接器生成的 CRC +运行时 CRC 验证
• ROM SCI 引导加载程序回退 以进行恢复
• 使用 闪存内核（来自 C2000Ware） 进行编程

额外说明：自定义引导加载程序+基于 GPIO 的恢复

除了上述内容外、我还计划将 小型定制引导加载程序 与基于 GPIO 的引导切换方法（类似于 SPRACN1）集成到闪存中、我希望您对这种组合方法有所意见。

建议的增强功能

1. 复位时（闪存引导）：

   • 自定义引导加载程序首先执行
   • 读取：
     • 闪存状态标志（更新状态）
     • CRC 验证结果

2. 引导决策：

   •  如果固件有效→跳转到应用程序
   •  如果固件无效或标志指示“正在更新“：
     • 将 引导 GPIO（例如 GPIO15）驱动为高电平
     • 触发 软件复位
     • 器件进入 ROM SCI 引导模式

3. SCI 编程阶段：

   • 闪存内核执行
   • 更新的元数据扇区：
     • 设置“Update in progress“
     • 对新映像进行编程
     • 更新 CRC
     • 设置“更新完成“

4. 恢复行为（电源故障情况）：

   • 如果发生中断：
     • 标志保持为“进行中“或 CRC 不匹配
     • 引导加载程序在下一次复位时检测到故障
     • 再次强制 SCI 引导（通过 GPIO + RESET）

问题

1. 架构验证

   • 是否为以下组合：
     • 闪存引导加载程序（用于验证+决策）
     • 基于 GPIO 的引导切换（强制使用 ROM 引导加载程序）
     F2800157 的推荐安全方法？

2. 基于 GPIO 的引导覆盖

   • 是否认为通过 GPIO（如 SPRACN1 所示）主动强制 SCI 引导对于生产系统是可靠的、而不是仅依赖于 ROM 回退？

3. 引导加载程序位置安全

   • 由于此自定义引导加载程序驻留在闪存（同一组）中：
     • 应采取哪些预防措施来 防止闪存擦除/写入过程中损坏？
     • 建议：
       • 将其放在单独的扇区中、永远不会擦除？
       • 使用任何硬件/软件保护机制？

4. 故障边缘情况

   • 在最坏的情况下、
     • 引导加载程序本身已损坏
   • 我假设 ROM 引导加载程序是唯一的恢复路径。
   • 这种理解是否正确、是否有其他建议来处理此场景？

目标

我的目标是构建一个 失效防护固件更新系统 、该系统能够：

• 检测损坏或不完整的固件
• 使用 SCI 引导自动恢复
• 安全处理电源故障
• 尽管受到单组闪存的限制、但仍可更大限度地降低风险

再次感谢您的支持和指导。

此致、
Kamarudheen MD