[参考译文] CC2745R10-Q1：CC2745R10 上软件复位后 RTC 时间持久性所需的指导

您好 Ankur、

在软件复位和看门狗复位期间、CC2745 上的 RTC 不会复位。 参考 TRM 的第 16 章。

此外、如果您确实需要写入 RTC D_TIME 寄存器、请参阅系统计时器、这是射频内核使用的高分辨率计时器。 您需要通过向 SYSTIM.STATUS.SyncUP 写入 1 来将系统计时器与 RTC 同步。 请参阅下面链接中的 TRM 各节。

系统计时器

RTC D_TIME 寄存器
系统计时器状态寄存器

当器件从复位变为活动状态时、系统计时器会自动与 RTC 同步。

我希望这能回答您的问题。 如果您遇到任何其他问题、请告诉我。

谢谢。此致、
Lakshaya

您好、LAKSHAYA

感谢您的回复、确认在 SW/WDT 复位期间 RTC 未复位。

我们还有一个关于 DTIME + SyncUP 和 BLE 共存的后续问题。

我们的设置：

• CC2745R10、SimpleLink LPF3 SDK 9.14.02.16
• FreeRTOS 无嘀嗒声空闲（待机模式）
• 同时运行 BLE 5.x 外设角色

问题： 当我们在写入 RTC_O_DTIME 后 SYSTIM.STATUS.SYNCUP = 1 （如您所建议）、BLE 链路层将永久终止。 唯一的恢复是下电上电。

我们在 RCL 日志中看到此错误：

RCL_CommandStatus_Error_StartTooLate (0x86)

此后、广播停止并且不会触发断开事件。 BLE 永远不会恢复。

我们确定的根本原因： BLE LL 使用 绝对 SYSTIM 时间戳安排所有广播和连接事件 (RCL_CommandTiming_s.absStartTime)。 当我们编写 SYSTIM.STATUS.SYNCUP = 1时、SYSTIM 向前移动 DTIME 偏移（~56 年）。 这使得每个调度的 BLE LL 比较值都立即到期→ StartTooLate →BLE 栈裸片。

我们的问题：

1. 是否有办法 RTC_O_DTIME  在不 触发 SYSTIM 重新同步的情况下写入（将 Unix epoch 编码到 RTC 中）、因此 BLE LL 不受影响？
2. 或者、是否有建议的顺序来 在 BLE 处于活动状态时安全地更新 CC2745R10 上的 RTC 时间？

我们已经尝试过的方法：

• 在不写入 SyncUP→BLE 的情况下写入 DTIME 会立即存活、但在首次待机唤醒后、SYSTIM 会自动同步 RTC→相同的 StartTooLate 错误
• 纯软件偏移（无 DTIME 写入）→BLE 安全、但 POCH 在 SW/WDT 复位时丢失

如能就正确的方法提供任何指导、将不胜感激。

谢谢
BR  
Ankur Singh

你好 LAKSHAYA

关注 CC2745R10 上有关软件复位间 RTC 时间持久性的较早线程（TRM SWCU195A、第 16 章）。

我想报告一个功能限制、该限制影响任何 RTC.DTIME SYSTIM.STATUS.SYNCUP 在 FreeRTOS 运行时尝试使用应用程序代码中的+机制的应用。

我们尝试过的

从调制解调器接收到 Unix epoch（~17.8 亿秒、2025 年）后、我们使用 RTC.DTIME 将 RTC 时间计数器调整为 Unix epoch 值、然后 1 SYSTIM.STATUS.SYNCUP 按照 TRM§16.5.22 中的说明写入。

发生什么事了

该器件在 epoch 同步后大约 20 秒通过 WDT 复位。 同步后不运行任何任务。

根本原因分析

FreeRTOS DPL 层 ()ClockPLPF3_freertos.c使用 SYSTIM 作为其整个节拍基址：

// ClockPLPF3_freertos.c line 87
#define getClockPTick()  (HWREG(SYSTIM_BASE + SYSTIM_O_TIME1U) / ClockP_TICK_PERIOD)

它还编程 SYSTIM.CH0CC 为触发 FreeRTOS 嘀嗒中断的硬件比较：

// ClockPLPF3_freertos.c line 245
HWREG(SYSTIM_BASE + SYSTIM_O_CH0CC) = newSystim;

当 SyncUP 触发时、SYSTIM.TIME1U 从较小的引导相对值（例如，启动后~5,000,000µs = 5 秒）跳转到大约 1,781,000,000,000,000µs（以微秒为单位的 Unix epoch）。 之前编程的 CH0CC 比较值（在引导时设置的提前~1ms）现在相对于新的 SYSTIM 值大约是 56 年。

根据 TRM§15 (SYSTIM)、如果比较值在过去的 2^22 个周期（~4.19 秒）内、硬件会触发立即比较事件。 过去 56 年的比较远远超出了这个窗口、因此行为变得不明确。 实际上、ClockP 的 ISR 会触发、计算 nextTick - nowTick 为大规模绕回、以一个假的未来值安排下一次比较、所有 FreeRTOS 任务都将耗尽、并且 WDT 会在~20 秒时触发。

ClockPLPF3_freertos.c 的关键约束：

/** Max number of ClockP ticks into the future supported by this ClockP
 * Under the hood, ClockP uses the SysTimer whose events trigger immediately if
 * the compare value is less than 2^22 systimer ticks in the past
 * (4.194sec at 1us resolution). */
#define ClockP_PERIOD_MAX  (0xFFBFFFFFU / ClockP_TICK_PERIOD)

ClockP_PERIOD_MAX 在 FreeRTOS 运行时进行的任何大于（4290 秒）的 SYSTIM 跳转都会损坏节拍队列。 一个 Unix 的 epoch 跳跃是~56 年,这是许多数量级超过这个限制。

解决方法的示例

我们使用纯软件偏移方法—硬件永远不会被触及：

s_boot_epoch = epochSeconds - (SYSTIM.TIME1U / 125000)
GetEpoch()   = s_boot_epoch + (SYSTIM.TIME1U / 125000)

为了实现 SW/WDT 复位的持久性、我们将存储 s_boot_epoch 在一个 .noinit 带有幻数的 SRAM 部分 (ARM SYSRESETREQ 不清除 SRAM) 中以进行验证。 此操作正常。

公钥

您能否确认这是否是的已知限制 ClockPLPF3_freertos.c、以及在 FreeRTOS 运行时是否有任何支持的路径用于根据应用程序代码调整 SYSTIM 时基？ 否则、可能值得向 TRM§16.5.22（DTIME 寄存器说明）添加一条注释、说明在 SYNCUP 使用基于 FreeRTOS 的 DPL 时不得从应用程序代码调用。

器件：CC2745R10 SDK：SimpleLink LPD3 SDK 9.12 TRM：SWCU195A（2024 年 12 月、2025 年 5 月修订）文件参考： kernel/freertos/dpl/ClockPLPF3_freertos.c

谢谢你。

此致、
Ankur Singh