[参考译文] TMS320F28P650DK：ECC 测试问题

该示例存在一个已知问题、即它对未编程的闪存位置使用地址、因此会生成不正确的错误类型（意外可校正错误）。 我认为这不会导致您看到的行为。

我认为实施此测试时需要小心、确保在测试模式处于活动状态时不使用闪存。 这包括由错误引起的 ISR 及其可能调用的任何函数、以及在此期间可能发生的其他中断（暂时禁用这些中断可能更安全）。

如果这些建议都没有帮助、请查看您是否可以获得更多详细信息。 它以何种方式失败？ 应用程序崩溃了吗？ 或者测试功能是否仅返回失败值？ 故障的性质是什么（未生成 NMI、中断/错误状态不正确等）？

Whitney

您好：  

感谢您的回答。

如果位于 RAM 中的 ISR 处于活动状态、会出现问题吗？

此外、您能否就以下两个主题提供反馈：

   是否可以通过电源复位而不是软件复位来消除故障？

   测试期间电源不稳定是否可能导致故障？

很遗憾、我们没有其他信息、因为我们无法在测试台上重现问题。

但客户正在寻求反馈。

谢谢

如果位于 RAM 中的 ISR 处于活动状态、会出现问题吗？

如果 ISR 位于 RAM 中、您可以确认它未调用闪存中的任何函数、那么这个应该可以。

是否可以通过重置电源而不是软件重置来消除故障？

很难猜测为什么这可能是没有更多关于故障性质的信息的情况。 我已经浏览了相关寄存器的说明、它们都看起来像是通过 SYSRSn（调试器复位）复位的、而不是 POR。  

我想不出为什么不稳定的电源会影响这个测试特别的原因。

他们如何知道 导致该问题的是 ECC 错误测试？ 如果 ECC 测试失败、应用程序会做什么？

Whitney

您好 Whitney、

感谢您的答复。

现在、我的设备出现了问题。

ECC 测试错误与我之前想象的闪存无关、而是与 RAM 上的 ECC 测试有关。

特别是、当我从诊断库 运行 CorrectionECCTest () 执行函数时、出现故障。

在注释为的部分中：

//
//遍历 M0 RAM 位置、直到每个 ECC 位对应的高 16 位
//（位 14：8）已将错误注入其中。
//

失败的测试是：

if (errorAddr！=((uint32_t)&m0Data)+ 1UL))

我一直在使用这个测试,因为很多时间没有问题（并且问题出现在几个样本,很好的部分工作正常）。

即使与之前固件一起使用的有缺陷样片也能正常工作（以前的固件指具有不同功能但具有相同代码用于 ECC 测试的固件）

我完成了以下测试：我将测试从 M0 RAM 移至 M1 RAM（未使用 M1 RAM，因此现在它仅用于测试）。在这种情况下、示例运行良好。

您能给我解释一下什么是问题吗？ 可用于测试的 M0 地址是否有限制？ 如果我在链接器中保留一个固定的存储器区域以供测试、会更好吗？（当前我只是在 M0 存储器区域中映射，而不是在固定地址）

您能否检查  runCorrectionECCTest() 中是否存在已知问题或我应忽略的某些推荐问题？

非常感谢、

Barbara

M0 通常用于什么？ 有何不同？ 此检查会将被测试的 RAM 块置于测试模式（与所有 M0 类似，而不仅仅是注入错误的特定地址）、因此我们可以在数据和 ECC 之间造成不匹配、因此当 RAM 处于测试模式时、在再次禁用测试模式之前、不应该对其进行堆栈、变量或代码执行等访问。

Whitney

您好：

RAMM0 也用于：

- hwbiststack（测试是在 ECC 测试之前执行的,所以我不认为这是责任）

-.data ->在这种情况下、我不能排除在测试执行期间执行对其中一个中断的访问、因为在该阶段中启用了中断（如 TI 示例 sdl_ex_ram_ecc_parity_test.c 中所示）、因为我正在使用 corrErrorISR？

非常感谢、

Barbara

您能否确认以这种方式使用 DINT /EINT 可以解决我的问题？

DINT；
testRAMLogic (MEMCFG_sect_m0、MEMCFG_TEST_WRITE_ECC、(uint32_t)&m0Data、(RAM_ECC_SINGLE_BIT << IDX)；
EINT；

如果问题确实是由该功能期间的中断引起的、这可能会解决该问题。 更具体地说、这 3 条线路需要在测试模式下不间断地执行、而无需访问存储器。  

corrErrorISR 不会执行、直到 M0 RAM 重新处于功能模式并且已读回注入的错误、因此应该可以正常工作。

当您为 ECC 错误获得不正确的地址时、您能否将这些地址与映射文件进行比较、看看它们是否与特定变量的位置相匹配？ 它们是否都在为.data 保留的区域内？ 这可能会帮助您确定是否存在导致该问题的中断。

Whitney

是、返回的地址在.data 范围内

您是否能确定哪些特定变量可能会连接到这些地址？ 我想知道确定变量是否可以提供有关是否/哪个中断导致了问题的提示。

Whitney

您好、我找到了测试过程和访问 M0 存储器期间可能进入的两个中断（其他中断不使用 M0 存储器）。

其中一个中断只执行一次读取、另一个执行一次读取、另一个执行四次写入。 用于读取和写入的变量是不同的。

您能否确认返回的地址是读取、写入还是两者都涉及的地址？  

尊敬的 Barbara：

我今天对 RAM 测试模式进行了一些实验、想和大家分享我观察到的一些可能对调试有所帮助的内容。

正如我在调用中提到的、从存储器读取数据时会发生错误检测。 不过、我发现、如果您在测试模式处于活动状态时执行读取、则不会执行检测、无论是否注入了错误、似乎都不会产生错误。 直到 RAM 恢复“功能“模式后、读取才会检测到注入的错误。 因此、基本上、在测试过程中单独读取 ISR 数据可能不足以导致地址错误。

无论如何、在测试期间启用中断仍然存在其他问题。 如果在 RAM 处于测试模式时写入、则在 ISR 中写入的变量将用不匹配的 ECC 和数据（假设它们的值不断变化）写入、这会增加一个错误、您最终会在 RAM 返回功能模式后稍后读取这些变量时检测到这些错误。 这可能是您看到错误的原因、但我不知道时间轴是否一定适合您看到的特定行为、因为您说 ISR 中的读写变量是不同的。

另一个问题是您正在读取的变量。 特别是在 ECC 测试模式期间、如果您读取该 RAM 中的变量、读取将获取 ECC 值、而不是数据值。 它可能不会导致检测到错误、但变量将包含无效数据、这可能是一个问题、具体取决于您将该变量用于的用途。

Whitney