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.

[参考译文] TM4C129ENCPDT:检测坏 RTC 晶体或其他

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/899098/tm4c129encpdt-detect-bad-rtc-crystal-or-other

器件型号:TM4C129ENCPDT

是否有任何方法可以检测 RTC (实时时钟) 晶体是否损坏? 是否有任何方法可以检测 RTC 时钟源的其他方面不能用于看门狗?

我看到测试 HIBRIS.WC 位使晶振稳定的示例代码。 这种方法是否保证能够检测到坏晶体或其他时钟故障? 在确定存在不可恢复的错误(不使用回退时钟源)之前、应将等待该位设置的时间视为足够长的时间?

在这个特定的应用中、除了安全装置之外、RTC 不被用于任何其它操作。 换言之、不使用挂钟或时间日函数。 因此、如果 RTC 发生故障、则不会有很大的损耗来解决缺失的特性。 但是、看门狗本身很重要、如果可能、它必须工作、如果它不工作、则必须被检测。 因此、如果有一种方法来检测发生故障的 RTC、那么看门狗可以以相同的速度返回到精度较低的 HIB LFIOSC。 后者已经过充分测试、但精度不是首选。 至少如果 RTC 中断、LFIOSC 可以在标称值的-70%到+127%范围内执行。

额外的信用用于检测实时时的 RTC 故障、但我认为这可能需要定期测试-我看不出它是如何自动的、因为如果启动后 RTC 发生故障、看门狗将停止工作。

