教你轻松解决RTC意外回到初始值的问题

2021-07-28 17:22 来源:电子说

关键词:RTC,篡改

1.问题描述

根据客户反馈,使用STM32F446产品进行开关机测试时,RTC会意外恢复到配置的初始值。

2.问题分析和解决方案

通过与客户的邮件沟通,得知客户的VBAT引脚有独立的电池电源。首次启动代码时,将检查备份寄存器中保留的标志。如果是第一次运行,会设置RTC的初始化,包括年、月、日、分、秒。如果不是,则跳过,然后只读取RTC中的时间信息,不进行修改。

为了使用统一的引用,建议客户使用Cube库下的官方示例代码:STM 32 Cube _ fw _ F4 _ v 1 . 25 . 0 project sstm32 f 446 ze-nucoroexampertcrtc _ calendar,可以分析这个问题。客户使用此示例代码来测试问题是否仍然存在。

看样码,为了消除HSE和LSE的影响,建议客户将HSE改为HSI,LSE改为LSI,与车载高速晶振和32.768K的低速无关.客户仍然存在使用修改后的代码的问题。检查相关代码:

15166378-ed32-11eb-a97a-12bb97331649.png

如上代码所示,每次加电后都会读取BKP_DR1的值,判断是否是第一次启动,如果是,则配置RTC。换句话说,如果出了问题,这个判断肯定会出错,导致RTC的重复配置,也就是备份寄存器的值丢失!是什么导致备份寄存器的值丢失?

同时,我试图在nuco板上重现客户的问题,但无论我怎么尝试,都无法重现。现在双方使用的测试软件完全一样,但是硬件平台不同,这似乎就是这种硬件差异带来的问题。因此,下一步是比较客户硬件和核板之间的差异。

第一个疑点是VBAT引脚。如果VBAT出现异常,RTC重新配置正常,但是客户VBAT真的会有问题吗?以下是客户VBAT引脚的相关电路:

153ce70a-ed32-11eb-a97a-12bb97331649.png

图1 VBAT的外部电路如上图所示。客户VBAT外接电池。当VDD通电时,VDD将为电池充电,当VDD断电时,电池将为RTC供电。因此,断电和通电测试期间的VBAT波形呈现给客户:

VBAT引脚的波形在掉电和上电过程中不掉电,也就是说RTC有稳定的电源。为了避免VBAT的影响,让客户简单的拆下电阻R8,重新测试,但问题依然存在。接下来继续查看与用户MCU相关的原理图,发现Vcap引脚上的电路与ST的官方建议不一致:

17781738-ed32-11eb-a97a-12bb97331649.png

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

如上图所示,客户使用的VCAP引脚对地电容为100nF,而ST建议为2.2uF,这与MCU内核的稳定性有关。单片机核心的不稳定有没有可能导致RTC问题?

已经证实问题与这两个电容无关。当客户更改为2.2uF并再次测试时,问题仍然存在。同时,我们关注PDR_ON引脚,认为很多客户在这个引脚上种过一次,客户可能接错了PDR_ON引脚,焊接了,挂掉了,会出现一系列奇怪的问题。该引脚与掉电检测相关。请客户仔细检查此引脚是否连接正常,客户反馈确定正常。因此,客户被要求移除R64的10K上拉电阻,并将其直接短接到VDD并再次测试。

结果问题还是一样。到目前为止,硬件应该差不多检查过了,但是问题的关键还没有找到。这个时候我觉得这个问题是备份寄存器值丢失导致的,那么什么时候会丢失呢?推理无非是以下几种情况:

1英寸vdd和VBAT同时断电

2)客户代码的意外修改

3.检测到入侵

首先排除前两个原因,客户的VBAT不会掉电,排除第一种情况。客户使用ST官方提供的样本代码,不应有意外修改

px;width:400px;" alt="17bc53a8-ed32-11eb-a97a-12bb97331649.png" />

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

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

18292e92-ed32-11eb-a97a-12bb97331649.png

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

18deb172-ed32-11eb-a97a-12bb97331649.png

Figure 5评估板上的PC13

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

18e9d714-ed32-11eb-a97a-12bb97331649.png

Figure 6 STM32F103上的PC13外部下拉 看来PC13是有讲究的。于是请客户将PC13引脚拉地再测试,结果问题不再出现。看来此问题确实由PC13引脚引起。 为了重现客户的现象,我在STM32F446-EVAL评估板上尝试重现,但是,始终没有重现,但好在客户修改PC13引脚后确实问题得到解决,所以此问题也就到此为止。

3. 后记

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

编辑:jq

延伸 · 阅读