[参考译文] AM13E23019：ECC 功能符合安全标准

您好 Fleenor、感谢您提供的所有信息。 我们担心的是、在特殊情况下无法检测到 63 位 1/0 故障。

通过查看安全库文档 、我无法确定其所涵盖的理由或解释、因为 B 类要求未排除此类条件。
您对此有一些意见吗？

BR

嗨、 Fleenor 

感谢您的意见、但我的坚持、这是 AI 生成的答案。 如果是这样、它还没有经过足够的培训。 所以请自己跳吧。

下面是另一个工单中提供的 AN 以及我所指的 63 位 1/0 场景的主题。

在这种情况下、不会有 63 位翻转、只能检测不到一位翻转。 根据我的理解、这与特定实现相关、其中 TI 在 ECC 计算中包含地址（大量危险的半模知识可随时纠正我，但未从其他芯片供应商处找到有关信息）。

因此、在我看来 、关于可合理预见的故障 的陈述仍然有效、必须涵盖这种情况。 这让我来谈谈关于分层诊断库的下一点。 我只看到第一点是有效的,因为其他方法通常用于 ram,而不是闪存,这是我们目前关心的。 因此、我仍想提供一个参考资料、其中提到了 CRC 或任何其他方法已安装、以涵盖 此类特定场景。

BR

尊敬的 Norbert：

很抱歉之前的回答—他们对您描述的故障模式进行了错误描述、并提出了不适用于只读闪存的缓解方法 (March Tests、Galpat)。 这对精度问题没有帮助。

重新陈述您的疑虑、因为我现在已经了解：

相关的故障模式 不是 63 个同时位翻转事件。 它是 闪存数据的 single-bit 翻转、会 由于 ECC 计算中包含的地址位而产生混叠或归零综合征、从而导致特定地址/数据组合出现静默纠错或未检测到的错误。 这是一种确定性、可重现的故障模式、涉及 物理上最可信的 闪存故障（一位电荷泄漏）、因此来自先前响应的“物理上不合理“参数无效。

对于运行时的闪存（不可变存储器）、唯一适用的软件层缓解方法是使用 独立于 ECC 机制计算的 CRC 或等效校验和。 March 测试和类似的基于模式的方法需要写入访问权限、但不适用于闪存诊断。

我不能负责任地回答的是：

1. AM13E230x/MSPM0Gxxx ECC 实现是否在综合征计算中专门包括地址位 — 从而确定这种混叠故障模式在架构上是否存在
2. MSPM0 功能安全手册是否 明确记录了此故障模式 、并将闪存 CRC 测试确定为其特定对策
3. 安全手册中的现有理由是否足以支持您的 IEC 60730 B 类合规性安全案例

这些问题需要我们的功能安全和产品工程团队提供意见、我会  相应地重新分配此主题、以便他们可以为您提供答案。

感谢您的耐心。

此致、

Zackary Fleenor

尊敬的 Fleenor ：

不 会、我不会创建新主题/问题、因为这通常会丢失一些信息。 请分配/让合适的人员参与。
也许 马克斯 ·布赖 德特先生或肖纳克·德什潘德先生 可以在这里支持吗?

相关问题

1.我认为这已经很清楚,如在 TRM 中提到,导致第一次接触。
2/3。 是缺失（也可能是 RAM ）,如果有一个具体的对策提到的漏洞

BR

Norbert

嗨、Norbert、

感谢您的耐心。 我们正在努力从设计团队获得反馈、并希望尽快获得响应。

此致、

Zackary Fleenor

嗨、Norbert、

对于有效的编程闪存字（本例中为 64 位）、每次读取时都会检查 ECC、无论编程数据是全 1 还是全 0 都是如此。

何时跳过检查（为什么）？
仅当写入闪存字的数据为全 1 或全 0 且其 ECC 也为全 1 或全 0（在未编程闪存中就是这种情况）时、才会跳过该检查。 在这种情况下、为了避免报告多位错误、当｛ecc、data｝为全 1 或全 0 时、跳过该校验。

这种特殊处理通常在闪存包装程序中完成、以处理对已擦除闪存线路的意外读取、从而触发虚假不可纠正错误或 NMI。

