About the drift of the RTC of STM32F407VET6

[juntakei]

Hello everyone, I'm Jun and I live in Japan.

The board is a custom board based on BLACK_F407VE, and is for hobby engine control. The crystal oscillator is ABS07-LR-32.768kHz-6 (load capacitance 6pF) recommended by STM.
The development environment is Visual Studio Code and PlatformIO. The framework is Arduino.
The program was modified from the sample program SimpleRTC in the library that comes with PlatformIO so that the hour and minute can be set. In addition, RTC_CALIB can be output to a port.
There are three boards, and a 3V battery is attached to VBAT. Set the time in the RTC, turn off the power, and refer to the RTC one hour later. One board has 0 drift, and the other two boards advance significantly. The power is turned on and off only once each when setting and referencing.

NO1:
Capacitors on both ends of the crystal are 12pF
RTC_CALIB=Average of 1 minute 511.94Hz
RTC value after 1 hour = 39 seconds ahead

NO2:
Capacitors on both ends of the crystal are 6pF
RTC_CALIB=Average of 1 minute 511.99Hz
RTC value after 1 hour = 101 seconds ahead

NO3:
Capacitors on both ends of the crystal are 12pF
RTC_CALIB=Average of 1 minute 511.94Hz
RTC value after 1 hour = Almost 0 seconds ahead

So here are my questions.

1. I'm using Visual Studio Code and PlatformIO as my development environment, but can I ask a question here? I think the library and HAL are STM programs.

2. The library has the following signature. Isn't 2020 outdated?
/**
*************************************************
* @file STM32RTC.cpp
* @author Frederic Pillon
* @brief Provides a RTC interface for Arduino
*
*********************************************
* @attention
*
* <h2><center>&copy; COPYRIGHT(c) 2020 STMicroelectronics</center></h2>

3. Since RTC‗CALIB is almost 512Hz, can we assume that there is no problem with the capacitance of the capacitors on both ends of the crystal (6pF even for 12pF) or the artwork on the board?

4. Why does the RTC value advance so much on some boards even though the RTC‗CALIB is almost 512Hz?

5. Is there anything I can do to find out the cause?

<This text was translated from Japanese to English by Google Translate>

[waclawek.jan]

> RTC value after 1 hour = 39 seconds ahead

How do you know? How exactly do you observe that?

JW

[juntakei]

I set the time from a PC terminal using SimpleRTC. After setting, the time is displayed every second.

Meanwhile, I am displaying a clock page on the web on my PC and comparing the two. Since I set the RTC manually while looking at the clock page, I think the error in setting is 1 to 2 seconds at the most. I expect the error to be 2 to 3 seconds per hour.

I am attaching two images.

The first one shows the RTC clocks on board No. 3 matching.
The second one shows the RTC clock on board No. 1 39 seconds ahead.

Thank you in advance.

[waclawek.jan]

I can argue at the register level, but your approach is removed from that by at least 3 layers (Cube/HAL, the Arduino libraries, and whatever program you are using to communicated between PC and the mcu), of which I only marginally know Cube/HAL (I don't use it actively and I personally detest it too).

Two most common sources for problems of this magnitude (10000ppm) with RTC is 1. mistakenly using LSI instead of LSE as primary clock source, which is probably ruled out by you measuring the 512Hz calibration output; 2. neglecting the effect of shadow registers, i.e. reading only the time register without reading date register, but that appears to be ruled out by the fact that the time your program reads out does indeed change.

So at this point I don't really know what to recommend to do (except to delve into the depth of all 3 layers plus the underlying hardware/registers). One thing which comes into mind perhaps is to find out, whether the delay appears gradually or suddenly (i.e. observing whether time after each 10 minutes gradually deviates by 6.5, 13, 19.5... seconds; or the time is exact for a couple of 10 minutes' observations and then suddenly jumps ahead by the 39 seconds and then in subsequent observations the deviation remains 39 seconds).

JW

PS. What happened during that hour with the board? Any inputs/outputs are changing?

[juntakei]

Thank you for your reply.

The following is written in the setup function for the clock source, so I think it is set to LSE.

if (rtc.isTimeSet()) {
  rtc.setClockSource(STM32RTC::LSE_CLOCK);
  //Initialise external clock for RTC if clock is set. That is the only clock running of VBAT
}
rtc.begin(); // initialize RTC 24H format

Also, since it can output 512Hz, I measured the average value with a USB oscilloscope, so I will attach two images. The frequency measurement was 1 minute and the trigger was rising. Both have little deviation.

The first is 512Hz for No.3, where the RTC works well.
The second is 512Hz for No.1, where the RTC advances by 30 seconds.

The delay seems to appear gradually as far as I can tell from the terminal. I'd like to find a way to check this, but I'm using delay(1000) in the loop function to display the time at 1 second intervals, so I don't understand whether subtracting the time from the terminal log will give me the correct 1 second error. Is this worth trying?

Thank you.

[waclawek.jan]

At this point I don't have any other ideas, sorry.

JW

[juntakei]

I think I can check every 10 minutes.
If I find out anything, I'll ask again.

Thank you.

[juntakei]

I turned the power off for an hour of testing and nothing happened.

[Tesla DeLorean]

Only LSE can run via VBAT

LSI won't and has a different frequency and prescalers / dividers. A mismatch of those will result in divergence of time.

[juntakei]

Thank you for your reply.

>Only LSE can run via VBAT

I understand this.

>LSI won't and has a different frequency and prescalers / dividers. A mismatch of those will result in divergence of time.

What does this mean?

Does this mean that the RTC clock uses the LSE when the power is off,

and the LSI when the power is on, it uses the LSI?