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.

[参考译文] MSP430F5529:实时时钟与实时时钟校准相关的中断行为

Guru**** 2609955 points
Other Parts Discussed in Thread: MSP430FR5994, MSP430F5529

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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/646921/msp430f5529-real-time-clock-interrupt-behavior-with-respect-to-real-time-clock-calibration

器件型号:MSP430F5529
主题中讨论的其他器件:MSP430FR5994

我正在开发一个数据记录器、旨在从两个不同的传感器(A 和 B)进行测量并存储它们。  传感器"A"记录频率为1Hz、传感器"B"记录频率为64Hz。 这些值没有标记、只是在以重复模式收集时进行存储"ABBB...ABBB... 等)、因此为了解码数据、模式必须重复而不会失败。 代码使用 RT1PSIFG 来生成用于数据收集和存储的64Hz 中断。 64Hz 传感器的时序很紧凑、但它在大多数时间内都能正常工作(请参阅下文)。

记录器设计为一次运行数月、时钟的精度是一个问题。 32768Hz 手表晶体根据基准进行校准。  晶体通常以大约32ppm 的速度缓慢运行、因此为了补偿 RTCALS 被设定为0并且 RTCCAL 被设定为4 (根据勘误表、+32ppm 的调整)。  精度是正确的。  没有问题。

问题是、每隔64分钟、无故障、数据中会出现干扰、其中64Hz 数据不良、看起来传感器 B 的一个或多个64Hz 测量值缺失。 RTC 校准是第一个可疑事件、因为它是在64分钟间隔内发生的唯一事件。  我已阅读并重新阅读用户指南以了解问题并尝试找到解决方案、但我不太理解、我需要一些帮助。  用户指南的相关章节内容如下:  

通过根据 RTCCALS 和定期调整 RT1PS 计数器来完成校准
RTCCALx 设置。 在日历模式中、RT0PS 将标称37268Hz 低频(LF)分频
256倍的晶振时钟输入。 一个64分钟周期具有32768个周期/秒×60秒/分钟×64分钟= 125829120
周期。 因此、频率降低–2ppm (下校准)大约等于添加
每125829120周期额外256个周期(256/125829120 = 2.035ppm)。 这是通过实现的
在64分钟的时间内保持 RT1PS 计数器一个 RT0PS 输出的附加时钟。
类似地、频率增加+4ppm (上校准)大约等于删除512个周期
每125829120周期(512/125829120 = 4.069ppm)。 这是通过递增 RT1PS 来实现的
在一个64分钟周期内、RT0PS 输出的两个额外时钟的计数器。 每个 RTCCALx
校准位导致每64分钟添加256 LF 晶振时钟周期或512 LF 晶振
每64分钟减去一次时钟周期、给出了大约–2ppm 的频率调整或
分别为+4ppm。