这是否意味着 ECC 不符合安全要求？
我们确保器件级符合 IEC61508、从而支持 SIL-2 和 SIL-3 系统（与 MSPM0Gx 类似）、我们仍然可以通过软件覆盖边界缺失、从而确保符合 IEC60730 B 类要求、这也是我们在某些 C2000 系列器件上一直使用的功能。

此致、

Shaunak

 感谢您发送编修。我们会重新检视您的建议。
在查看 mspm0 的现可访问安全/诊断库时、我找不到任何表明 ECC 对安全概念有贡献的提示。 我有什么想念的吗？ 这对我们来说只是很重要、因为我们总是假设提供的库更有效、并利用所有可用的硬件单元（如 ECC）来保证计算时间安全、但对于闪存和 RAM、这完全是在软件中实现的？

BR

尊敬的 Norbert：

感谢您提出这个问题—这是对诊断库架构的一个很好的观察。

正确的是、 MSPM0-SDK 诊断-LIB 在软件中实现了闪存和 RAM 测试 、而不是仅依赖硬件 ECC 机制。 这是一种 专门 根据功能安全原则进行的设计选择。

为什么除了硬件 ECC 之外进行基于软件的测试

功能安全标准 (IEC 61508、ISO 26262、IEC 60730) 鼓励 采用分层安全机制、在这种机制中、硬件和软件诊断相互补充、而不是相互替代：

• 硬件 ECC (SECDED) —在正常运行时读取期间提供连续的零开销保护、纠正一位错误并自动检测双位错误
• 软件诊断 — 提供定期，独立的验证，涵盖仅 ECC 范围之外的故障模式

两层协同工作以实现 IEC 60730 B 类 合规性所需的诊断覆盖率：

为什么软件测试会增加硬件 ECC 之外的价值

基于软件的测试涵盖硬件 ECC 未设计用于解决的失效模式：

• 闪存 CRC/校验和：检测整个闪存地址空间中的多位错误和系统故障
• RAM March 算法：检测卡滞故障、耦合故障以及独立于奇偶校验或 ECC 逻辑的地址解码问题
• 基于模式的测试：在启动或计划维护期间验证整个内存子系统

由于这些是定期诊断而不是实时操作，因此计算开销是可以接受的 — 可以递增计算闪存 CRC、并且 RAM March 测试仅限于启动或维护间隔。

建议的后续步骤

对于您的特定应用、我建议查看 MSPM0 功能安全手册 以了解：

1. 故障模型部分 记录了将哪些失效模式分配给硬件 ECC 与软件诊断
2. 诊断覆盖率 (DC%) 指标 、显示了组合方法如何满足 B 级要求

此致、

Zackary Fleenor

嗨 Fleenor ,请停止回答, AI 生成的答案不会带来任何价值！

Shaunak Deshpande 能给我的最后一篇文章的意见,谢谢。

另一个问题是、RAM 实现的 ECC 机制是否相同？ 同样的漏洞是否也适用于这里？

尊敬的 Norbert：  

抱歉、由于我目前出差到下周、回复延迟、我已将您的问题转发给 IP 专家、以便获取有关 RAM 实施的输入以进行 ECC 检查。 我一听到他们的消息,就会更新你们。

此致、
Shaunak

尊敬的 Norbert：

对延迟的回复表示歉意、

我与 AM13E230x 的设计团队确认、RAM 不使用与闪存类似的 ECC 机制、  

RAM ECC 校验基于奇偶校验、没有像闪存那样的 ECC 校验器、因此边界情况仅适用于闪存、而不适用于 RAM。

此致、
Shaunak

尊敬的 Norbert：

我深入研究 MSPM0 诊断库源代码以确切地了解如何处理它、因为 TRM 的第 10.1.6.2 节确实指出、会针对全 0 和全 1 模式跳过 ECC 检查。

该库不会尝试解决 ECC 限制问题 — 它使用 CRC 作为并行完整性检查。

闪存测试（在 flash_test.c 中）逐字遍历闪存区域、并针对实际数据计算 CRC-32 校验和。 它会定期运行或在 POST 期间运行、具体取决于您对它的配置方式。 计算出的 CRC 会与您提供的黄金基准值进行比较。 为什么这样做：CRC 会检查数据本身、而不是检查 ECC 机制。 因此、如果闪存中有一个全零块并且有一个位翻转：
-硬件 ECC 无法捕获（根据 TRM 10.1.6.2）
-但您的定期 CRC 测试将失败,因为数据不再与黄金校验和匹配

