[参考译文] TMS570LC4357-TMS570：EP 代码错误处理和校正机制阐释

尊敬的 Hanson：

Unknown 说：

如果 ECC 代码本身发生一位错误(相对于数据)、SECDED 机制如何在错误检测和纠正两方面处理此问题？

SECDED 模块 也能够检测 ECC 代码中的 single-bit 错误。

请验证故障表格中突出显示的以下数据：

例如、如果 ECC 位4损坏、则生成的综合征将变为0b00010000、因此可以基于此检测 ECC 第4位中的 single-bit 错误并进行位校正。

Unknown 说：

从更正的角度来看、是否存在基于错误 ECC 代码错误纠正数据而不更改 ECC 代码的机制的风险？ 这是我的申请中的一个主要问题

不,不会有任何风险的配重机制。

Unknown 说：

如果可能出现这种情况(即由于错误的 ECC 代码而对数据进行错误更正)、是否有任何策略或机制可用于增强 ECC 代码本身的可靠性？

不会、会发生这种情况。

不会为 ECC 代码提供任何冗余存储、如前所述、 该器件也可以对存储的 ECC 代码执行 single-bit 纠错和 double-bit 错误检测。

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：

感谢您的答复。

我想确认一下我对 ECC 代码中一位错误的理解。

您提到如果 ECC bit-4中发生一个单位错误,综合征将是0b00010000. 我知道、将接收到的 ECC 代码与重新计算的 ECC 代码进行比较时、会在 ECC 验证过程中产生该综合征。 例如、IF 数据位26 有一个单位错误、生成的综合征将是0b11100110、允许系统检测并纠正此错误。

能否请您确认我的理解是否正确？

此致、
汉森

此外、我目前尝试特意在中注入 ECC 错误 高速缓存区域 用于测试目的。 对于如何实现这一目标、您有什么见解或建议吗？

Unknown 说：

您是正确的、这里的综合征只不过是再生 ECC 和旧 ECC 的异或。

这很有帮助！ 谢谢！

Unknown 说：

老实说、我从来没有这样做过、但是您可以尝试、如果您遇到任何困难、我将在这方面帮助您。

老实说,我已经尝试了,失败了。
1我通过 HCG 代码启用缓存。

2通过修改 辅助控制寄存器的位[5：3]、将高速缓存 ECC 模式设置为0b010。


3通过启用  辅助控制寄存器中的 DR2B、可以创建 ECC 错误。

4 该错误应该是被触发的。 但 ESM 状态寄存器3中没有发生任何情况。

尊敬的 Hanson：

您可以一次引用以下线程吗、这在这种情况下可能会很有用：

(+) TMS570LC4357：高速缓存 ECC 和 ESM 组3通道9 -基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：

感谢您的答复-它是非常有帮助的!

但是、仍然有一些东西令我感到非常困惑。
我检查了该线程并 尝试生成 ECC 错误。
以下是我的程序。

当程序 到达 红色框中的代码时、会触发数据中止。

0x300000000是 Dcache 的起始地址,也是我试图读取的地址。

数据故障状态提供以下信息：

基于此,我认为缓存准备不当,或者我访问它的方式不正确。

所以、我有几个问题：

1  在 尝试将高速缓存作为常规存储器进行访问时、是否应启用高速缓存？ 在本例中、我禁用了它。  
2当访问高速缓存作为常规存储器时,有什么具体的提示我应该知道吗?

非常感谢作出任何澄清。

——
谢谢、此致、

汉森。

尊敬的 Hanson：

很抱歉响应延迟、在这段时间内、我还遇到了很多其他问题。

关于此问题、我怀疑有一件事：

如果我们尝试直接访问未在 MPU 区域中配置的任何区域、则无法访问它们、并且它可能产生中止异常、请非常阅读以下默认配置。

因此、我的建议是尝试将此区域配置为如下所示的一个区域：

这可能会解决该问题、请检查并告知我。

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：

对迟交的答复深表歉意。 我刚刚结束了我的假期。

感谢您的意见。 我曾尝试按照您的建议配置 MPU、但很遗憾、仍然无法解决这个问题。 与以前一样、我仍然遇到同样的问题。

实际上、我并不认为数据中止是由 MPU 触发的。 我们可以看到、将0x1122334U 写入缓存并未触发数据中止、而从同一地址读取却会触发数据中止。  

数据中止状态表示该中断是 A  同步外部中止 而 MPU 将触发 背景 中止 所需的时间。

 再次感谢您的建议。 我 最初在作为常规存储器访问高速缓存时忽略了 MPU。 但这似乎不是问题的原因。

如有任何进一步的建议、将不胜感激。

谢谢、此致、

汉森。

尊敬的 Hanson：

是否有可能与上述问题共享一个示例代码、以便我在最后快速进行调试

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：

我为您准备了一个简单的演示。

请检查它。

谢谢、此致、

汉森。

e2e.ti.com/.../Cache_5F00_ECC_5F00_error_5F00_create.zip

尊敬的 Hanson：

对响应延迟深表歉意。

您是否仍然受困于此问题？

——
谢谢、此致、
Jagadish。

尊敬的 Jagadish：

感谢您的帮助。 我实际上已经通过这个问题,因为我想不出任何其他解决方案尝试。

测试它肯定是理想的,但我也可以继续而不直接测试它自己。

目前、我将重点介绍闪存中的 ECC 机制。

似乎、即使闪存中的实际数据仍然正确、但如果 ECC 代码本身中存在3位 ECC 错误、我们仍然无法准确检索它。

换句话说、如果我尝试从 ECC 错误超过 SECDED (单错校正、双错检测)功能的闪存区域读取、尽管数据本身完好无损、返回值将与闪存中存储的值不同。  

任何关于这一点的澄清都将是有帮助的。

谢谢、此致、

汉森。

尊敬的 Hanson：

对于再次延迟的响应、我们深表歉意、下次请确保及时响应。

似乎、即使闪存中的实际数据仍然正确、但如果 ECC 代码本身中存在3位 ECC 错误、我们仍然无法准确检索它。

换句话说、如果我尝试从 ECC 错误超过 SECDED (单错校正、双错检测)功能的闪存区域读取、尽管数据本身完好无损、返回值将与闪存中存储的值不同。  

我从未实际测试过这一点,但根据我的知识,这不应该发生。 如果 ECC 中存在多位(超过2位)错误、则返回的数据不应错误。

根据综合征表、ECC 中的3位错误将导致多位错误。 例如、假设 ECC 中的至少3位被损坏：

示例：

ECC 损坏前：0x46

ECC 损坏后：0x41

NOW 综合征(故障发生前 ECC 为 EX-OR、数据/ECC 损坏后 ECC 为 EX-OR)将变为：0x07

那么、如果将这个0x07与故障列表进行比较、它会指向第8列中的第一个元素、对吧？ 它只不过是 M、在本例中、M 表示多位错误。 因此、器件中的任何多位错误都将触发与 double 位错误类似的不可纠正的 ESM 标志、它也可能生成异常。

——
谢谢、此致、
Jagadish。