[参考译文] CC2340R5：RTC

您好、Ryan、

您的低频时钟源是 XOSC 还是 RCOSC？     RCOSC_LF 的精度为±600ppm (数据表因器件而异)。  600 (精度) x24 (小时) x60 (分钟) x60 (秒)/1000000 (PMM)=51.8秒、每天以最大 RCOSC_LF (输入)精度移位、无需补偿温度。  如果使用 XOSC_LF、则精度将取决于所使用晶体的规格和负载电容器。   因此、RTC 的精度将取决于振荡器源、时钟补偿和温度变化、但不应取决于所使用的其他代码操作。

此致、
瑞安

您好、Ryan、
我使用 LF XOSC 模式，不应该在其他地方设置低频时钟源、对吗？

我将一个7pF 32768振荡器和两个12pF 电容器用作负载电容器。

我再次测试它。 大约13小时后、读取 RTC 524M 寄存器的 Count 值后、乘以0.524转换为秒、与计算机时间存在28秒的差异。

如果使用 RCOSC，600 (ppm)*60 (s)*60 (m)*13 (h)实际上大约为28秒

但我的 SYSCFG 已设置为 LF XOSC、似乎没有其他地方可以修改它。

或者 CC2340是否完全未连接到外部32.768K 振荡器、而是使用了内部600ppm 振荡器？ 如果是、如何让 CC2340使用外部振荡器？

您已经在 SysConfig 中找到了设置所需 LF 时钟源的正确位置、并且 CC2340 LFCLK 应相应地参考低频晶体振荡器。  您可以 在运行时检查 LFCLKSEL 和 LFCLKSTAT 的值以确认。  请将您的自定义硬件发现与 TI LaunchPad 进行比较、并请记住、外部晶体也具有 ppm 精度(例如、LaunchPad 外部晶体上为+/- 380ppm)、这 可能会因不正确的 LF 晶体调谐而进一步加剧。  您还可以计算 TIME8U 值、并记住这些寄存器是32位无符号整数表示。  最终、  预计数小时内会出现秒漂移。  以下是有用的应用报告： https://www.ti.com/lit/swra495 

此致、
瑞安

我确认了我的 LFCLKSEL 和 LFCLKSTAT，似乎切换到外部振荡器成功了。



我还使用仪器来测量并确认误差值为+12ppm。

kai kang 说：

请将您的自定义硬件发现结果与 TI LaunchPad 进行比较

此外、使用非 BLE 的空 TI 驱动程序示例进行测试 、其中添加了 RTC、并考虑在待机功耗模式受阻的情况下进行测试(即仅在运行状态下运行)。

此致、
瑞安

我使用 TI LaunchPad 进行了两个小时的测试、发现 RTC 的速度要慢2秒、这实际上在+-380ppm 的范围内、 但奇怪的是、我检查了 TI LaunchPad 的 BOM、发现其振荡器应该为+-20ppm、在超过工作温度时似乎产生了380ppm？ 

感谢快速调查和响应。  如何在特定时间段内测量 LaunchPad 上的 RTC？  首选方式是通过 UART 等通信外设进行输出、而不依赖于活动的 JTAG 连接和 CCS 调试器会话、这可能会影响时序。

此致、
瑞安

(1)我用 LP-XDS110ET 连接 CC2340、然后 进入调试模式、在测量开始时记录 RTC524M 的值、然后在2小时后读取 RTC524M 的值、 然后在测量开始时减去该值以转换经历的时间。
380ppm * 60 (sec)* 60 (min)* 2也约为2秒、因此该测量的结果应该是准确的？

(2)我有一个问题：TI LaunchPad 的 RTC 误差值是否绝对为380ppm？ 因为在上述振荡器规格中写入的其中一项是"频率生成容差"。 这是否意味着除了380ppm 之外、还有+-20ppms？

1) 1)请在未连接调试器的情况下测量 RTC524M。

2) 2)这是 TI 2340R5 LaunchPad 使用的32kHz 晶体的数据表。  工作温度范围内的频率稳定性为380ppm、频率容差为+/- 20ppm @ 25 C +/- 3 C 。您可以联系晶体制造商了解更多信息。