如果我理解正确、RT0PS 以128Hz 的频率馈送 RT1PS、因此64Hz 中断每2次从 RT0PS 中触发一次。  为了调整时钟、RT1PS 每隔64分钟被保持以进行多次 RT0PS 计数(创建一个长的1/64"秒、或者它被预先载入一个大于0的值来加速时钟(创建一个短的"1/64"或者一秒)。  在我的情况下、当标称晶体为32ppm 慢时、需要将 RT1PS 预加载为值4 (还是8?) 这将导致2个丢失的中断。  或者以另一种方式、"64Hz RT1PS 中断"在"第二次校准"期间只会触发62次?  这种解释是否正确? 如果不是、我会遗漏什么?  

最小调整值为-4/+8ppm。  因此、即使32768晶振恰好在目标上、仍会每64分钟出现一次时序干扰。 对吧? 是否有任何工作可以确保每秒有64个中断?

感谢你的帮助。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    如果您可以简单地保证64到1的日志记录比率、即使日志记录在 x 百万秒内不是精确的 x 百万组数据、是否会更好?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    这将从数据解析的角度来工作、但时钟会随着时间的推移而不准确、因此时间戳会随着时间的推移而漂移。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您不必放弃校准、我认为您只需要快速 ISR 中的计数器、这样您就可以跳过或立即执行额外的"快速"数据记录、然后 IAW 记录1Hz 事件。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我的基本问题是 RTC 校准的工作方式是否符合每64分钟可能会在1秒周期内出现额外或过多的64Hz 中断的要求。 根据您的回答、您似乎同意用户指南的这一解释。 您是否了解它的工作原理? 我想先确定问题的原因、然后再找到解决方案。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    是的、除非我自己被错误地描述了它的工作原理(可能的)、否则你已经得到了它。 除非校准数据寄存 器为零、否则可以并将添加或减去'闰 周期'。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    用户指南指出:"最小校准可能为-4ppm 或+8ppm。 例如、设置 RTCCALS = 0和 RTCCAL = 0h 将导致频率减少-4ppm。 类似地、设置 RTCCALS = 1和 RTCCAL = 0h 将导致频率增加+8ppm。" 因此,似乎没有避免"第二次跳跃"。 实际上、每64分钟至少有2个丢失的1/64位中断、每64分钟有4个额外的1/64位中断。

    我很难相信 RTC 是这样设计的。 希望其他人也有其他解释、但我并不乐观。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Nick、

    通过在另 一个类似的 e2e 线程中读取先前的帖子并引用 Katie 的帖子、可以发现每64分钟缺失一个或多个传感器读数的根本原因是来自在 RT0PS 输出的一个或多个时钟周期内保持 RT1PS 计数器的校准模块。

    校准模块的目的是让用户仅在日历模式下就能完美地校准 RTC 输入、从而在一段时间内准确测量秒、分钟、小时等。 在这种情况下、您希望在 RTxPS 中断标志上精确地对每 n 秒触发一次的中断计时、而不必担心校准模块会影响这些中断。 这听起来像是一个完美的计数器模式 RTC 应用。

    最好清除 RTCMODE 位以将 RTC 置于计数器模式、这样校准模块就会被停用、而不必担心它会影响预分频中断时序。 由于您不标记传感器数据并且只需解码重复数据模式、因此 RTC 外设的这种配置应适用于您的实现。

    此致、

    Matt Calvo

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

    这个特定的问题看起来可以通过在计数器模式下使用 RTC 来解决。  但是、这将是一个巨大的变化、并会产生几个负面影响。  具体而言:

    1、时钟随着时间的推移将不再准确。  这是一个特殊的问题、因为通常一次部署多个数据记录器数月、数据应合理同步。 我们已将温度补偿添加到校准值中。  如果没有 RTC 补偿、任何两个数据记录器之间的时钟漂移都将超过我们的目标。

    2.数据记录器有多种工作模式,并不总是连续记录。  日历模式对于设置唤醒时间和在两次测量之间保持低功耗运行非常有用。

    3.虽然数据文件以重复模式存储,但由于其他原因(例如与其他设备通信),记录器仍需要跟踪时间,而这些原因超出了本讨论的范围。

    因此、我没有准备放弃 RTC 日历模式的原因有多种。 此外,我仍然希望围绕这一领域开展的工作能够提供两个领域的最佳成果。

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

    你需要有一种时间感是有道理的、我完全理解、这是你保持 RTC 处于日历模式的倾向的根本目的。 日历模式的分辨率以秒为间隔。 使用 RTxPS 中断每秒64次触发中断是可行的、但由于校准模块每64分钟保持 RT1PS 计数器一定数量的周期(这是为了在一段时间内保持精度)的需要而受到限制。

    根据我在用户指南中看到的内容、RT1PS 计数器的输出受校准模块的影响。 也许一个可能的权变措施是使用 RT0PS 中断功能来触发针对64Hz 应用的传感器数据采集。 如第22.2.3.1节所示、RT0IP 位能够触发速率低至128Hz 的 RT0PSIFG。 在您的情况下、您可以忽略所有其他中断、以便最终得到来自 RT0PS 的可靠64Hz 中断计数器。

    此致、

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

    这个问题是否有其他发展,或者是否找到了解决办法? 我当时正在研究 MSP430FR5994上提供的最新 RTC 版本(RTC_C)、该版本的日历模式似乎可以解决我们在 RTC_A 上实施的项目中发现的问题 对于 RTC_C、我们在 RTC_A 外设用户指南中看到没有"可能的最小校准"。 因此、RTC_C 似乎可以在日历模式中使用、而无需校准校正的干预。 使用 FR5994实现的其他一些好处是 FRAM 转换、除了具有低功耗加速器等外设来协助低功耗信号处理之外、FRAM 转换的优势远高于基于闪存的存储器。

    此致、

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

    未找到解决方案。  当前状态可以定义为混乱。   顺便说一下、由于 MSP430FR5994 (或任何其他版本)是已部署的产品、因此无法切换至 MSP430FR5994。

    下面是我当前的想法: 我们通常将 RTCALS 设置为1、将 RTCCAL 设置为4 、这会导致校正+ 32ppm。  我已经验证了这种校准是否有效、方法是将时钟与具有和不具有 RTC 校正的基准进行比较、间隔数天/周。  时钟调节在宏量程下工作。  但我认为用户指南中没有充分描述确切的调整方法。

    32 ppm 偏移相当于每64分钟删除4096 T0PS 周期、或 RT1PS 计数器增加16个增量(根据第22.2.4节、第二段)。  这将是16/128或8/64或1/8秒。 我以前曾假设这种调整是一次发生的,而这种幅度的跳变将是非常明显的。  但仔细阅读数据表并不会这样说。 相反、它说周期是"每64分钟"减去的。  这种增量似乎分布在64分钟间隔内、一次1/2秒、直到进行总调整的1/8秒。  我有两个理由这样认为:

    使用不同更快传感器的旧版硬件在64Hz 下工作。 值得注意的是、它没有"跳跃秒"、其中一秒1/64丢失(绝不介意每秒1/8)。 (如果数据文件模式不会保留、则解析的文件将损坏。)  假设有足够的裕度、系统可以在不丢失数据的情况下管理一个短周期(1/128与1/64)。

    2.在较新、较慢、与时序更密切相关的硬件上,数据文件错误每64分钟显示为错误模式。  这种较慢的硬件可能无法管理较短的周期。  此外、即使在不同的硬件上、误差始终以每秒相同的时间间隔发生、具体而言、每分钟的误差为38.875和58.875秒。  错误的数量是特定于硬件的并且随 RTCCAL 值的变化而变化。 我猜、RT1PS 计数器必须经过硬编码才能在第38和58秒递增、并且数据文件中的错误数与短周期数成正比。

    这就是我认为正在发生的情况、但我尝试通过在示波器上捕获一个短周期来确认它。 为此、修改了代码以根据 RT1PS 1/64中断来切换输出。  示波器设置为在短周期(即小于1/64秒或15.6ms 的周期)触发。  我预计周期仅为秒长的1/128、但到目前为止、即使在运行超过64分钟后、我也看不到任何短周期、因此这一理论尚未得到证实、因此我感到困惑。

    但底线问题是:正 RTC 补偿值会导致"丢失"1/64中断还是会导致"短路"1/64中断?  解决方案将取决于答案。

    感谢您的回答。

    Nick

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

    Nick、

    我将与我们专门从事 RTC 外设的系统工程团队联系、看看他们是否能够让您了解您在设计中发现的问题、并询问一些潜在的权变措施或解决方案。 当我听到他们的反馈时、我会与您联系。 感谢您的耐心等待!

    此致、

    Matt Calvo

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

    系统工程团队对 RTC 行为有何看法?

    谢谢、

    Nick

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

    正如大多数 TI 人昨天休假回来的时候一样、我希望很快能听到他们的反馈。 我将继续并再次 ping 他们、以加快响应速度。

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

    由于系统所有者正就此事与他们联系、他们最初的问题是确保 RTCALS 位被设置为1。 这是第一个问题、因为在您最初发布的 E2E 帖子中、您声明 RTCALS 设置为0。 我认为这只是初始帖子中的一个拼写错误、但我想肯定。

    谢谢、

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

    很好的收获  这是一个排印错误。 RTCALS 被设定为1。   完成以下注册:

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

    感谢您的澄清! 下一个问题是在二进制(十六进制)代码模式还是在二进制编码十进制(BCD)模式下使用 RTC?

    此致、

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

     BCD。  这是整个 RTC 寄存器集(尝试提前回答问题)。

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

    感谢您发送该信息。 如果我们可以重复您在使用 MSP430F5529 Launchpad 之一时看到的问题、这将有助于调试过程。 您是否愿意向我发送您的源代码、或者至少是包含该问题的已拆装版本、以及有关我们如何观察问题是否存在的说明。

    此致、

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

    我通过电子邮件向您发送了有关获取已删除的源代码的信息。 我会留意您的回复。

    此致、

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

    由于我们正在将此问题的支持脱机、请继续并选择此帖子已解决您的问题、以便我可以关闭并记录此主题。

    此致、

    Matt Calvo