[参考译文] 了解活锁函数的差异。

您好 Arriy、

 CPU 内部只有一个硬错误高速缓存。 此硬错误高速缓存用于闪存(位于 ATCM 接口上)和 SRAM (位于 BTCM 接口上)。 安全手册中单独提到了它们、但实际上只使用了一个硬错误高速缓存。

1) 1) Cortex-R4处理器尝试通过将校正后的数据写回 TCM 并重试访问来校正 TCM 中的1位错误。 如果1位错误是由硬故障引起的、那么这样做不会改变从 TCM 读取的数据、 当重新尝试访问时、将再次检测到相同的错误、处理器将锁定、永久检测错误并重试、而不会取得任何进展。

硬错误高速缓存的目的是防止 CPU 读取具有永久性单位错误的 SRAM 或闪存。 假设其中一个内存单元中存在缺陷。 如果您从它读取数据、CPU 将检测到它为一个单位 ECC 错误。 CPU 将尝试将校正后的数据保存到硬错误高速缓存中、并将校正后的数据写回 SRAM 或闪存、然后重试。 下一次如果 CPU 从同一错误地址读取、那么它只是从缓存读取、而不是从 SRAM 或闪存读取、因为地址中存在匹配。 您可以使用 RAMTHRESHOLD 寄存器设置单个位阈值出现。 同样、闪存的 FEDACCTRL2寄存器用于设置发生阈值。

2) 2)当活锁发生在闪存或 SRAM 时、行为没有差异。

您好、Charles。
感谢你的答复。

我想对这两种安全机制执行故障注入测试。
如果执行了故障插入测试并发生了带电锁定，您是否执行了(闪存/SRAM)故障插入测试？

如果您知道 FLA 和 SRAM 中的不同活锁生成方法、请告诉我。

您好 Arriy、
请查看此帖子 e2e.ti.com/.../549321。

您可以从 FLA 或 SRAM 创建活锁。

您好 Charles
感谢您的支持。

您说活锁可以创建低于项目吗？
Dave 的"SPNU511_7-41_Livelock_Test.zip"。

Livelock 是通过执行该项目而实现的。
它是否满足 FLA 和 SRAM 的活锁故障注入测试？

此致

您好 Charles。

我知道你很忙、但我正在等待建议。

此致

您好 Arriy、
由于某种原因、当我单击链接时、无法找到 Dave Livingston 回答的帖子。 下面是另一个讨论生成活锁错误的链接。 e2e.ti.com/.../549321。我有新的任务、不再支持 Hercules 论坛。 由此给您带来的不便、我们深表歉意。

您好 Arriy、

正如 Charles 提到的、他不再支持 Hercules 论坛问题、但如果您对此主题有任何其他问题、请继续发帖、我将向您解答。 请查看他提供的新链接、如果您有任何问题、请告知我。 对于 RAM 与闪存 LiveLock、它们是两个独立的操作、需要2个独立的软件功能测试。

你好、Chuck

感谢您的回答。

我知道 SRAM /闪存的活锁需要2个独立的功能性软件测试。

我可以实现 SRAM 的活锁。 但是、我无法想象   实现闪存活锁的方法。

请告诉我如何发生闪存活锁？

你给了我这个链接，但是我不知道我想要知道什么。

Charles 给了我一个链接，但是    我在链接中看不到 ARM ALT 用户指南。 "抱歉！ 我们找不到您的页面。" 将会指示。

此致

Arriy、

链接指向可从此处下载当前版本的文档的旧版本：

• ARM 优化 C/C++编译器用户指南 tidoc：spnu151
• ARM 汇编语言工具用户指南 tidoc：spnu118

或在此处访问在线版本：

• downloads.ti.com/.../index.html
• downloads.ti.com/.../index.html

此致、
Christian

您好 Christian
感谢您的支持。
我看到了链接


>我知道 SRAM /闪存的活锁需要2个独立的功能性软件测试。
>我可以实现 SRAM 的活锁。 但是、我无法想象实现闪存活锁的方法。
>请告诉我如何发生闪存活锁？
请就上述问题向我提供建议。

