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.

[参考译文] TM4C123GH6PZ:故障地址= 0x2000.8000

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/566109/tm4c123gh6pz-fault-address-0x2000-8000

器件型号:TM4C123GH6PZ

您好!

我将以高速率(1000Hz)向 TM4C123GH6PZ 微型器件的 UART 发送串行消息。 我注意到、在收到1500左右的良好消息后、微控制器将进入故障 ISR。 每次试运转期间、故障前的消息数量似乎并不完全相同。 故障状态寄存器= 0x0000.8200。 故障地址寄存器= 0x2000.8000。  它属于存储器映射上的"保留"部分。  我在论坛上找不到有关此故障地址的详细信息。 一条注释提到、这是微控制器在 SRAM 外运行时引起的。  

有趣的是、数据表中的存储器映射中有一条注释: 注意:在存储器映射中、尝试在保留空间中读取或写入地址会导致总线故障。 此外、尝试在闪存范围内写入地址也会导致总线故障。


因此、听起来微型器件正在尝试访问保留地址0x2000.8000。 这是 SRAM 问题吗? 我还能做什么来确定此故障的原因?

感谢您的帮助、

CamK

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

    我是否可以赞扬您为您的帖子所付出的关心、细节和努力?    干得不错。

    现在-对于问题-假设(LPAD 上显示列出的 MCU)您正在使用 UART_0 -通过板载 ICDI MCU -您是否可以确认?

    如此多的消息安全送达(并且处理得很好)这一事实(可能)会将一些责任转移到您的"数据源链"上。   (发起设备(PC?) 和电路板的 ICDI MCU)

    您是否尝试过:

    • 降低波特率
    • 降低到达的消息速率(低于所述的1000Hz
    • 确定"故障触发消息"的(重复)特性 (即长度、重复或"非法"字符的存在)    

    "新消息"是否可能在"完全/完全处理"之前到达、并且"重叠"会导致(或导致)您的问题?

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

    所访问的 SRAM 不在 TM4C123x 器件上提供的32KB SRAM 范围内。 在项目的链接器命令文件中指定的 SRAM 大小是多少?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Amit、您好!

    因为~1500这样的消息(看起来)需要妥善处理-您是否认为 SRAM 会逐渐填满-并溢出(最终)到"禁止区域?"
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好 CB1

    这取决于应用程序如何处理存储器。 是否创建了一个大型阵列(可能指向 SRAM 大小不正确)、从而允许应用程序假定一个较大的 SRAM。 我首先要清除通常的嫌疑犯。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    感谢 Amit 和 CB1提供了深刻的评论。 我想提供一些更相关的信息,以帮助澄清这种情况。

    -我将以1000Hz 的频率向 UART0上的微控制器发送消息。 消息长度为7字节。 微控制器处理消息并为每条消息生成30-40字节的应答。 UART0的波特率设置为115200bps。

    同时,我还在 UART2上以1000Hz 的频率接收长度约为40字节的数据报消息(来自陀螺仪)。 微控制器处理这些消息、但不回复其中任何一条。 这是921600bps 的硬编码波特率。 我无法更改此波特率。

    -当我不在 UART0上发送任何消息时、微控制器可以处理来自 UART2上的陀螺仪的通信。 当我开始在 UART0上发送消息(UART2上仍在发生通信)时、在收到1000条消息后的某个位置按 FaultISR。 如果在 UART0上仅发送大约1000条@1000Hz 的消息、则表明我已清除、并且没有故障。 如果我等待一秒钟、然后再发送另一个1000、则没有故障。 在我遇到故障之前的消息数似乎与1250-2000有很大差异。

    -我确实注意到、如果我减速并以500Hz (而不是1000Hz)的频率在 UART0上发送消息、我永远不会遇到 FAULTISR。

    -我还尝试将 UART0的波特率降低到9600bps、同时保持1000Hz 的消息速率、虽然我不再生成任何故障、但我的微控制器似乎无法跟上消息的速度、并且微控制器的一些回复会丢失。 我需要在 UART0上保持115200bps 的波特率。

    -链接文件指定以下内容
    SRAM (rwx):origin = 0x20000000,length = 0x00008000

    SRAM 确实会以0x2000.8000结束。

    -当在 UART0或 UART2上接收到字节时、它们将被放置在环形缓冲器中。 然后启动一个任务。 该任务会创建缓冲区、并从环形缓冲区提取接收到的字节进行处理。 UART0会创建一个接收缓冲区和一个发送缓冲区、每个缓冲区的大小为180。 这是因为除此测试用例外、UART0还处理各种各样的其他消息。 UART0上的任何其他消息都不会以1000Hz 的频率发送、仅此测试用例状态命令即可。 UART2创建大小为64的缓冲器、用于从陀螺仪接收数据报。 数据应始终适合该缓冲区、因此这不是问题。

    这些缓冲器看起来不像 SRAM 中的非常大的缓冲器。 如果这是由于 SRAM "溢出"而产生的故障、我猜微控制器在第二个命令进入时尚未完成第一个命令的处理。 然后在第一个和第二个命令完成之前进入第三个命令。 等等。

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

    这第二个回答在(所需)细节和清晰度方面"排在第一位-同样做得很好。

    我建议您在您认为您的缓冲区需要的"顶部 SRAM 位置"上方放置一小段测试代码-可能接近200字节左右。 如果到达该 SRAM 位置、请让代码"暂停进程"。 通过这种方式、您应该能够确定缓冲区的"方式、位置和原因"(泄漏-超出规定范围)。

    您的"缓冲器设计目标"不应该是"禁止超过缓冲器的专用 SRAM 范围?"   此类强制似乎尚未驻留-邀请(及时)此类 SRAM 溢出...

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

    我的第一个想法是、创建缓冲区时、您释放池中使用的缓冲区。 由于降低 UART 速率似乎可以解决问题(尽管对于 FaultISR 出现之前的时间仍然存在疑问)、情况可能不是这样、但 CB1的帖子显示了查看是否存在内存泄漏是合理的。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢 CB1。 只需尝试提供适当的信息、以便您的时间(以及我自己的时间!) 不会浪费。 我感谢各位的答复。  

    在创建检查/停止方面...

    uint8* overflowptr =(uint8*) 0x20007F38;
    uint8 tempRxBuffer[180];
    if (tempRxBuffer >= overflowptr)
    {
    while (1);//停止
    
    } 

    这是正确的方法吗? 我是否会对每个大型数组声明执行相同的操作?

    此致、

    CamK

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

    相信您"有了这个想法"、您必须用">="而不是仅用"="进行测试!

    我会将溢出错误10-20字节(超出/超过)定位为"最大预期缓冲区填充位置"、以便您能够更快地检测到此类"泄漏"、从而确定问题的原因。

    我们"知道"(现在)波特率和消息速率会影响您的问题的发生-您"提出两个问题"、以便问题更快、更显著地发生、这是否是值得的?