问题：
该问题由某客户提出，发生在 STM32F103RBT6 器件上。据其工程师讲述：其产品为车载 GPS 导航监控设备，其中使用了 STM32 作为主控器件，负责管理整个设备。在该产品的设计中，使用了 STM32的 RTC，并将其计时显示在产品的屏幕上。计时显示的更新是由 RTC 的秒中断来完成的，即由 RTC的秒中断服务程序从 RTC 中读出新的时间并更新到相关的变量中，再触发屏幕刷新程序更新屏幕上的显示。在测试时发现屏幕上显示时间的秒部分走时不均匀，时快时慢，甚至会丢掉某个中间值而发生跳变。 对该显示时间做长时间计时的测量，发现其长时间计时是准确的，即秒长度的平均值是准确的。将程序中的其它中断关掉，只保留 RTC 的秒中断，问题依旧。通过在 RTC 秒中断服务程序中加入对 GPIO 翻转的代码来测量 RTC 秒中断响应的时间间隔，发现其是均匀的，如图（一）所示，说明并非 RTC 的秒中断响应不及时而导致显示时间的波动。


用同样的方法测量从 RTC 秒中断得到响应到完成屏幕上显示时间的更新所消耗的时间，结果为1.56mS，如图（二）所示。这一延时不足以对屏幕上显示时间造成的可察觉的波动。到此，不知下一步该如何定位问题原因，请求技术支持。



调研：
重复观察现象，如其所述。为了便于观察，修改代码，在每次从 RTC 读取新的时间之后，将保存时间的变量通过 UART 打印到终端软件上。其结果如图（三）所示，与设备屏幕上的显示时间是一致的：



进一步修改代码，在每次从 RTC 读取时间数据之前加入 1mS 的等待，如表（一）所示，其中变量TimeDisplay 由 RTC 的秒中断服务程序置“1”，触发该任务更新屏幕显示时间：



编译后重新测试，结果表明之前所述现象不再发生，如图（四）所示：




结论：
对 RTC 的时间数据的读取与 RTC 内部对时间数据的更新在时间上存在竞争关系，以至两者在时间上的顺序不确定。于是，读到的时间数据，时而是新数据，时而是旧数据，从而导致读回的时间数据的取值会发生跳变、或者不变的现象，而不是稳定的递增。


处理：
通过在读 RTC 的时间数据之前加入一定的延时，来保证其与 RTC 内部对时间数据的更新之间保持一个固定的时间顺序，以便读回的都是更新后的数据。

建议：
在 STM32 中，RTC 部分与 CPU 部分分别属于不同的时钟域，且两者的工作时钟频率相差较大，前者工作在 32.768KHz 的频率下，而后者的工作频率通常在 36MHz 以上。这一差别导致两者对同一事件做出响应的速度存在着明显的差距，CPU 的响应速度快而 RTC 响应速度慢。从图（五）所示的 RTC系统架构中可以看到，由前置分频器产生的秒脉冲信号送给 RTC 的计数器的同时，也通过 RTC 的中断请求控制单元送到了 CPU 的 NVIC 单元。



这样的信号传递关系决定了，在 RTC 的计数器接到更新计数的信号的同时，RTC 的秒中断请求信号即已送达 CPU，而不是在 RTC 的计数器完成更新计数之后。这样一来，由于 RTC 对这一事件的响应时间是 RTC 时钟域的 1 个时钟周期，即 ，而 CPU 对这一事件的响应时间几个到几十个 CPU 时钟域的时钟周期。假如 CPU 工作在 36MHz 的频率下，一般来说，这一时间在 左右，所以，CPU 要先于 RTC 的计数器响应这一事件。然而，一般情况下软件的中断服务程序并非一开始就去读 RTC 的时间数据，而是要先做一些前期的判断和准备工作，甚至要等到中断服务程序结束后，由普通任务去读这一数据。由此，也会引发一个延时，通常这一延时的时长在 10uS 到 50uS 之间。于是，读取 RTC 的时间数据的事件和 RTC 计数器更新计数值的事件在非常邻近的时间点上发生，且无固定顺序。综上所述，几个事件在时间上的关系，如图（六）所示：



为了消除 RTC 计数器更新时间数据和软件读取 RTC 时间数据这两个事件在时间上的竞争，可以让后一事件延后一段时间之后再发生，以确保两个事件有固定的时间顺序。