[参考译文] TMS570LC4357-ECC：闪存或 EP 或未知根本原因

对此的更新、
我更新了代码以专门使用闪存 API 来读取 CRC32 函数中的数据。  这未能解决我看到的问题。

实际上、预热循环是解决此问题的不一致的解决方法。 但是运行 CRC32 两次仍然保持一致、以便更新闪存值、似乎需要以大约 128KB 的长度运行才能使值始终如一地更新。

如果在刷写应用程序并将内存窗口设置为持续刷新的同时运行调试器、我确实可以看到偶尔会显示正确的值。 但是、当它到达运行（第一个）CRC32 的点时、它始终使用上面第一个图像中显示的值暂停。 同样、在未连接调试器的情况下运行时显示了类似的行为。

但仍不确定这些闪存值正确更新以读取的原因是什么。 任何建议或信息都会有帮助。

您好、Spencer、

不幸的是、我以前从未遇到过这种行为。

1.您能否尝试在引导加载程序代码上禁用一次缓存并执行一次测试：

此外、我需要对以下内容进行说明：

1.您正在使用哪个引导加载程序？

2.您使用的 CRC 是硬件还是软件?

3.根据我对您的项目的理解,首先,您的引导加载程序项目将通过一个通信介质接收应用程序,然后使用 FAPI 库将相应的应用程序写入闪存。 一旦应用程序正确写入闪存、您就会为应用程序计算 CRC。 我的理解是否正确？

4.您打算如何处理生成的 CRC？ 闪存和应用中是否也有任何预先计算的 CRC？ 您想将其与之进行比较吗？

--
此致、
Jagadish。

尊敬的 Jagadish：

1.回答缓存问题,我认为还有第二个问题是相关的。 重新启动器件并刷写好应用程序时、我会运行 CRC 并将其与保存在闪存中的内容进行比较。 但是、一旦我在代码中运行 CRC、第二个 32 位字就会始终发生变化 — 在下图所示的函数内完全随机发生变化，并且 CRC 与我在闪存中保存的内容不匹配（仅再次是第一次）。 无论是否使用调试器、这都是一致的。

现在、如果我运行如下所示的预热循环、有时会导致单字正确、但并非总是如此。  

如果我禁用缓存,这将始终如一地工作,无需预热循环或两个 CRC32 () 调用。 但是、我的代码对安全至关重要、我无法使用编译器优化->我的代码结果需要在其他位置使用缓存，否则程序无法正确通信 — 我的引导加载程序仅支持 CPU、无中断或 DMA、可减少大量测试工作量。 我已在下图中尝试禁用缓存->运行 CRC ->重新启用缓存->并使缓存无效、但 MCU 会在某个地方不断崩溃。  

关于这一点的最后一点、如果我保持缓存处于禁用状态、则无法正确通信以接收要写入闪存的应用程序。  

1.我使用的是自定义引导加载程序。 如果闪存驱动程序代码有用、我可以使用 FAP 来提供其部分代码。

2.我目前使用的是软件 CRC。 我想切换到硬件 CRC、您是否有在该器件上使用该 CRC 的代码示例？

 是的、我通过 SCI 接收到该应用程序、将其复制到 8 字节对齐的存储器缓冲区中、并以小块写入闪存。 我一直使用 Fapi_issueProgrammingCommand () 的 32 字节写入大小和 8 字节写入大小。 是的、一旦将应用程序写入闪存、TMS570 就会从发送应用程序二进制文件的外部器件 (PC) 接收 CRC、然后运行 CRC32 ()、如本页的第一篇文章所示、我使用它与刚刚从 PC 接收到的 TMS570 的 CRC 进行比较。

关于我的原始帖子、 一旦闪存值被更正、但结果是不匹配的 crc ->在第二次运行 CRC32 () 后、结果是匹配的 crc（并且闪存值不会再次更改）。

4.生成 CRC 并且与从 PC 接收到的 CRC 匹配后、我将其保存到闪存组 7 中。 然后、我在重新启动/重新启动时使用此正确保存的 CRC、以与另一个生成的 CRC 进行比较->此回复中的图像是我在重新启动时的代码、用于在应用程序上运行 CRC 以验证其是否未损坏。 现在、正如我在本回复的第一部分中解释的那样、如果没有循环或两次运行 CRC32、CRC 匹配将失败。  

最后、我认为 CRC 生成和逻辑本身没有问题、是正确的、我确实使用 API 正确地写入闪存。 我仍然非常迷失在其他我可以尝试或研究的东西上

您好、Spencer、

我真诚地为延迟的回应道歉！

我在这台设备上从未遇到过此问题。 为了进一步讨论这个问题,我需要你的两件事

1.您可以与您一起设置一个实时调试会话。

2.然后,如果需要,我需要你的代码或任何演示代码与此示例.

我将在美国时间上午 10 点至晚上 10 点之间提供。 您可以根据您的可用性安排呼叫。 注意：明天 (星期五) 是我们的假期。

--
此致、
Jagadish。