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.

[参考译文] TM4C1294NCPDT:TM4C1294 MCU 无法访问、并且可能内核挂起

Guru**** 2482225 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/720996/tm4c1294ncpdt-tm4c1294-mcu-is-not-reachable-and-likely-core-hung

器件型号:TM4C1294NCPDT

您好!

我们从客户部署中发现问题、即 几天后无法访问 TM4C1294 MCU、并且可能发生内核挂起。
TM4C1294通过 UART 接口与嵌入式 CPU (通信处理器)相连。 已尝试从复位 UART 接口
嵌入式 CPU、它没有帮助。

我有以下问题、  

TM4C1294是否支持内核转储机制?

2.当 TM4C1294卡住时、是否可以从嵌入式 CPU 收集内核转储?

由于它在客户网站上、我们无法连接 CCS。 您是否有任何其他建议来找出根本原因或避免此问题?

谢谢、
SENTHIL  

如何为 TM4C1294生成内核转储

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

    [报价用户="Senshil Paramasivam"]几天后无法访问 TM4C1294 MCU、且可能内核挂起。[/quot]

    也许这是事实、但您在这种(核心挂起)诊断的进展中提供了(非常)最低限度的证据。

    是否可以采用以下方法-部署哪些"探头(赦免)"更好的声音和详细诊断"?

    • 向 TM4C 添加定期切换的 LED (快速)可识别任何"严重"的功能丧失。  (测试 MCU:计时器、GPIO 和中断!)
    • 您会注意到、"已尝试从嵌入式(通信处理器)重置 UART 接口。"   您是否还应该尝试"重置 TM4C 的 UART " ?  
    • 它证明了"建议"-在开发期间-创建"活动测试"-此"监控单个 MCU 外设"-并提供"外设恢复"-在需要时/如果需要...
    • 作为"标准操作程序"-您不应该有"黄金客户端板"(或最近的传真-@ 您的站点)-以便您可以"连接 CCS"-和"直接观察此(或其他)情况?"
    • 这些 "板"在"总现场人口"中所占的百分比是多少?   这很重要-不是吗?

    对核心转储的"推动"(即使有)似乎(非常)为时过早、并且与上述方法"秒"(详细)远。   (当然、除非深入了解"核心转储"、否则证明"隐藏"目标...)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!
    本身没有内核转储功能。 如果您可以通过调试器连接到处理器、则可以观察处理器寄存器和存储器以诊断问题。 CB1提供了出色的诊断建议。 LED 切换将是了解内核是否挂起的好方法。 当与嵌入式 CPU 通信的特定 UART 死区时、是否还有其他外设(例如其他 UART、SPI、计时器等)仍在运行? 我有一个非常重要的问题、就是这种故障是可重复的还是一次性的? MCU 需要在哪种类型的工作环境中运行? 需要检查的是噪声、温度、稳定的电源? 是否超出规格? 我还可能会产生软错误、该软错误会损坏存储器位单元和寄存器免受辐射的影响。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢 CB1的见解。 请参见内联。

    向 TM4C 添加定期切换的 LED (快速)可识别任何"严重"的功能丧失。 (测试 MCU:计时器、GPIO 和中断!)
    好主意。 我们可以定期验证计时器和 GPIO 访问、并切换 LED。 您建议如何验证中断?

    您会注意到、"已尝试从嵌入式(通信处理器)重置 UART 接口。" 您是否还应该尝试"重置 TM4C 的 UART "?
    在我们的设计中、我们只需通过 UART 接口从嵌入式 CPU 访问 TM4C。 无直接访问。 在这种情况下、我们无法从嵌入式电路板访问 TM4C、因此尝试在嵌入式侧重置 UART。

    它证明了"建议"-在开发期间-创建"活动测试"-此"监控单个 MCU 外设"-并提供"外设恢复"-在需要时/如果需要...
    好主意、我们会将它们包括在内。

    作为"标准操作程序"-您不应该有"黄金客户端板"(或最近的传真-@您的站点)-以便您可以"连接 CCS"-和"直接观察此(或其他)情况?"
    是的、我们在本地确实有黄金板、但到目前为止我们还没有看到这个问题。

    这些"板"在"总现场人口"中所占的百分比是多少? 这很重要-不是吗?
    这并不重要。 我们没有大量的样片可供总结、仅在客户设置多次时才发现此问题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢 Charles 的建议。 如果设置为本地设置、但不用于调试客户问题、LED 切换将有所帮助。 由于与 MCU 的通信中断、因此很难确认其他外设是否正常工作。 在过去一个月中、我们的一个客户设置中发现了至少4或5次此问题、但在本地设置或其他客户中未发现此问题。 根据所有测试观察结果、它在正常条件下以稳定的功率、温度等运行 如何确认是否存在软错误? TM4C 是否具有奇偶校验错误中断或计数器? 哪些内存容易出现这些错误? 是否有校正逻辑(ECC)?

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

    如何在远程系统上配置看门狗计时器。 默认配置应在第二次超时时软复位 MCU、并可用于观察 NMI 引脚。 理想情况下、您可以让软件检查 MCU 复位原因寄存器、并在 POR 之后通过 UART 将(转储)原因打印到调试终端。

    另一种方法是在编译代码中启用 Debug 指令开关、以便以类似的方式确定违规的应用程序或 Tivaware 库调用的内容。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您-回答如下:  (CB1的初步建议 CB1的后续回应)

    [引用 user="Senshil Paramasivam">向 TM4C 添加定期切换的 LED (快速)可识别任何"显著"的功能丧失。 (测试 MCU:计时器、GPIO 和中断!)
    好主意。 我们可以定期验证计时器和 GPIO 访问、并切换 LED。 您建议如何验证中断?

    这很简单-因为目标是"评估尽可能多(合理地)的 MCU 系统元件"-只需让(所选)定时器的周期性"中断"调用"X-OR"GPIO 即可。   因此... 三只鸟— “单 (CB1)石头”。   (通过计时器、GPIO 和中断全部(定期)测试并清楚地进行监控!)   如果 LED 指示灯继续闪烁-"悬挂核心"为(已解除)实际结果。

    [引用 user="Senshil Paramasivam">您是否还没有尝试过"重置 TM4C 的 UART"?
    在我们的设计中、我们只需通过 UART 接口从嵌入式 CPU 访问 TM4C。 无直接访问。 在这种情况下、我们无法从嵌入式电路板访问 TM4C、因此尝试在嵌入式侧重置 UART。

    MCU 的 UART 在加电后正常运行后"立即退出"是很少见的。  从基础知识开始-(MCU 上)信号电平最近是否被测量并确认为"w/in spec?"  在我们公司的许多/大部分设计中-我们(通过计时器)对 UART 进行编程、使 其使用其所连接的设备定期进行"握手(*)"(除非交易活动(两者都是)高电平且最新!)  当检测到足够长的"安静"时间时- MCU 将"握手"(*) -并等待响应。   如果该响应未能到达或出现(某种方式)损坏、则 MCU 的 UART 将执行"外设复位"-重新初始化-并尝试新的握手。(*)  这涉及在您的设计中添加此类"扩展和提高稳健性"代码策略。   

    [引用 USER="Senshil Paramasivam]*在开发过程中、创建"活动测试"(哪些是"监控单个 MCU 外设")并提供"外设恢复"(如有必要、如有必要、)...
    好主意、我们将包括这些内容。[/引述]

    好极了!   响应(如上所述)注释(一种方法)以实现"活动测试"、"使 MCU 能够"发现问题"、并"智能地尝试修复"。   另请注意-可以 对每种"问题检测"进行编程、以便在"CU 监控指示灯"上生成唯一的模式-宣布问题-并"恢复正常"-"修复"何时成功或应该成功!   此外-它(始终)证明是明智的-"通知"连接的(处理器或板)- MCU 发现了一些问题-尝试"修复"-然后发出"修复"完成信号...

    [引用 user="Senshil Paramasivam">并且-这些"板板"在您的"现场总人口"中所占比例是多少? 这很重要-不是吗?
    这并不重要。   我们没有大量的样片可供总结、并且仅在客户设置中多次发现此问题。

    可能需要注意的是、这里的许多人会质疑您对"不重要!"的评估   如果样本大小如此小-那么(任何)故障证明"严重"-并且(迄今为止)"发现此类缺陷的发现有限"-可能比"缺陷"(扩展)的存在更多地反映您/客户的"检测技术和/或努力"!   我相信这句格言 "索瑞号"(非常)非常适用-在这里...

    另一个注释"看门狗使用情况"-(CAN)导致完全 MCU 复位-并且(复位)证明比此处概述的"专用且重点突出的基于外设的技术"更"中断和耗时"。   当然- W-Dog 提供 了"没有关键见解"-此处介绍的"重点更突出/更有效"诊断方法做得好...

    (*)"握手"(如此处所述)不涉及"流量控制"或其他(额外)信号。   此处的用法描述了一个(非常)简短的"UART 交换"-在 MCU 和远程设备之间-以确保通信"存在、是双向的-并且是正确的..."

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

    这很简单-因为目标是"评估尽可能多(合理地)的 MCU 系统元件"-只需让(所选)定时器的周期性"中断"调用"X-OR"GPIO 即可。 因此... 三只鸟—“单(CB1)石头”。 (已通过计时器、GPIO 和中断全部(定期)测试并清楚地进行监控!) 如果 LED 指示灯继续闪烁-"悬挂核心"为(已解除)实际结果。

    听起来不错。 将尝试此选项。


    MCU 的 UART 在加电后正常运行后"立即退出"是很少见的。 从基础知识开始-(MCU 上)信号电平最近是否被测量并确认为"w/in spec?" 在我们公司的许多/大部分设计中-我们(通过计时器)对 UART 进行编程、使其使用其所连接的设备定期进行"握手(*)"(除非交易活动(两者都是)高电平且最新!) 当检测到足够长的"安静"时间时- MCU 将"握手"(*)-并等待响应。 如果该响应未能到达或出现(某种方式)损坏、则 MCU 的 UART 将执行"外设复位"-重新初始化-并尝试新的握手。(*)这涉及在您的设计中添加此类"扩展和提高稳健性"代码策略。

    当您说"外设复位"时、您是指在 UART 中连接的嵌入式 CPU (器件)复位、还是仅指复位 UART 接口? 最好在这两个器件之间定期进行心跳或握手并进行复位。


    好极了! 响应(如上所述)注释(一种方法)以实现"活动测试"、"使 MCU 能够"发现问题"、并"智能地尝试修复"。 另请注意-可以对每种"问题检测"进行编程、以便在"CU 监控指示灯"上生成唯一的模式-宣布问题-并"恢复正常"-"修复"何时成功或应该成功! 此外-它(始终)证明是明智的-"通知"连接的(处理器或板)- MCU 发现了一些问题-尝试"修复"-然后发出"修复"完成信号...

    最好在这两个设备之间定期进行心跳或握手、并在出现问题时尝试自动恢复。


    可能需要注意的是、这里的许多人会质疑您对"不重要!"的评估 如果样本大小如此小-那么(任何)故障证明"严重"-并且(迄今为止)"发现此类缺陷的发现有限"-可能比"缺陷"(扩展)的存在更多地反映您/客户的"检测技术和/或努力"! 我相信这句格言"索瑞号"(非常)非常适用-在这里...

    是的、目前样本大小非常小。


    另一个注释"看门狗使用情况"-(CAN)导致完全 MCU 复位-并且(复位)证明比此处概述的"专用且重点突出的基于外设的技术"更"中断和耗时"。 当然- W-Dog 提供了"没有关键见解"-此处介绍的"重点更突出/更有效"诊断方法做得好...

    是的、我们已经计划启用看门狗、但今天没有启用
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    如何在远程系统上配置看门狗计时器。 默认配置应在第二次超时时软复位 MCU、并可用于观察 NMI 引脚。

    我们计划启用今天缺失的看门狗。 您能否提供示例代码或指针来观察带看门狗的 NMI 引脚?


    理想情况下、您可以让软件检查 MCU 复位原因寄存器、并在 POR 之后通过 UART 将(转储)原因打印到调试终端。

    好的、将检查复位原因(RESC)寄存器。 由于我们在 MCU 挂起以恢复后进行了下电上电、因此可能的复位原因会将电源复位记录为一个原因、因此它可能不会提供太多新的信息。


    另一种方法是在编译代码中启用 Debug 指令开关、以便以类似的方式确定违规的应用程序或 Tivaware 库调用的内容。

    您能否提供启用调试指令开关的示例? 它是否在控制台上打印所有调试消息? 它如何帮助查找有问题的应用程序或 Tivaware 库调用?

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

    也许(现在)是时候出现"这个已解决"的绿色标记了!   (请注意、供应商已注册具有此类指导的"愉快"。)

    当您说"外设复位"时、您是指在 UART 中连接的嵌入式 CPU (器件)复位、还是仅指复位 UART 接口?

    我特意采用了"外设复位"来区分"UART 外设复位"。   (此类"独立外设复位"比整个 MCU 复位更快且干扰更小。)   此外、它们可能会单独 "计数" 、从而提供对潜在问题的见解: "程序、组件或系统"问题!

    我应该注意的是、我们的公司(通常)包含一个小型(外部) EEPROM (故意不包含在 MCU 中)、并且该器件会"加载"相关的"无关信息"、该信息可提供关键数据-即使电路板已离开(由客户拥有)。

    摆脱了(早期)"核心挂起"(SENSE)-您现在应该更好地准备好产生更强大的设计-并且可能有一个能够"发现(甚至)克服并记录"(问题)的设计-而不是... 运行盲...

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

    就像 包含 CB1 最近 的各种彩色文本 一样 、阅读起来非常愉快。  除了火星任务调试程序外,他还建议 地球引力非常重。

    针对 Tivaware 控制台的调试显示:

    #define debug 1 
    //
    //
    //如果驱动程序库遇到错误,则调用的错误例程。
    ////
    *****************
    
    #ifdef debug
    void
    __error__(char *pcFilename、uint32_t ui32Line)
    {
    
    #endif
    
    
    UARTprintf ("assert_debug:%s 行:%d %s\r\n"、msg、__line__、__file__) 

    可以在 C:\ti\Tivaed\MyLibraryVerison\examples 中找到看门狗示例工程。 NMI 引脚默认 PD7 必须配置为看门狗使用(请参阅数据表中的 SYSCTRL 寄存器文本)、 软件模拟 POR 、并且可以从其他器件远程触发。  如果    通过 看门狗 处理 NMI 进行配置、某些异常似乎也可能以某种方式触发 NMI 中断。  该部分高于我目前的薪酬等级、 也许 Charles/CB1会鸣响如何实现这一目标。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    想法是看门狗第一次超时可以复位任何外设。 对外设的调用也会刷新狗计数器、以防止其过期。 它们将其称为宠物犬、喂狗、我们在第二个超时功能上禁用 MCU 复位。