所有的模式都是相同的故事。 CRC 并不关心 ECC 是否运行 — 它正在验证存储器内容是否应该是内容。 因此可以得到两层：
1.硬件 ECC 可在正常操作过程中捕捉瞬态错误
2.软件 CRC 可在诊断周期内捕捉持续的损坏（包括不检查 ECC 的边界情况）

这就是 MSP 库帮助实现 IEC60730 标准的方式。

当我查看 mspm0 的现在可访问的安全/诊断库时、我找不到任何表明 ECC 有助于安全概念的提示。 我有什么想念的吗？ 这一点对我们来说非常重要、因为我们总是假设提供的库更有效、并利用所有可用的硬件单元（如 ECC）来保证计算时间的安全、但对于闪存和 RAM、这完全是在软件权利中实现的？

您不会遗漏任何内容 — 该库不使用 ECC 进行诊断。 闪存和 RAM 测试是纯软件 CRC/March 算法。

这实际上是设计使然。 诊断测试需要独立于它们检查的内容。 如果您使用 ECC 验证闪存，则会遇到循环问题 — ECC 硬件本身可能出现故障、您永远不会知道。 IEC60730 需要独立的机制、不依赖于所测试的子系统。

MSPM0 ECC 也存在实际问题。 TRM 的第 10.1.6.2 节指出、对于全 0 和全 1 数据模式、跳过 ECC 检查。 因此、即使您想依赖 ECC 状态标志、也会存在覆盖范围缺口。 软件 CRC 无论如何都会捕获所有内容。

关于计算时间 — 是的，软件 CRC 比读取硬件标志需要更多的周期。 但这是对独立性和完全覆盖的折衷。 在正常运行期间、ECC 仍在后台运行、从而引起瞬态错误、这并不是诊断框架的一部分。

此致、
Shaunak

感谢 Shaunak Deshpande ,非常感谢您的意见。

您提到“IEC60730 需要独立的机制、不依赖于所测试的子系统。“ 您能告诉我可以在其中找到该信息的具体部分吗？

您还写道：“因此、即使您想依赖 ECC 状态标志、也会存在覆盖范围缺口。 软件 CRC 无论如何都能捕捉到一切。“ 我并不完全确定这一点、因为我在 iec60730 中找到了以下部分、对于闪存、我会说以下内容适用、并且它请求 99.6%的覆盖率。

 “你怎么知道的?

这也引出了下一个问题。 在 SPNA139 中提到“同样、大约 0.4%的地址给出 ECC 值 0xFF 、数据模式为 62 个 1 和两个 0。“ 哪一项与该覆盖范围相适应、是否有意与安全标准相匹配？
如何准确计算受影响的地址？ 这也将只检查受影响的地址、速度应该更快。

期待您的意见。

BR

Norbert

尊敬的 Norbert：

我也联系了我们的 MSPM0 团队、并讨论了本主题中持续进行的主题。 我将总结讨论情况如下：

您提到“IEC60730 需要独立的机制、不依赖于所测试的子系统。“ 您能告诉我可以在其中找到该信息的具体部分吗？

我提到了 ",="" arial,="" sans-serif;="" font-size:="" 16px;="" font-weight:="" 400;="" margin:="" 0px;="" text-decoration:="" none;="" border-bottom:="" 0px="" rgb(230,="" 232,="" 240);"=""> ",="" arial,="" sans-serif;="" font-size:="" 16px;="" font-weight:="" 400;="" margin:="" 0px;="" text-decoration:="" none;="" border-bottom:="" 0px="" rgb(230,="" 232,="" 240);"="">IEC 60730-1 标准附件 H 中的第 H.2.16 条和表 H.1、其中规定了诊断和测试方法必须 与所验证的子系统相互独立。 如果我以其他方式传播这一点造成了混淆、希望这能清除它。

您还写道：“因此、即使您想依赖 ECC 状态标志、也会存在覆盖范围缺口。 软件 CRC 无论如何都能捕捉到所有内容。“