时间偏移可能是由采样方法引起的、而不是晶振的稳定性。

此致、
瑞安

首先、本文开头所述的测试过程没有使用调试、因此我认为是否进入调试模式无关紧要。 再次测试后、我认为 RTC524M 暂存区并不意味着每个 Count 都将恰好为0.524 (秒)。 因为
(1) 524 (ms)不能被32.768K 振荡器整除

(2)我发现524.2919921875 (ms)可被32.768K 振荡器整除。 得到暂存区值后、每个计数乘以524 (毫秒)。 如果每个计数的误差为0.2919921875 (ms)、则在1小时内确实可能出现2秒的误差。

(3) 524 (ms)我想它是使用32K 振荡器计算出来的、因为524 (ms)可以平均除以32K

如果我的上述猜测是正确的、那么 RTC524M 寄存器的每个计数的正确准确时间是多少？

此外、我想问、CC2340的 RTC 是否可以使用中断？ 如果可以、我应该如何使用 RTC 中断？

我理解您的担忧、已询问系统开发人员您提出的差异。  从到目前为止反馈给我的内容：

我对 TRM 的解释方式以及到目前为止提供的内容表明、RTC 的 LSB 是正确的。 TIME8U 精确地表示8us、表示 RTC 的 LSB。 TIME524M 必须代表524.288ms、而不是524ms 才能保持一致。   这意味着我们至少应该更新 TRM 一章中寄存器的说明。

因此、 与 更精确的 值(0.524288)相乘有可能增加您的准确度。

关于中断、它们可被使用、并涵盖在 TRM 的第12.3和12.4节中。  例如、使用 RTC。 CH0CC8U 比较值、用于在 TIME8U.VAL 超过该值时触发通道0中断事件。  您还可以考虑使用 SYSTIM 来满足类似的要求、前提是它与 RTC 同步。

此致、
瑞安

您好、Ryan、
(1) RTC 是否确认精度为524.288 (ms)？ 因为我在测试开始时计算出524.288 (ms)、因为524.288 (ms)/32.768K = 16、但后来我们发现32.768K 是振荡器周期、也就是说、它在1秒内振荡32,768次、因此如果524.288 (ms)转换为振荡17,179.869184次、 这是有点不合理的、因为振荡器的振荡数量不应有一个小数点、所以我认为在前一条消息中它是524.2919921875 (ms)、因为524.2919921875 (ms)* 32768 = 17180、我们认为它更合理。 能否与开发部门确认是524.288(ms)还是524.2919921875(ms)？

(2)您提到的 SYSTIM、我在"TRM"中看到了相关信息、但没有实际的操作示例、我查看了 TI E2E 论坛、没有关于如何调用或应用 SYSTIM 的信息。 能不能再详细介绍一下？

(1)表示位索引0到索引18是 RTC524M 临时寄存器的单位、因此为2^19 = 524.288、而位索引19到索引50是​​计数中 RTC524M 的值。 我能这样理解吗？

位索引0至18是 RTC 计数的更精细度。  例如、TIME8U 返回 time[34：3](即 2^3us = 8us  )。   

此致、
瑞安

好的，谢谢。  当前测试结果准确。 我会进行长期测试。 如果我再发现问题，我会在论坛上讨论。

我还有一个问题、开发部门如何确定 LSB = 1us、因为如果根据1 (s)/32.768 (k)的周期进行计算、应该约为30us。 那么如何计算1us？

RTC 保留了一个宽度为[50：-16 ]的"时间累加器"。 这里的位索引0具有1us 的意义、因此时间的范围为2^51*(1us)= 71.4年、精度(非精度)为2^-16*(1us)= 15.3ps。"  

我认为目前正在努力更新 TRM、以 强调" RTC 累积时间的精度为15.3 ps (基于 LFINC–提供/估计的 CLKLF 周期)、而不是仅计算 CLKLF 周期的数量(作为大多数其他 RTC)。"

此致、
瑞安

好的、谢谢