• 状态
  • 已锁定 已锁定
  • 回复 25 回复
  • 订户 0 订户
  • 视图 1050 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] TM4C1297NCZAD：在已部署的设备中处理 NMI、故障中断和默认中断的正确方法

admin
Guru**** 2465890 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/665704/tm4c1297nczad-the-proper-way-to-handle-nmi-fault-interrupt-and-default-interrupts-in-deployed-equipment

器件型号：TM4C1297NCZAD
主题中讨论的其他器件：TM4C123

我没有这款处理器的经验、但我正在查看一些代码、这似乎不是为已部署系统(未连接调试器)处理这些中断的最佳方法。

有什么建议或意见？

//============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
//这是当处理器接收到 NMI 时被调用的代码。 这种情况
//只需进入无限循环，保持系统状态以供检查
//由调试器执行。
//============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
静态空
NmiSR (空)
｛
//
//输入无限循环。
//
while (1)
｛
｝
｝
//============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
//这是处理器收到故障时调用的代码
//中断。 这只是进入一个无限循环、从而保持系统状态
//供调试器检查。
//============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
静态空
FaultISR (空)
｛
//
//输入无限循环。
//
while (1)
｛
｝
｝
//============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
//这是处理器收到意外时调用的代码
//中断。 这只是进入一个无限循环、从而保持系统状态
//供调试器检查。
//============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
静态空
IntDefaultHandler (空)
｛
//
//进入无限循环。
//
while (1)
｛
｝
｝

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

    您是正确的-但有供应商文档建议、"登录此类"分离的容器"应允许"附加代码"尝试更正情况"、然后"重置 MCU"。

    "此类问题的细分"使创建的"纠正策略"大大减少。

    还值得注意的是、经过适当设计的"看门狗"应该从这些循环中"逃脱一个"。。   (但"没有任何(进一步)纠正机制...")

  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我们遇到了一个问题、我认为看门狗会导致我们复位。 我们只是不知道代码的哪个部分导致了无限循环。 正确设计的看门狗是否会告诉您导致问题的代码是哪一部分、还是只是导致复位？
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我认为、API 包含的函数使用户能够"确定此类复位的原因"。    (在撰写此文档后-我认为它无法正确解决您的问题。)

    [引用 user="Mark sheats"]我们只是不知道代码的哪个部分导致了无限循环

    您不能设置一个唯一的位、而每个"无限段"中都有这样的位吗？    这样可以在看门狗代码中进行测试/检查-不能吗？

    通过正确构建(纠正)的操作来"退出循环"似乎更可取-避免看门狗进入...

  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我到目前为止还没有处理过这个代码(我还没有自己编译)、但希望很快能处理。 我正在寻找指导、以便我能够提出好的建议来帮助我们解决问题。 我几年前用不同的工具、不同的处理器等编写了代码
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    怀疑所提供的指南：

    • 在具有这样 的无限循环时设置一些独特的识别因子
    • 从每个 无限循环中的 w/开始-启动正确的"纠正措施尝试" (从而逃逸该循环)

    合理满足 您确定的"指导要求"。   祝你有机会。

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

    您无法设置正常变量、因为堆栈变量将在复位时丢失。 您需要写入闪存或 EEPROM 以记录这些循环。

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

    希望您(有意)将您的写操作直接发送给该线程的发起方。   我们的团队没有遇到此类问题。   (至少-尚未！)

    另外请注意、我们的"纠正措施启动"在任何重置之前就会发生、因此 我们的"识别变量"是"有效且正常"。

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

    感谢您的建议。 我不确定我们是否"无意中遇到需要显式启用的中断"。 我刚开始项目、试图掌控一切。 但是... 我们将看到。 内部的另一个程序员在该处理器系列方面的经验要比 I 丰富得多 我是该仪器上一版本的专家。

    我们已经讨论了向闪存写入内容。 我希望写入可以在处理器复位之前完成。

    谢谢、

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

    我说的都不是100%正确。 很少有人明确地犯错。 所有语句似乎都带有星号...

    我始终点击底部的"回复"按钮。 不是定向信息。

  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    CB1_MOBILE、很抱歉我的初级问题。 您是否能够在启动纠正措施时完全避免重置？
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [报价用户="Mark sheats"]您是否能够在启动纠正措施时避免完全重置？

    我还在"寻找" 一个(更多)熟练的"顾问。   (对某些人来说、将过去的技术公司公开似乎"不足"！)

    参加了工程与法学院的课程-您的问题"完全避免重置"-会导致不适！    什么以及谁定义了"完全"？   如果明天发生"复位"会怎样？

    我要指出，"最常"(而且总是)我们"避免重置"。   而且-在"高电流、噪声保证环境"(自动和无绳电动工具自主设计)中、这种能力非常重要。

    您的问题"不是新手"-您"对问题的预期"-在问题发生之前-然后、"设计适当高效的"纠正措施"-描述(大部分)我们(持续)的成功...

  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是的、但确实需要对您的部件进行处理。 我知道我之前已经写过这篇文章、但现在我找不到参考。 稍后、当我有更多的时间时、我会在上面发布更多内容。

    Robert
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    谢谢你。 我期待您或其他人提供有关处理这些类型中断的最佳做法以及可能时的实际详细信息的更多信息。 我们的计划之一是在战略位置插入一些诊断代码、看看我们是否能够弄清为什么事情会被锁定。
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我应该补充一点，我的小组认为能够"引起这样的问题"是"特别有用的"！   (即导致此类问题/发生(几乎)"命令时！")

    当这些问题"短暂"----它们的"原因和解决办法"----变得更加难以确定----并减少/防止。  

    请注意、海报/朋友 Robert 和我都是"测试驱动型发展"的大支持者。 (TDD)  我们都推荐 James Grenning 编写的"嵌入式 C 的测试驱动开发"一书。

    我们发现、当财富微笑时、"合适(甚至更好)的启发式测试"可能会极大地帮助"淘汰"、甚至是 "难以发现-问题的原因！"   (和分辨率！)

  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    非常感谢。 这很有帮助。
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Mark、

    我找不到我之前关于看门狗和复位的注释。 因此、从零开始、这就是我认为目前看门狗和意外中断的最佳做法。 假设您已经清除了尽可能多的案例、这是为了捕捉测试未发现的遗留的杂散中间帐篷(尽管相同的技术也有助于测试)。

    意外中断

    所有意外中断在中断被关闭时进入无限循环、或者它们直接触发复位。 无限循环预计会触发看门狗。 由于这不是正常的或预期的中断、因此出现了非常错误的情况、您无法信任微控制器的状态。  在它们进入无限循环(或复位)之前、它们执行两个操作。

    它们将值写入一组保留位置、以指示发生了意外中断以及发生了哪个中断(对于某些处理器故障中断、您也可以记录其他信息以帮助后续诊断)

    如果您可以通过简单的 I/O 来保护系统安全、则例程也会这样做。 请注意、这通常很困难、因为您不知道系统处于什么状态。 这也是您在硬件设计中需要考虑的问题(例如提供输出以悬空所有功率驱动器)

    看门狗

    看门狗运行一个多级过程来检查所有关键线程。 物理看门狗的时间设置为最快的监视过程(在我的情况下是10kHz A/D 过程、因此我要将看门狗复位时间设置为大约150或200uS、您可以根据您的过程容差设置更严格或更宽松)。 现在、在该过程中、看门狗有条件地馈送。 看门狗的馈送不仅取决于这个快速处理(或中断)的条件、也取决于其它处理软件看门狗。 这种快速处理看门狗馈送会检查每个 SW 看门狗是否过期(通常通过递减"计时器"并查找下溢来实现)。 如果任何软件看门狗已过期、则不馈送硬件看门狗、并且将超时复位处理器。 如果任何 SW 看门狗已过期、则其 ID 将写入前面提到的保留位置。

    每个 SW 看门狗由其观察的过程/循环定期复位(馈入)。 因此、一个预期每10次(即频率的1/10)运行一次的循环 HW 看门狗所监视的快速关键过程您可以在循环运行时将计数器设置为12或15。

    启动时(复位后)、您需要执行几项检查。

    • 读取复位原因寄存器和保留位置。 以某种方式记录此信息。
    • 然后、将保留位置设置为由于报告而不具有的某些值(通常为位全为零或全为一)、并清除复位原因寄存器。
    • 然后、您继续执行其余的启动操作。

    有几个地方可以对此进行一些微调。

    • 我在 SW 看门狗计时器上使用 ECC 代码、以降低通配写入作为看门狗馈送的几率。 无效值被视为看门狗超时
    • 软件看门狗会被忽略、直到第一次喂入。 这允许进行任何所需的初始化。

    在这种意外中断和所有关键进程(通常还有一些不那么关键)被监视的情况下、无论复位的原因如何、都将收集并希望记录这些中断的记录。 虽然收集的信息可能无法立即诊断问题、但它应缩小您正在查看的区域、并且可以扩展信息以帮助进一步诊断、以限制您收集和存储信息的能力。

    Robert

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

    布拉沃-我被告知我的“手拍”-从尼亚加拉(尼亚加拉)的(适当的)一侧-在加拿大听到了(穿过瀑布)。
    您可能想提及"我们"青睐的方法、即"写入快速响应、非易失性、外部存储器"、以保持这些关键/关键值、并采用更加安全且(无勘误)的合作器件...

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

    [引用 user="CB1_MOBIST"]您可能想在更安全且(无勘误)的合作设备中提及"我们"的首选方法"写入快速响应、非易失性、外部存储器"以保存这些关键/关键值...[/quot]

    好的地方。 复位后的复位原因记录在该过程中、部分是为了减少时序注意事项。 外部存储器速度更快、更可靠(尤其是 FRAM)、因此将其用于记录是一个相当大的优势。 该过程与使用哪个处理器无关(除了并非所有处理器都能区分复位源)

    BTW、我已成功地使用此技术在现场诊断 TM4C123欠压电路中的过灵敏度*。

    Robert

    *进行比较

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

    您是否可以通过连接到 CPL 来实现任何此类"欠压、过灵敏度"？   (加拿大电力和光...)
    最后一次去温哥华——向上帝发誓——62英寸平板电视缩小到~40英寸——在 CPL 让我们(所有人)进入黑暗之前，以这种方式跑了一个小时……

    (电力公司的名称是虚构的-"Brown to Black-Out"不是！)

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

    在这种特定情况下、反向更令人担忧。 噪声都是内部源。 动力稳定、在能力边缘没有任何变化。 不同位置的电路板显示了不同的发生频率。 从所有外观来看、欠压电路都响应了传导噪声、功率实际上并没有降低。

    外部监控器(我是否曾提到过我不信任微控制器上的复位电路？) 从未跳闸。 解决方案是多管齐下的

    • 电路板布局修复(这是第一块运行电路板)
    • 增加铁氧体以降低传导噪声
    • 禁用掉电

    Robert

  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    感谢大家的宝贵意见。 这为我提供了一些非常有用的提示、我们将在接下来的几天内努力工作... 希望我们能在一周内找到并解决这个问题！！！
  • 0
    TI__Guru**** 2465890 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用 user="Robert Adsett"]我是否曾提到过："我不信任微控制器上的复位电路？"[/quot]

    也许... 也许... 好的——“经常”——甚至布鲁诺(和 Univ 学生路易斯)——都在葡萄牙——现在，“强迫这种 外部主管”——他们所遇到的一切！

    我们的同事-出席"您的预定电路板停用"-报告： "我们来(不)称赞欠压电路-但埋葬它..."

    似乎是那种破的，千禧一代的工作人员，现在， “拥有”……  "长寿命监控器和快速、非易失性、无勘误的外部存储器..."

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

    Robert Adsett 说：
    禁用掉电



    您为什么这么做？ 关闭错误检测似乎不是处理问题的适当方法。

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

    [引用用户="Peter Borenstein"]

    Robert Adsett
    禁用掉电

    您为什么这么做？ 关闭错误检测似乎不是处理问题的适当方法。

    [/报价]

    我认为案文中我很清楚。 它被关闭是因为它引入了虚假警报。 我在任何情况下都不依赖他们提供保护、其他地方也提供了适当的电源保护。

    裤子不仅被皮带和悬架固定、而且还被几个纸夹固定。 我刚刚取下了纸夹、因为它们在抽血。

    Robert

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

    一般而言-我同意。 然而、在海报 Robert 的案例中、他(仔细)分析了/分析了"掉电"电路(MCU 中的电路)似乎是"因果关系"。

    您是否建议"继续使用"失败/失败的"检测方法？"   (仅因为它存在？)   这似乎-不太合适-