BLE 连接中重置硬件 RTC 会导致链路断开

背景是一个一次性电池供电的 BLE 健康监测设备。设备平时休眠，定时唤醒采集数据，再通过手机连接上传。调试时增加了两个 BLE 指令：设置 RTC 时间和读取 RTC 时间。

问题出现在 SET_RTC：手机通过 BLE 写入当前时间，固件解析成功，也返回了状态帧，但浏览器马上显示设备断开。串口日志能看到指令已经进入处理函数，Notify 也返回成功，断开点集中在调用 RTC_InitTime() 之后。

原因是这类芯片的硬件 RTC 不只表示业务时间。BLE 协议栈、低功耗唤醒、系统定时器也依赖同一套 32k 计数时基。连接过程中直接重置硬件 RTC，会让底层时间基准跳变，BLE 链路可能被打断。

最后的处理方式是把业务时间和硬件 RTC 分开：

业务时间 = 硬件 RTC 单调计数换算时间 + 业务时间偏移

SET_RTC 不再调用 RTC_InitTime()，只记录手机时间和当前硬件 RTC 时间之间的偏移。GET_RTC 返回当前硬件 RTC 时间加上这个偏移。这样设备仍然能对外表现为已经同步 RTC，同时不破坏 BLE 和低功耗系统依赖的底层时基。

真正需要写硬件 RTC 的场景，应放在 BLE 协议栈停止后处理，例如断开连接、停止广播，再设置硬件 RTC，必要时重新初始化 BLE 或重启设备。对于持续运行的低功耗 BLE 设备，业务时间偏移是更稳的设计边界。

本文由 AI 辅助生成，可能存在错误或遗漏，请以实际资料和官方文档为准。