[参考译文] TMS320F28374D：NMI (FLAUNCHR)会不时发生

卡洛、

是在每个器件上发生的吗？  如果是、则可能是由于对错误的 ECC 进行编程而导致的问题。 请检查并告知我。

他们可以检查发生错误的地址(请参阅闪存 ECC 寄存器)、并查看它是否与他们的生产映像匹配(假设在应用程序运行期间或现场未再次对该位置进行编程)。

谢谢、此致、

Vamsi

您好、Vamsi、

首先、感谢您的回答。

在每个器件上、它的发生似乎越来越少。 它通常在上电几个小时后发生(通常在8-10个小时后发生)、但也可能在几分钟后发生。

编程；我们有自己的引导加载程序；当我们在应用程序中时会出现问题。

使用 JTAG 连接 Blackhawk 和 Uniflash 对引导加载程序进行编程

使用与 RS485通信的专有协议对应用进行编程。

此致

Emanuele

您好！

我还重新编译了工程以在没有引导加载程序的情况下工作、问题仍然可见； 器件在10小时后复位。

此致

Emanuele

Emanuele、

感谢您提供信息。

您是否在所有器件的同一位置看到 ECC 故障？

如果是、则可能是自定义加载程序错误地对 ECC 进行了编程。

在发生故障的器件中、您只需在 RAM 中加载一个代码、即可在启用 ECC 检查的情况下读取整个闪存。  并监视 ECC 寄存器以查看发生错误的地址。  找到错误位置后、您可以缩小问题范围。

您的应用程序在运行时是否也会进行闪存编程？

CPU1闪存或 CPU2闪存中是否出现问题？

谢谢、此致、
Vamsi

Vamsi、

 此时、我有3个测试中的器件。

下次发生故障时、我应该能够读取产生问题的地址。

CPU1上显示此问题。

程序加载；我们在没有引导加载程序的情况下也会对此问题进行实验。

我们可以重新编译代码以在没有自定义引导加载程序的情况下工作、因此我们可以使用 uniflash 或 CCS 加载代码；因此、我认为我们可以将自定义加载程序排除为根本原因。

此致

Emanuele

Emanuele、

感谢您提供信息。  必须知道、即使使用 CCS 或 UniFlash 进行编程、应用也会失败。  如前所述、我认为了解 ECC 错误发生的地址非常重要。  这有助于您确定根本原因。

以下是需要考虑的一些事项：

1.您最近是否对您的应用程序进行过任何更改？  自应用程序最近开始失败以来、您需要专注于这些更改。   

2.一旦您使用 CCS 或 UniFlash 对器件进行编程(以及在运行应用程序之前)、请将一个简单代码加载到 RAM 中、以便在启用 ECC 的情况下读取整个闪存。  这有助于了解错误是在应用程序执行之后还是甚至在执行之前出现。

3.您是否对应用程序进行了校验和测试(不是在运行时)以确保闪存中的应用程序映像完整？  如果是、校验和测试是否通过了故障器件的测试？  编程后、您可能需要立即在器件上运行测试。

4.您的应用是否在其中嵌入闪存 API？  如果是、应用程序是否会调用闪存 API 来在运行时擦除和/或编程闪存？

5.是否对 DCSM 用户 OTP 进行编程？  如果是、请检查 OTP 上是否有上面列出的#2和#3。

6.您可能已经知道了这一点，但以防万一：在您的应用程序链接器 cmd 文件中，您是否有任何已初始化的段映射到 RAM？  如果是、请注意、所有已初始化的段都应映射到闪存。  如果需要，可以在运行时使用 memcpy()将它们复制到 RAM，然后再从 RAM 访问/执行它们。   

7.请确保按照工作频率正确配置闪存等待状态。

谢谢、此致、
Vamsi   

您好，Vamsi，

所有检查点 均未成功。

请您详细说明一下 POIN6吗？  

不是很清楚

谢谢你

此致

卡洛

您好、Vasmi、

我仍在等待接受测试的设置中出现新的 NMI 事件。

关于闪存配置、您可以在这里找到内部寄存器的屏幕截图

此致

Emanuele

卡洛、

您能解释一下它意味着什么不成功吗？  请提供更多详细信息。

在应用程序链接器命令文件中、是否有任何内容映射到 RAM？  可以将未初始化的段(例如：.ebss、 .stack、 .esysmem)映射到 RAM。  但是、初始化的段(如.text、.cinit、.econst、.switch、.reset)应该只映射到闪存。  如果需要从 RAM 执行任何代码，仍需要将其映射到闪存以进行加载，然后在运行时使用 memcpy()将其复制到 RAM。  您知道 ramfuncs (或.TI.ramfunc)-对吗？

谢谢、此致、

Vamsi

Emanuele、

好的、请在您找到故障地址以及该地址属于您的应用程序时通知我们。   

关于闪存配置： 我查看过、看起来不错。 下次、如果您希望我们查看此类内容、请拍摄清晰的快照、以十六进制格式显示所有位字段值。 这样便于查看。  我将所有十进制值转换为十六进制、这次查看了。  感谢您的理解。

谢谢、此致、

Vamsi

您好！

我们在所测试的设置之一中试验一个新故障。

我们捕获了在本例中生成故障的地址：

• 寄存器地址0x5FB06 UNC_ERR_ADDR_LOW = 0x0000000
• 寄存器地址0x5FB08 UNC_ERR_ADDR_HIGH = 0x000701FC

此致

Emanuele

Emanuele、

该特定地址位于 TI-OTP 闪存的一个部分、其中包含有意的 ECC 错误、因此面向安全的应用可以验证 ECC 逻辑的功能。

Tommy

Tommy、

现在的问题是为什么会发生这种情况。

1. 指针可能会有问题吗？
2. 这可能是闪存编程问题吗？

我正在准备另一项测试：

我将在连接 Blackhawk 的情况下向位置0x701FC 添加2个观察点(读取/写入)。 我希望能找到这种错误的访问发生在哪里。

在这种情况下不会产生 NMI、但是如果有一个到这个位置的存储器访问、CPU 应该暂停。

还有另一个有趣的问题；我发现另一篇文章的问题大致相同：

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/767132?TMS320F28375D-Rarely-occuring-NMI-FLUNCERR-on-28375D

相同事件和相同错误地址； 0x701FC...

您知道他们是如何解决的？ 没有其他信息。

此致

Emanuele