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.

[参考译文] MSPM0G3519:获取硬故障错误源(如何?)

Guru**** 2393725 points
Other Parts Discussed in Thread: MSPM0G3519

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1513271/mspm0g3519-getting-hard-fault-error-source-how-to

器件型号:MSPM0G3519

工具/软件:

您好:

MSPM0G3519中有很多硬故障异常的来源:总线错误、从非特权状态访问 CPU 外设、MPU 等  除了可能的堆栈帧转储位置之外、是否有办法获取硬故障的来源?

此致、  

Eugene

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

    您好、Eugene、

    硬故障将导致程序进入硬故障处理程序、但这不会告诉您它发生的位置。 最好的方法是使用微跟踪缓冲区。

    调试部分中找到

    如何在 CCS Theia 中使用内核跟踪调试应用程序崩溃

    马修

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

    如果调试器未连接、而这些情况确实会在现场发生(...并且当那里有数百万个器件时会发生)、该怎么办? 您如何建议处理这些问题、并确定根本原因?

    只是为了澄清。 问题不是发生在哪里、而是导致问题发生的原因。

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

    您好、Eugene、

    M0架构中存在一些限制、使我们无法轻松识别硬故障的原因。 我们通常的建议是在 M0上发生硬故障时进行复位。 这里有一些可能的权变措施、但它们涉及进入汇编代码。

    关于这个问题的背景、您还能告诉我什么?

    马修

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

    您好、Matthew、

    我知道 M0有一些限制。 我想知道什么是硬故障。

    至少、确定这是 MPU 违例、而不是任何其他违例将有所帮助。 如果我们需要调试从现场返回的结果、有关根实例的任何额外信息都会有所帮助。 我已经有汇编预处理程序来获取堆栈帧和一些 CPU 寄存器。 遗憾的是、我在 TRM 中找不到任何其他适用于硬故障的有用寄存器。 还能做些什么? 如果有、请分享示例。

    此致、

    Eugene

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

    您好、Eugene、

    最好的做法是识别 PC 值、然后使用它推断导致故障的指令。 遗憾的是、M0+在重检测硬故障方面受到限制。

    我们没有任何其他方法来确定硬故障是否是 MPU 违例。

    马修