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.

[参考译文] TM4C123GH6PGE:硬故障调试

Guru**** 2390755 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1167988/tm4c123gh6pge-hard-fault-debugging

器件型号:TM4C123GH6PGE
主题中讨论的其他器件:TM4C123

大家好、

这是在黑暗中拍摄的照片、因为我偶然发现调试了代码中发生的随机硬故障。

该故障似乎随机发生、有时在几天之间甚至几个月内发生。 在连接 JTAG 的调试会话中、我曾尝试捕捉故障、但几个月以来一直不幸运。 因此、我不必坐在微控制器旁边进行调试会话并连接 JTAG、我添加了一些寄存器信息、我将这些信息保存到故障处理程序中的闪存中。 这不是最复杂的方法、但我希望我可以在观察到寄存器堆栈后对问题进行逆向工程。

我已经有几次崩溃转储、并开始区分寄存器的含义、但我对我看到的内容完全感到困惑。 我不会在这里列出所有内容、但我看到的重要寄存器如下所示:

CFSR 寄存器的值为1。 这告诉我发生了一个访问违反(IACCVIOL)。 当我第一次开始执行这些故障转储时、寄存器告诉我这是一个"不精确的故障"、这意味着寄存器中的许多信息是无用的。 谷歌搜索后、人们建议关闭写缓冲、将不精确的故障转换为精确的故障。 我这么做了、这就是我发现它是一个访问错误的方式。

此时、IACCVIOL 的文档显示"当该位为1时、为异常返回堆栈的 PC 值将指向错误指令。 处理器未向 MMAR 写入故障地址。" 好的、我可以查看 PC 值、我也将其写入闪存、并且可以缩小导致问题的指令范围。

问题是、故障处理程序寄存器堆栈中的 PC 值为"0xFFFFFFEC"。 对于多个崩溃转储、该值始终位于 PC 寄存器中。 我会丢失、因为该地址距 TM4C123芯片存储器本身的末尾19个字节。 它也牢牢地位于内存的"保留"区域。

来自数据表:

虽然我同意尝试访问此存储器会产生错误、因为它是保留的。 在解释文档时、我错误地说 导致故障的指令位于 PC 值。 0xFFFFFFEC 上可能有什么程序指令? 我很乐意知道 PC 中的值可能是无用的、但从读取 ARM 寄存器文档中可以看到它特别发出的"当该位为1时、为异常返回堆栈的 PC 值指向错误指令"

任何建议、想法或想法都值得赞赏。 几乎在芯片末尾的一个保留存储器块中的地址实际上使我进入了循环:)

谢谢!

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

    尊敬的 Mike:

    这确实令人困惑、因为该区域没有指令。 这让我想知道堆栈是否已损坏。 您是否已验证没有发生栈溢出或可能发生内存泄漏(缓冲区溢出、malloc 问题等)

    您好像在使用  IACCVIOL 位编写 Arm MCU 手册、这样吗? 我无法从 TM4C 数据表中识别它。

    您是否尝试过使用专用 TM4C 寄存器执行相同的操作?  寄存器76:可配置故障状态寄存器(FAULTSTAT)、偏移量0xD28?

    我从未在 Arm 手册指导下调试过该器件的故障、而是仅使用  FAULTSTAT 等工具。 因此、Arm 默认错误处理可能不会告诉您 FAULTSTAT 寄存器会发生什么情况。

    此致、

    Ralph Jacobi

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

    您好、Ralph、

    感谢您的回应! 是的、IACCVIOL 位来自 Arm MCU 手册中的可配置故障状态寄存器。 芯片数据表中可配置故障状态的 IERR 位等效。 我不知道他们为什么要更改位名称:)

    IERR 位的描述与 IACCVIOL 一样、并添加了一句话:"即使 MPU 被禁用或不存在、在任何到 XN 区域的访问中都会发生此故障。" 因此、我假设0xFFFFFFEC 实际上位于程序计数器中、那么访问从不执行区域就有意义。

    此时、我可以相信、0XFFFFFFEC 可能以某种方式进入了 PC 值。 然后、当它跳到那里时、故障发生。 正如您指出的、现在这是一个有关该值如何实现的问题。

    幸运的是、代码中没有分配程序或调用程序。 这样就可以消除任何有故障的动态内存分配。  我想我将重点介绍您提到的溢出缓冲区项目。 我们执行大量的 I2C 恒定读取、我不确定我们是如何存储/处理这些数据的。 也许我们正在对数组进行溢出、或者使用不正确的数据类型来读取我们正在读取的数据。

    感谢您的建议!

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

    尊敬的 Mike:

    另一个原因可能是计数过大、或者计算结果不应为负。 在符号数中、它是一个距离0x0000不远的负数。

    我与我的同事进行了检查、他强烈怀疑堆栈损坏也是原因所在。

    以下是检查堆栈溢出的方法: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1164811/tm4c1230e6pm-reset-of-micro/4386491#4386491

    虽然我不确定这对您的系统有多好、尽管您在调试时遇到了挑战、但如果您可以在发生故障后连接到器件、仍应检索内存位置以查看堆栈是否溢出。

    此致、

    Ralph Jacobi