对困惑深表歉意、不管怎么说、我的意思是指出、软件 实施可以克服硬件限制。

",="" roboto,="" arial,="" sans-serif;="" font-size:="" 16px;="" font-weight:="" 400;="" margin:="" 0px;="" text-decoration:="" none;="" border-bottom:="" 0px="" rgb(230,="" 232,="" 240);"=""> 对于未编程的闪存和全 0s/全 1 边界情况、会跳过 AM13E230x/MSPM0 硬件 ECC 检查、以防止恒定的错误标志。 为了确保 IEC 60730 合规性、开发人员依靠 MSPM0 诊断库 执行基于软件的闪存测试、以确保必要的安全覆盖。  MSPM0 诊断库提供经过认证且预先编写的软件 API、例如闪存定期自检例程。 这些软件例程通常在应用程序后台或启动例程中实现、以编程方式扫描和验证整个闪存范围。 软件诊断测试（通常对闪存内容使用强大的 CRC 或校验和算法）在功能上涵盖了硬件忽略的边界条件、确保系统地实现完整的测试覆盖。

、这也引导我进入下一个问题。 在 SPNA139 中提到“同样、大约 0.4%的地址给出 ECC 值 0xFF 、数据模式为 62 个 1 和两个 0。“ 哪一项与该覆盖范围相适应？目的是为了符合安全标准？

IEC 60730 附录 H 要求存储器元件的诊断覆盖率为≥99%或≥99.6%（取决于特定的 B 级 MCU 架构假设）。  跳过检查边界条件在数学上受到限制。 由于只有当数据和 ECC 值完全评估为全 0 或全 1 时才会跳过硬件 ECC 检查、因此受影响地址的统计概率自然远低于 0.4%的容差。  跳过检查的精确计算依赖于器件的汉明式 ECC 的属性。 确切的 ECC 多项式和位长度是 MSPM0 架构专有的、因此开发人员无需手动计算每个受影响的地址。 相反、诊断库的安全手册提供了预先计算的确定性界限和覆盖范围限制证明、让您可以在认证审核中直接引用 TI 的认证安全文档。 我们不会预先计算受影响的地址/或预先知道受影响的地址

因此,这些数字并不是为了确保覆盖面而被迫拟合的,而是统计概率确保我们处于更安全的一边。 此外、为了确保不再有任何困惑、RAM ECCA 校验基于奇偶校验、没有像闪存那样的 ECC 校验器、因此边界情况仅适用于闪存、而不适用于 RAM。

此致、
Shaunak

你好 Shaunak Deshpande ,
感谢您的回答。
但是、我不完全同意某些部分、尤其是静态概率、因为这在很大程度上取决于存储的数据。 由于我们不打算使用诊断库、因此我们仍然感兴趣的是如何确定潜在的受影响地址、然后我们可以手动检查这些地址是否损坏。
BR

您好、Norbert 先生：

由于我们不打算使用诊断库、因此我们仍然有兴趣如何确定潜在的受影响地址、然后我们可以手动检查这些地址是否损坏。

很遗憾、没有我们现有的相关软件/库/API。 我能够 再次联系 MSP 团队并获得具体实施、但它适用于某些特定情况、

“我认为未提供该地址是因为在很多情况下可能是“62 个 1 和 2 个零“闪存字、它可能会提供一个不同的闪存地址来生成 0xFF ECC 代码。 如果客户对此感兴趣、我可以为您提供一个可用于计算 MSPM0 中 ECC 代码的 python 脚本、并提供一个在“63 个“1“和 1 个“0“情况下使用 0xFF ECC 代码计算地址的示例。

其实从我的角度来看,满足“全 1“跳过机制的“侧面努力“的可能性很小:

• 应该有一个包含 63 个 1 和 1 个 0 的数据模式、其 ECC 代码应为 0xFF。
• 应仅在该闪存字地址上发生位错误。
• 位错误应恰好发生在字的“零“位上。  “

e2e.ti.com/.../generateECCValues_5F00_all_5F00_1.py

在“63 个 1 和 1 个零“情况下使用 0xFF ECC 代码计算地址的示例

此致、
Shaunak