工程师笔记 | 解决 RTC意外恢复到初始值问题

[复制链接]

STMCU小助手发布时间：2021-7-15 13:16

文章
文章封面:
文章简介:	通过与客户邮件沟通，了解到客户的VBAT引脚上有独立的电池供电，在代码中当第一次启动时会检查备份寄存器中保留的一个标志，如果是第一次运行，则会设置RTC的初始化，包含年月日时分秒，如果不是，则跳过，后面只读取RTC内的时间信息，并不再修改。

1. 问题描述
客户反馈在使用STM32F446的产品做上电、掉电测试时，RTC会意外恢复到配置的初始值。

2. 问题分析及解决
通过与客户邮件沟通，了解到客户的VBAT引脚上有独立的电池供电，在代码中当第一次启动时会检查备份寄存器中保留的一个标志，如果是第一次运行，则会设置RTC的初始化，包含年月日时分秒，如果不是，则跳过，后面只读取RTC内的时间信息，并不再修改。

为了使用统一的参考物，先建议客户使用Cube库下的官方示例代码：
STM32Cube_FW_F4_V1.25.0\Projects\STM32F446ZE-Nucleo\Examples\RTC\RTC_Calendar,此代码刚好可以针对此问题进行分析。客户使用此示例代码测试问题依旧。

查看示例代码，为了排除HSE与LSE的影响，建议客户将HSE改为HSI, LSE改为LSI，这样一来，完全跟板上高速晶振无关，跟32.768K的低速也无关。客户使用修改后的代码问题依旧。

查看相关代码：

如上面代码所示，每次上电后会读取BKP_DR1的值，判断是否为第一次启动，如果是，则配置RTC。换句话说，出现问题时，这个判断肯定出现问题，导致重复配置RTC，也就是备份寄存器的值丢失！是什么原因导致备份寄存器的值丢失呢？

同时我这边在NUCLEO板上尝试重现客户的问题，但无论如何尝试都无法重现，现在两边所使用的测试软件一模一样，只是各自的硬件平台有所差异，看来就是这个硬件上的差异带来的问题。于是下一步比较客户的硬件与NUCLEO板有何不同。

首先怀疑是VBAT引脚。要是VBAT再现异常，RTC重新配置就很正常，但客户的VBAT真的会出现问题么？下面是客户VBAT引脚的相关电路：

Figure 1 VBAT外围电路
如上图所示，客户VBAT外部接一电池，当VDD有电时，VDD将将电池充电，当VDD掉电时，电池给RTC供电。于是向客户提出VBAT的在掉电上电测试过程中的波形：

Figure 2 VBAT波形
如上图所示，VBAT引脚的波形，在电源掉电上电的过程中并没有出现掉电的情况，也就是说，RTC擁有穩定的电源供应。为了避免VBAT的影响，要客户干脆将R8这个电阻去掉再测试，结果问题依旧存在。

接下来继续查看用户MCU相关的原理图，发现Vcap引脚上的电路与ST官方的建议并不一致：

Figure 3客户产品的vcap和PDR_ON引脚

如上图所示，客户所使用的VCAP引脚对地电容为100nF, 而ST建议的是2.2uF,这个电容涉及到MCU内核的稳定性，有没有可能是MCU内核不稳导致RTC的问题呢？

经验证，问题与这两个电容没有关系，当客户修改到2.2uF再次测试时，问题依旧。

同时注意到PDR_ON引脚，联想到曾经多个客户栽到这个引脚上，客户可能PDR_ON引脚接错，虚焊，悬空将会导致一系列奇怪问题。此引脚涉及到掉电检测。要客户仔细检查此引脚是否已经正常连接，客户反馈确定正常。于是要客户去掉R64这个10K上拉，直接短接到VDD再测试下。

结果发现问题依旧。

到目前为止，硬件上该检查的也差不多检查了，还是没有找到问题的关键。这个时候，想起此问题是由于备份寄存器的值丢失引起，那么什么时候下会丢失呢？思来想去，无外乎以下几种情况：

1> VDD和VBAT同时掉电

2> 客户代码意外修改

3> 检测到入侵事件

首先排除前面两种原因，客户的VBAT不会掉电，第一种情况排除。客户使用的是ST官方提供的示例代码，应该不存在意外修改的情况，那么第三种…可是示例代码中也没有使能入侵检测啊？

于是想到errata sheet, 打开并发现如下内容：

如上所述，即使没有开启入侵检测，当tamper引脚出现高电平的情况下也有可能会导致入侵检测误判。于是查看客户的入侵检测引脚：

从客户的原理图可以看出，入侵引脚PC13用户外部按键输入，有外部10K上拉电阻：

其波形如下所示：

Figure 4 PC13引脚波形

对照STM32F443-EVAL的相关电路 ,在评估板上，PC13用作tamper检测但外部下拉：

Figure 5评估板上的PC13

同时评估板上的ST-Link部分的STM32F103的RTC_PC13也是外部10K下拉：

Figure 6 STM32F103上的PC13外部下拉

看来PC13是有讲究的。于是请客户将PC13引脚拉地再测试，结果问题不再出现。看来此问题确实由PC13引脚引起。

为了重现客户的现象，我在STM32F446-EVAL评估板上尝试重现，但是，始终没有重现，但好在客户修改PC13引脚后确实问题得到解决，所以此问题也就到此为止。

3. 后记
很多时候当对问题无从下手的时候，解决问题的关键是首先找到一个可以参考的参照物,比如软件是有ST提供的官方示例代码，硬件是有ST提供的NUCELO板，找到这个关键的参考物后接下来逐渐比较客户的软硬件与参照物的差异，不断缩小范围，这个不失为一种常规比较有效的方法，希望读者能充分利用。