The STM32L431 RTC clock is slowing down

[Kevin.YIN]

We tested the RTC clock and found a phenomenon that the system kept VDD3.3V in standby state and then disconnected VDD3.3V in standby state, but the RTC clock did not run slowly. If the system controlled automatically and disconnected VDD3.3V in sleep state (3.3V is controlled by the I/O pin pull up enable), The RTC clock will run slowly. It is clear in the L431 manual that VDD and VBAT are automatically switched.

In conclusion, after the chip enters standby mode, the RCT is normal when the VDD is disconnected. When entering low power mode and disconnecting VDD at the same time, RTC running slow will occur.

I would like to know whether this simultaneous switching is feasible, and if so, what are the possible reasons for this phenomenon of slow RTC? VDD switching to VBAT is done automatically. How long does the switching time take? Each VDD pin is equipped with a 100nF+10uF capacitor.

Thank you in advance for your help!

[Danish1]

Please tell us more about the “running slow“ you observe. Is it a few missed ticks during the changeover either to or from battery-backup, or is it that the longer you spend on battery the greater the loss of time?

RTC can be derived from a number of clock sources. We should ignore internal clock sources (LSI, HSI, MSI) as at only 1% at best they are susceptible to drift.

And HSE is likely to be stopped when on battery backup.

So that just leaves LSE, with a 32kHx crystal. Is that what you’re using?

[Kevin.YIN]

Thank you for your help!:loudly_crying_face:

it is that the longer I spend on battery the greater the loss of time.

The clock source of the RTC uses the LSE with a 32kHx crystal.

We output real-time information through MobaXterm software, and network calibration is also carried out for RTC in the program. When the system will be calibrated every time after waking up, the software can see that the time after calibration is different from the actual time displayed. Usually, it is measured for 10 minutes, which is about one minute slower.

Then I removed the calibration and looked at the RTC, set the wake up time for 3 minutes, 10 minutes and 15 minutes respectively, and timed it with a stopwatch. The phenomenon was that it would wake up about 30 seconds faster. The wake up time interval displayed on the software was the same as that on the stopwatch.

The above is probably my testing process, which is the problem encountered by my client, so I can only test through the bin file provided by them. I wonder whether it is possible to disconnect VDD at the moment when entering the low power mode, and then use VBAT to power RTC. Will this affect RTC? :tired_face:

[JPeac.1]

If you believe the RTC slows down then if you monitor the LSE oscillator frequency you should see it change as well. If the LSE is stable and doesn't slow down then look at what the LSE frequency is compared to the ideal 32.768KHz.

You mention network calibration, what is that? Do you compare the RTCCLK against a fixed, crystal controlled frequency (i.e. HSE) at startup (and on a periodic basis to allow for temperature and humidity fluctuations) to adjust for variations in the LSE crystal? ST has an application note on this and how to use the RTC calibration register to compensate for LSE frequency variations.

If you are comparing internal RTC time against a network time server then there will be some drift. The tolerance of the LSE oscillator will yield a cumulative error, the reason a network time server is needed to keep a local RTC in sync.

It's not really clear what your problem is, other than the normal inaccuracy from the LSE oscillator.

Jack Peacock

[Kevin.YIN]

Hello jack

Thank you for your advice! I am very sorry for not reading the news recently due to personal reasons. In fact, the main problem is that if we enter standby mode first and then disconnect VDD, then the RTC is normal, but when we enter standby mode and disconnect VDD at the same time, the RTC will slow down. This is in order to achieve the minimum power consumption to complete the switch, but I don't know whether it is feasible.