P.S. 我注意到、在等待晶振稳定之后、我在 TivaWare 中找到的示例代码将休眠振荡器设置为低驱动模式。 这是正确的顺序吗? 这不应该首先完成? 数据表显示、在休眠振荡器运行后不应更改驱动器、因此这看起来很可疑。 但是、直到之后、示例代码才会启用 RTC 或将其选择为计数器模式、因此可能所有操作都很好。 也就是说、在设置驱动器之前等待晶振稳定、但在驱动器级别之后进行所有其他设置是否正确?

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

    您好 Brian、

     您是否有机会将 RTC 故障检测为篡改事件。 请参阅以下摘录。 您可能能够在看门狗过期之前检测 RTC 故障

     在我熟悉的另一个 TI MCU 中、有一个片上频率计数器、该计数器将采用两个时钟源(例如 RTC 时钟和 MOSC)并不断对它们进行比较。 如果被测时钟源偏离了基准时钟、那么它被检测为一个故障。 这是定期完成的。 但是、Tiva 器件中不提供此功能。

     但是、我可以想象您设置了一个将周期性中断的计时器(SysTick 或 GPTM)。 在中断中、您将读取看门狗值寄存器(WDTVALUE)、并查看与预期相符的已用计数。 这也可能会发出早期警告。 如果您未通过早期警告测试、则可以在 WD 过期之前回退到 LFIOSC。  

      

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

    额外的信用问候(  用于检测实时时钟发生故障)  年轻员工的飞行手(他们不在学校)唤醒了公司的转变!   (ET Moi)

    在我们公司的多种设计中、"将 xtal 输出捆扎到(两者都)其预期的 MCU 源和适当的缓冲器、"可以检测到外部晶体(或振荡器)故障(或偏差)。   (缓冲输出然后"馈送" MCU 未使用的计时器输入之一。)

    在我们的情况下、我们通常至少有一个空闲缓冲级-因此、严格而言、可能(始终)不需要。

    众所周知、晶体/振荡器频率-我们只是测试"偏差超出标准"-发出"晶体问题!"信号   这种方法成功地检测了"晶体温度和冲击/振动弱点!"   (我们的多个设计都是基于国防的-如果有这种要求!)

    供应商 Charles 的"看门狗比较"理念超出了(即出卖人)我们的想法-我们可能需要"借入和并入"(即偷窃)...   害怕而不是查尔斯 您的(几乎)无病毒检查(尚未)"已在邮件中丢失..."   (该死的邮局!)

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

    谢谢、Charles。

    篡改检测系统可以检测 RTC 中的*后续*故障,该系统是否还能检测初始故障? 换言之、我认为每次冷启动时都需要检查 RTC 是否工作、如果工作正常、则立即返回。

    如果 RTC 在冷启动时表现良好、则篡改检测应能够在 RTC 稍后发生故障时使看门狗恢复到 LFIOSC。

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

    您好 Brian、

     我认为在启动时、您可以启用防篡改模块、但不能启用防篡改 I/O 引脚。 换言之、不要让任何 tamp I/O 引脚产生篡改事件、而是基于 RTC 导致篡改事件。 根据数据表、自动切换到 LFIOSC。  

    防篡改时钟
    休眠时钟是防篡改模块的时钟源。 外部振荡器时的振荡器频率
    启用防篡改功能后、防篡改模块将监控外部振荡器。 如果是外部的
    由于任何原因振荡器停止、HIBTPSTAT 寄存器的 XOSCFAIL 位和休眠状态被置位
    时钟源立即切换到 HIB LFIOSC。 当 HIBTPSTAT 中的 XOSCST 位时
    寄存器为0、表示外部振荡器处于活动状态、可以向 XOSCFAIL 位写入1
    将其清除并重新启用外部32.768kHz 振荡器。

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

    您好、Charles、

    是否可以询问"如果外部 振荡器因任何原因停止"。 是否知道是否已检查(仅限)振荡器停止?

    海报没有明确说明他定义的"坏 RTC 晶体"。   我们怀疑"坏 RTC 晶体电路"(包括旁路电容器)增强了功能)

    我们的集团注意到:

    • 不可接受的随温度变化的频率漂移(偶数移位)
    • 与以上相同-由于海拔高度
    • 简介-但由于冲击/振动而影响频率偏移

    根据这些条件的振幅和持续时间、RTC 的精度可能会受到影响。   如果仅选中"Stoppage"、则我的小组先前建议的方法看起来更强大(更全面)的替代方法...

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

    您好 CB1、

     您的疑虑是有效的。 数据表并未将外部振荡器停止作为故障条件进行详细阐述。 因此、我不知道外部振荡器的运行速度是否太快(最高频率)或太慢(最低频率)将被检测到。 Brian 对32.768kHz 振荡器的主要用途是为看门狗供电。 如果他为看门狗超时周期增加了一些裕度、那么我认为它应该处理过快的情况。 因此、如果目的是能够生成一个 WD NMI 或者复位、那么振荡器频率上的某些偏差也许是可以接受的。 当 XOSC 发生故障时、内部 LFIOSC 被切换、其精度极差。 Brian 必须在看门狗超时中考虑这一点。  

     尽管如此、您的解决方案是一个很好的建议。 我先前建议使用在基准时钟上运行的 SysTick /GPTM 定期检查 XOSC 频率、这也可以考虑。  

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

    您好、Charles、

    感谢您-一如既往地感谢您的见解和指导。

    年轻员工回顾我"提醒"(他们的词-"硬化")、"早期发现"对于以下方面的重要性:

    • MCU 功能不正确(即超出规格)
    • 和/或特别是"性能故障"
      • 由 MCU 提供
      • 它的外设
      • 或其他(非 MCU)关键系统组件或子系统。

    员工注意到、"海报承诺为"检测 RTC 故障"提供额外信贷-通过他们的建议(已获得"无信贷")完成(仅限于)、但仅凭其应得的额外信贷!   聪明/资源丰富的年轻人(真的)应该(适当的)得到服务!   (奖励)

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

    谢谢、Charles。 我刚刚阅读了第540页的注释、其中说明"休眠时钟输入故障检测、检测时切换到内部振荡器。"

    我不确定是否需要启用篡改中断并提供中断处理程序。 但是、我将至少启用此功能以读取 HIB_TPSTAT 中的 XOSCST 位、以便记录故障。 实际上、在该中断中、似乎有必要显式地将看门狗时钟源从 RTCOSC 更改为 LFIOSC、因为即使休眠篡改模块将自动切换、我也不相信看门狗模块也会自动切换。

    这些特性一旦被执行、就必须进行测试、所以我想弄清楚如何暂时使晶体"失效"、而不会永久切断引线或进行不可逆转的更改。 如有任何测试建议、我们将不胜感激。 我假设 XOSC0输入临时接地可能是触发篡改检测的无损方式。

    我认为我不会将固件设计为向 XOSCFAIL 写入1、但最好知道该选项存在。

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

    您好 Brian、

     您是否有函数发生器来提供 XOSC 输入? 您可以改变频率并停止输入。  

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

    您好、Charles、

    "旁路电容值"中的足够变化通常将"使 XTAL 停止!"   (MCU GPIO 可以在并联旁路电容中(即接地)切换。)   我们当地的美国 实验室定期采用这样的“MCU 禁用技术”... 我们不确定它在32KHz 左右时的效率...

    您可能还会注意到、这证明了一种(某种程度上)"拉动"主(即 HF) XTAL 频率的方法-以及确定"晶体电路:范围、灵敏度和稳健性!"

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

    我们的电路板已经过制造、这是一项固件改进。 由于电路板已经制造、短接 XOSC0比插入函数发生器更容易。 我还有 LaunchPad 板、但我宁愿不损坏那里的32、768 Hz 晶振、因此、短接比连接函数发生器更容易。 我假设 LaunchPad 上的任何跳线都不会断开32、768Hz 晶振、因为如果迹线覆盖如此大的环路、晶振的性能可能会很差。

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

    很抱歉、我添加了一个稍微偏离主题的问题、但:

    防篡改模块是否在 XOSCFAIL 上产生中断?

    篡改模块有一个中断向量、但它是什么类型的中断(NMI 或可屏蔽的)、在这里处理什么事件?

    主 NMI 中断向量是否处理篡改事件以及 NMI 信号? 我看到 PMIC 寄存器中有一个 TAMPER 位来显示防篡改模块是 NMI 的来源、但我不清楚是否应该向我的防篡改 NMI 向量处理程序添加代码、 或者我是否应该为此向篡改向量处理程序添加代码。

    我想也有可能防篡改模块根本不为 XOSCFAIL 提供中断、在这种情况下、我需要轮询中断。 由于固件定期为看门狗计时器提供数据、因此我可以使用该函数轮询 XOSCFAIL 位并在为看门狗提供数据时将看门狗切换到备用时钟源。

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

    [引用用户="Brian Willoughby18"]因此、与附加函数发生器相比、短接更容易。

    您好 Brian、

     您可能可以使用镊子或 CB1的建议来测试 XOSC 故障。  

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

    [引用用户="Brian Willoughby18"]

    防篡改模块是否在 XOSCFAIL 上产生中断?

    篡改模块有一个中断向量、但它是什么类型的中断(NMI 或可屏蔽的)、在这里处理什么事件?

    [/报价]

    是的、您将需要在系统 NMI 处理程序中处理 XOSC NMI。  

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

    谢谢你。

    对于我的仿真、矢量编号91、中断编号75、矢量地址/偏移量0x0000016C 处的防篡改中断的用途是什么? 我似乎不需要它、但我仍然想知道该矢量处理了哪些类型的中断。

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

    我觉得有人建议将 XOSC 管脚中的一个或两个更改为 GPIO、以模拟不良的32、768 Hz 晶振、但最简单的问题是 XOSC0和 XOSC1都是固定的管脚分配。 GPIO 上不会出现两个引脚、因此不能直接将一个或两个晶振引线接地。 换句话说、这些引脚专用于晶体功能、而不是其他功能。

    我意识到、可能可以将晶振引脚连接到常浮型 GPIO、然后有条件地将其接地以进行测试、但我不想更改电路板设计以允许使用该非标准配置。 换言之、浪费第三或第四个引脚来测试和证明篡改功能是没有意义的。 我将手动将 XOSC0接地、并查看它是如何进行测试的。

    我还打算检查看门狗定时器1是否会在休眠外设的防篡改模块切换的同时自动从 RTCOSC 切换到 LFIOSC。 我不确定是否会发生这种情况、因为 RTCOSC 甚至不能作为看门狗计时器1的源、除非启用了专用门、因此我假设这里没有任何自动跟踪。 快速测试应该证明这一点很好。

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

    您好!

    [引用用户="Brian Willoughby18"]我认为有人建议将一个或两个 XOSC 引脚更改为 GPIO 以模拟不良的32、768 Hz 晶振

    否-这不是我们的建议。   而是-芝加哥美国的"SOP"也是如此 实验-第2个旁路电容器与现有的一个晶体旁路电容器(实际上)并联-这完全由 MCU GPIO 命令/控制、通过切换新"嵌入式"旁路电容器的"浮动端"来实现。 接地。   (再次-"添加/导致故障"晶体电路旁路电容器"有一端"焊接到现有旁路电容器之一"(XOSC 已连接)引脚-然后剩余(添加的电容器)引脚"切换至接地"。   

    我们现在将其作为"当然的事"来做-因为它"速度、简化和增强"我们的美国 监管筛查。   (通过我们的预期和执行-简化 UL 测试-甚至我们的"测试成本"优势-这是两个领域中的最佳-不是吗?)

    [引用用户="Brian Willoughby18"]我意识到可能会将晶振引脚连接到常浮型 GPIO、然后有条件地将其接地以进行测试、但我不想更改电路板设计以允许该非标准配置。

    再说一次-这不是我们建议的-我们建议添加一个"添加(即并联)旁路电容器"-足够的值来使晶体停止振荡。   虽然"不改变 PCB 设计"的愿望是合理的-这在前面没有说明过(在本主题中)以及我们集团认为提出的所有替代方法-无法满足我们(更具深远意义且更详尽)的技术所提供的优势...

    [引用 user="Brian Willoughby18"]我将手动接地 XOSC0并查看其如何用于测试。

    这是您的项目、但这是一项特别残酷的测试、可能会导致"意外"损坏、直到下游很长时间才会显示出来。   与风险资本公司合作(正如我们所做的那样)-建议(不)进行此类(潜在损害)"测试"。

    [引用用户="Brian Willoughby18"]为了测试和证明篡改功能、没有任何浪费第三或第四个引脚的感觉。

    我们看不出"单(或双)、献祭 GPIO 引脚"现在是如何升至3 -或(甚至) 4!   我们的建议没有什么!   此外-我们的方法(包括一个为 MCU 定时器引脚馈送信号的缓冲器)-避免了篡改功能可能施加的任何/所有限制(即仅检查振荡器停止!)   组件老化、温度引起的偏差、冲击/振动甚至 MCU 工艺变体均可通过我所在小组(远远早于)所述的方法进行检测...

    总之-您很高兴发现(可能)设计缺陷... 不是很好,似乎不愿意有效地处理它。。。

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

    Charles 是对的。 看门狗当前以 LFIOSC 时钟作为输入运行、其精度很差。 即使 RTCOSC 运行速度快或慢得多、它也不能像 LFIOSC 那样糟糕。 RTC 的完全故障是切换到看门狗的备用时钟源的接地。

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

    我设计了一种方法来检测发生故障或缺少 RTC 时钟源。 通过跳过基于 ROM 的休眠功能、可以在等待写入完成时超时。 如果发生超过1.5秒(1500ms)的事件、则可以重置休眠外设、并且可以在第二次尝试时在 HIBCTL 中设置 OSCSEL。 同时、设置 OSCBYP 和常规 CLK32EN。 这将使用 LFIOSC 运行休眠模块、然后报告 XOSCFAIL 位。

    当 RTC 晶体存在且工作时、防篡改模块将检测 XOSCFAIL 并切换。 根据我到目前为止的测试、似乎无需手动将看门狗定时器2从 RTCOSC 切换到 LFIOSC。 很明显、当休眠模块从 RTCOSC 故障转移到 LFIOSC 时、看门狗定时器2会随之改变。 至少我能够触发固件以无限循环方式挂起、即使 RTC 晶体接地并通过防篡改模块报告 XOSCFAIL、WDT 仍能捕获该固件。

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

    您好 Brian、

     感谢您提出这种检测 XOSC 故障的方法。 如果在1.5秒内未设置 WRC 位、则假设 XOSC 损坏并切换到 LFIOSC。 当其他人提出相同的问题时、我将引用您的帖子。

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

    我在 LaunchPad 上对此进行了测试。 我发现一个小削波与32、768Hz 晶振上的外露引线保持连接、没有直流失调电压。 我假设这连接到 XOSC0。 在上电之前和固件运行期间、我通过将跳线的另一端连接到 LaunchPad 上的其中一个接地引脚并将其断开来测试固件。 它基本上是看门狗测试的修改、但增加了一些防篡改模块。