此致

您好 Christian。

您说"鉴于这一点、您没有理由为闪存和 SRAM 实施不同的故障注入测试、因为 CPU 不关心活锁源(故障)。" 另一个线程中。(e2e.ti.com/.../2138472

但您还说过需要在该线程中进行单独的测试。 我很困惑...

您在另一个线程中说过、活锁函数是 CPU 流水线、在这种情况下、我认为无需单独的故障插入测试。
我认为只执行一个能够确认 ESM 通知的测试就足够了。

是单独的测试还是唯一正确的测试？

此致

卡盘 Davenport
您能否评论一下您认为需要两种不同的测试的原因：
"关于 RAM 与闪存 LiveLock、它们是两个独立的操作、需要2个独立的软件功能测试。"
也许我错过了一些东西、我的结论是错误的。

我知道、可能导致活锁事件(错误)的原因(故障)有多种：

单个未对齐的32位 Thumb2指令中存在两个单一位错误
加载指令中的单个位错误加上"有效载荷"中的单个位错误
UNDEF 矢量上的未定义指令

根据此逻辑、您需要至少3次活锁测试、甚至更好13次：ATCM、B0TCM、B1TCM、B0TCM+B1TCM、ATCM + B0TCM、 ATCM + B1TCM ...

但是、活锁检测机制在 CPU 流水线上仍然有效、并且与故障源无关。 它也与硬错误缓存(我从上一个帖子中删除了引用)无关、也与未定义的指令无关。 这些仅是可能导致活锁状态(错误)或同时工作的其他机制(硬错误高速缓存)的条件(故障)。
我认为、如果 CPU 内核被配置为排除硬错误缓存、条件将保持不变。 实际上、您无法针对未定义指令条件执行测试、因为这需要更改存储器内容、而且使用 POM 也不是一个选项。

我认为、从 CPU 活锁检测机制的角度来看、实施其中一项测试应该足够了。
但是、如果您从系统的角度来看、您可能需要检查每个会导致活锁的条件、那么您可能需要执行更多的测试。 一种方法是自上而下、另一种方法是自下而上。

最后、由您决定如何处理这一问题、我给出的解释只是一个提示、说明您可以如何争辩。 另请考虑在 ARM Cortex-R4F (r1p3C) TRM 中阅读有关此功能的信息、您可以在其中(从 ARM)直接找到此信息。

我认为您的问题"是单独测试还是唯一正确的测试？"没有正确、错误或是的答案。 很遗憾。

此致、
Christian

Christian、

我同意您对硬错误缓存和活锁机制的总体评估、我认为我们单独在闪存和 RAM 元素中包含测试的原因是我们单独考虑了每个元素。 在许多情况下、元件之间的安全机制存在重叠；例如、带有错误测试的功能软件测试和错误路径的软件测试可通过器件中大多数需要它们的模块/元件的共享测试实现。  

在这种情况下、我同意硬件本身对于硬错误高速缓存是通用的、具有要使用的硬件的多个原因条件。 您可以考虑进行100%测试、您应该测试故障机制的每个不同原因(包括 TCM 和闪存 TCM) 或者、如果考虑安全分析的分辨率、将 RAM 和闪存视为单独的元件、则意味着2种测试类型、或者从对 CPU 的理解来看、只有一种测试是可以的。

我的具体想法是、测试每个 RAM TCM 和 ATCM 将测试每个错误路径。 但是、我认为如果我们考虑存在重叠的机制、只能执行 RAM TCM 测试、因为其他机制会捕获未定义指令或闪存活锁的其他原因。 当然、如果我们查看 FMEDA、我们将看到该机制不是负责满足诊断覆盖率指标的主要诊断、

我建议将 RAM 硬错误缓存和活锁以及闪存硬错误缓存和活锁处理都包含在同一个 ISR/错误处理程序中、因为我认为这两个处理都将以类似的方式进行处理。 这样、至少 ISR 实例化测试可作为诊断测试和验证/验证工作的一部分来执行。