This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TMS570LS3137:使用 Uniflash 自动 ECC、仍然会出现 ECC 错误

Guru**** 646230 points
Other Parts Discussed in Thread: UNIFLASH, NOWECC, TMS570LS3137
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1032736/tms570ls3137-auto-ecc-with-uniflash-still-get-ecc-error

器件型号:TMS570LS3137
主题中讨论的其他器件:UNIFLASHNOWECC

大家好、我正在调试一些传统代码、我收到意外的 ECC 错误。

我们的项目具有多个编程到 TMS5703137CGWTQEP 的十六进制文件。

CAN 引导加载程序(CBL)、在组0扇区0中

即 PDIF。 在组0扇区3中(这只是参数存储器、无执行代码)

应用程序、在组0扇区4中


CBL 和应用程序在其链接器文件中没有 ECC 设置。

CBL 不会为闪存打开 ECC。

该应用确实会使用库函数 _coreEnableFlashEcc_()为 sys_startup.c 中的闪存启用 ECC;

我们将 nERROR 连接到一个红色 LED、因此如果我滑动并说红灯亮起、这就是我所指的。


我的问题是、当我在自动 ECC 打开的情况下使用 Uniflash 6.1.0.2829一次性对全部三个软件进行编程时、我预计不会出现 ECC 错误。

但是、我的红灯实际上正在点亮。 调试寄存器时、我会看到以下内容:

STAT3和 FEdacStat 显示组3通道7错误、这是不可纠正的 FMC 总线错误

 在组0扇区6中、0x000643E0的地址关闭、我们不对其进行编程或写入。

该应用程序还会检查 sys_startup.c 中是否存在组3错误、  如果此启动检查出现任何错误、则会使用看门狗重新启动、但这不会触发。

显然、我的组3错误是在启动后发生的、这是如何发生的。


因此、老实说、我有点困惑、即使我使用 Uniflash 对所有内容进行编程并打开自动 ECC、我也会收到闪存 ECC 错误。  

我们非常感谢您的任何建议。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    Cortex-R4 CPU 可以生成推测取指令到 ATCM 存储器空间内的任何位置。 对具有无效 ECC 的位置的推测取指令(随后未使用)不会创建中止、但会为可纠正或不可纠正的错误设置 ESM 标志。 不可纠正的错误将无条件地导致 nERROR 引脚切换为低电平。 因此、必须注意为整个 ATCM 空间生成正确的 ECC、包括段与任何未使用或空白闪存区域之间的空洞。

    我建议您使用引导加载程序的链接器 cmd 为整个闪存生成 ECC。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="45190" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1032736/tms570ls3137-auto-ecc-with-uniflash-still-get-ecc-error/3818446 #3818446"]可能会生成

    推测取指令是否确定? 是否仍然可以限制被检查的闪存扇区?

    [引用 userid="45190" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1032736/tms570ls3137-auto-ecc-with-uniflash-still-get-ecc-error/3818446 #3818446"]为整个 ATCM 空间生成正确的 ECC 时必须小心[/引用]

    我将 Uniflash 设置为"erase All"、然后是"Auto ECC"。 对于 ECC 检查、这种组合是否应该是确定性的? 在装载机方面还有什么可以做的呢?

    对于我们的程序来说、链接器 cmd 更改目前是一个较差的选项、因为实际的源代码更改目前不在范围内。 Uniflash 方面的任何选项都将不胜感激。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    推测取指令不 是确定性的。

    Uniflash 和 CCS 中的"ECC"生成选项仅支持映像的 ECC 计算、不会计算未使用的闪存段的 ECC。  如果您正在使用自定义或第三方编程工具、或者您希望确保存档的图像已完成、但由于外部影响、以后不会更改、则此选项可能不够。

    NowECC 是 ECC 计算的另一个选项:

    https://www.ti.com/tool/NOWECC

     

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="45190" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1032736/tms570ls3137-auto-ecc-with-uniflash-still-get-ecc-error/3819189 #3819189"]不计算未使用的闪存段的 ECC。  t[/报价]

    谢谢、这触发了我的解决方案、方法是创建一个包含未使用扇区填充的临时应用、然后使用 Uniflash 对其进行编程、以获得正确的 ECC。 然后、我能够正常对我们标记的软件进行编程、并且运行时没有 ECC 错误。  

    推测取指令不确定对我来说是令人困惑的。 在调试这个问题时、我尝试了三个不同的电路板/TMS570LS3137芯片、它们具有相同的 Uniflash 设置、并且它们上的地址都是0x000643E0。 有什么想法吗?

    虽然 temp 应用是一个可行的解决方案、但我想通过为未使用的扇区创建一个奇异填充十六进制文件来改进这一点。 是否有一种便捷的方法来为扇区5生成一个只以0xFFFFFFs 结束的有效十六进制文件?

    感谢您的建议。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="497352" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1032736/tms570ls3137-auto-ecc-with-uniflash-still-get-ecc-error/3819462 #3819462"]推测 取指令不确定对我来说是令人困惑的。 [/报价]

    Cortex-R4执行推测访问的可能方式超出应用定义 有一些有关推测取指令和数据的信息。

    如果推测取指令仅对闪存中的地址运行、并且程序不修改闪存、可以看到对于多个器件上的给定程序、推测取指令可能始终来自没有有效 ECC 的同一闪存地址。

    不确定 LDR 指令的数据预取是否可以尝试按照寄存器中可能与运行模式不同的地址执行。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您提供更多信息。