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.
已编辑:环境温度下的 HDK。
大家好、
我有一个早期版本的 TMS570LS31x HDK、它具有我们几年前收购的 TMX570LS3137BZWTQWQI YFB - 25ASX4W GI MCU。
最近、每当它在早上上电时、ESMSR3=0x00000008指示 ESM 组3 RAM 偶数组 ECC 错误、并且 nERROR 引脚被置为有效(板载红色 LED 亮起)、并且 MCU 拒绝启动。
请注意、只有当调试器通过 JTAG 连接时、才能读取 ESMSR3值、然后使用相同的二进制代码重新编程。 现在可以正常工作、但板载红色 LED 保持亮起。
在对 MCU 进行预热一段时间后、如果 HDK 上的电源关闭几秒钟或几分钟、然后打开、一切正常、不再出现 RAM ECC 错误。
对此行为有何解释?
谢谢。
你好、Chuck、
CPU 还应该通过数据中止来响应此错误。 数据中止处理程序(或具有调试器连接的用户)可以查询数据故障状态和地址寄存器、以确定中止的根本原因。
您的应用程序如何处理数据中止条件?
此致、Sunil
您好、Sunil、
我的应用程序是使用 IAR EWARM IDE 编译/链接的、其中有一个用于此目的的默认异常处理程序(如果被捕获在处理程序中、代码将停止)。
我至少希望调试器能够在不下载的情况下通过 JTAG 进行连接、因此我可以在出现此类错误后检查 CPU 系统的状态。 由于不能进行连接而不下载,因此我必须重新下载完整的应用程序,这样状态可能会丢失,但之后它现在可以运行到 main()。
我的期望是错误的吗?
谢谢。
我认为我这样做没有成功。
由于装置现在是热的,并且在没有 nERROR 置位的情况下工作,我不得不等待星期一的上午,看看是否可以执行。
我会随时向您发布。
谢谢。
你好、Chuck、
您今天是否能够重现此问题?
此致、Sunil
你好、Chuck、
如果您看到 CPU 寄存器、程序计数器(PC)应显示代码卡在何处。 我怀疑它将位于数据中止处理程序中、其中可能有一个"循环此处"代码结构、使 CPU 不会返回主应用程序。
也就是说 、TMX570LS3137BZWTQWQI 器件尚未通过最终生产测试。 因此、在整个温度范围内可能存在不正确的功能。
此致、Sunil
您好、Sunil、
HDK 从今天上午11:32运行不到5分钟(整个 RAM ECC 错误)后就从断电、 在此期间、我一直在回答您的问题。
现在大约5个小时后、我已经将其重新连接到电源、我想、MCU 运行正常、闪存中上周的二进制代码正常。
所以我想我只能在明天早上确认程序计数器的位置...
威瑞多... RAM ECC 错误只需多长时间?!?
谢谢。
另请注意、在长时间断电后声明的 RAM ECC 错误最近才开始进入 HDK。 除 CPU 挂起和 ESMSR3寄存器内容外、该指示灯是板载红色 LED。
我知道我可以找到一个旧建筑来尝试它,但这将需要另外一天...
这是否是导致 ESM 组3中 RAM ECC 错误的软件问题(不是软件可控的并且不可配置)?
卡盘、
您可以尝试使用防冻喷雾剂、看看是否会导致故障按需发生。 软件问题肯定会导致这种情况、例如、如果您在读取 RAM 位置时未先对其进行初始化。 即使在对 SRAM 进行写入访问时也会发生这种情况。 Cortex-R4F CPU 针对任何对非64位宽的 SRAM 的写入执行一个读取-修改-写入操作。 因此、任何入栈操作都可能导致 RMW 操作触发一个双位 ECC 错误。
此致、Sunil
Sunil、
有点奇怪、请记住 HDK 在我的办公室内、始终处于室温、大约23°C
我找不到一个冷冻罐、但却能找到一罐压缩气体除尘器、我在 MCU 上喷洒了大约60秒、并确保它真的很冷、仍然在冰点上方、但触摸时很冷、运气不好。 它在连接电源后即可正常运行。
我问自己这是与温度相关的、还是只是 MCU 内部的一些分子(读作:触发器门)、这些分子让我感到很有趣! 如果能通电几分钟,就会很开心,然后又能慢放电(超过5小时)... 哈哈
我还记得、在早上、如果我将 HDK 插入电源几秒钟、就会看到问题、断开并重新连接、仍然有问题。 我在这里的看法是,需要几秒钟的时间才能使事情充满活力... 如果事情是真实的:)
我明天会再试一次。
早上好、Sunil、
是的、程序计数器实际上位于0x000cc98、指向中止异常的中断处理程序。
它所需要的只是几秒钟的连接到电源、然后在电源被回收后工作正常。
我是否应该在此 HDK 上更改 MCU?
是否有其他关于此类行为的建议?
再次感谢。
早上好、Chuck、
是的、您可以执行一些操作来进一步调试。
另一项建议:请更新数据中止处理程序以进行管理、例如条件、以便它不会一直停留在"循环"代码结构中、除非您有外部看门狗将系统置于安全状态。
此致、Sunil
您好、Sunil、
您能告诉我如何检查数据故障地址和状态寄存器吗? 这些寄存器是由 ARM 内核管理并复制到某些 MCU 寄存器空间、还是由 MCU 直接管理?
感谢您分享知识。
此致。
很棒的 Sunil
我在 IAR EWARM 下看到 DFSR 和 DFAR 寄存器。
我知道 DFAR 寄存器指示数据访问故障地址、但在哪里可以找到 DFSR 寄存器的解释?
谢谢。
在 Cortex-R4F TRM 中描述了 DFSR。 请参阅 https://developer.arm.com/docs/ddi0363/g/system-control/register-descriptions/fault-status-and-address-registers
谢谢 Sunil、
明天将检查并保持发布。
此致。
晨报
今天早上,我们错过了重现问题的机会...
我像往常一样冷启动了 HDK,虽然 nERROR 引脚 LED 仍然如前一天一样有效,但“调试但不下载”调试器命令实际上起作用,这意味着调试器毫无问题地运行到 main(),然后等待... LED 仍然为红色、与之前中止处理程序中的无限循环相反。
通过检查 ESM 寄存器、仍然声明 RAM ECC 错误的相同 ESM3SR=0x00000008、但是所有 PL1错误处理寄存器都是0x00000000。
按下"Run"按钮实际上已启动正常的软件执行、LED 为红色。
这怎么可能发生?
谢谢。
你好、Chuck、
我很惊讶数据中止处理程序也会执行代码。 系统复位时不会清除 ESMSR3寄存器、因此以下情况可能会解释您的观察结果:
如果您将系统重置作为重置处理程序的一部分进行记录、则需要确认系统重置的来源。
您好、Sunil、
我理解您的说法。 MCU 位于 TI HDK 上、因此没有外部看门狗复位。 唯一的复位是调试器 JTAG 在尝试连接(不下载)时启动的复位。
问题是,有时重置成功,因此代码重新启动,但有时不会重新启动,卡在 Abort_Handler()中。
这有道理吗?
美好的一天!
你好、Chuck、
是的、这与我发送的序列相匹配。 对于 IAR 工具、我不是专家级用户、但应该有一种方法可以连接到器件而不会将系统复位置为有效。 然后、您可以在中止处理程序中捕获 CPU。
或者、您可以编写数据中止处理程序来记录您的 DFAR 和 DFSR 值、并将其存储在启动期间未自动初始化的 RAM 中。
此致、Sunil
您好、Sunil、
嗯、我终于捕获了一些东西、请多多包涵。
因此、要使用的 IAR 命令是"附加到运行目标"、而不是"调试而不下载"。
有一次、我得到 ESMSR3=0x00000028、这表示偶数和奇数 RAM 组都声明了双位 ECC 错误。 查看数据故障状态寄存器 DFSR=0x00000C09、可以看到 AXI 解码器写入操作错误、它是"同步奇偶校验/ECC 错误"、数据故障地址寄存器 DFAR 是有效的、即0x080017C8。
我尝试找到这个静态 RAM 位置中的内容、但无法正确解释:
1) 1)有关 DFAR 和 DFSR 变量的观察窗口
2) 2)第1670行、1671行的链接器映射、0x080017c8处的 DFAR 和0x080017cc 处的 DFSR、长度为0x4字节、没关系。
3) 3)地址0x080017c8处的存储器转储:猜测、该地址范围内的所有数据都包含值0x080017c8。 如何解释 address=value?
卡盘、
这是我所期望的。 在初始化 CPU SRAM 之前、您确实发生了栈写入(PUSH)操作(导致 R-M-W 操作导致中止)。 识别执行此写入的代码部分的方法是在中止模式(R14_abt)下查看链接寄存器。 这将在导致数据中止的指令之后有两条地址指令。 此外、来自数据中止处理程序的正常返回指令应该返回到引起中止的指令(除非它被停留在一个 while (1)循环中)。
此致、Sunil