RTC Time Drifts Even Though LSCO looks good

[kile]

Hi Everyone,

I have a project utilizing a STM32G030F6P6 with a 32.768kHz crystal and the LSE to source the RTC clock. It is exhibiting 2% clock error (which is huge!) over a 10 minute period despite using a 20ppm crystal. I am measuring this error by interrogating the RTC and communicating it to the rest of my system via i2c.

Now, I have read all of the crystal oscillator and load capacitor horror stories, but I have validated the actual crystal frequency by configuring the LSCO to output the LSE clock and it measures a stable 32.77 kHz (limited by the precision of my oscilloscope). In any case, much better than 2% error.

What gives? Can anyone confirm the expected duty cycle of the LSCO signal (I am measuring 40% and cannot find documentation as to what I should expect). 

[kile]

Just to clarify - both the RTC and the LSCO are configured to use the LSE.

[STOne-32]

Dear @kile ,

2% is huge indeed , can you change the drive level of the LSE to different combinations and each time power Off/On and see if there is an improvement on the error % . This is just for testing purposes from lowest to highest .

Next is to see how RTC is configured and how this drift is measured by software. By the way I assume the drift negative like missing pulses . Not positive with a faster time .

Let us know

Ciao

[kile]

Hi,

Thanks for your response. I increased the drive from low to medium high and it did not correct the issue. 

Can you provide some more information about how to measure drift in software - I’m not sure what we could measure against as a precise timebase? I figured my scope measurement would be as good as anything, and certainly much better than 2%. 

[waclawek.jan]

> I am measuring this error by interrogating the RTC and communicating it to the rest of my system via i2c.

Elaborate.

JW

[kile]

Hi - Thanks for the question.

At this point, we have verified against manual hardware signals (GPIO) which we manually timestamp against UTC. We're gaining hours here over a weekend, so it's not like this requires tremendous precision.

That's another thing - we are gaining time not losing it. So, this doesn't seem like insufficient crystal gain but I might be wrong about that. In any case, you'd think that checking LCSO would serve as an accurate measure of what's happening inside the MCU.

[STOne-32]

Hi @kile ,

thanks for the follow up , in that case you need to slow down the LSE and crystal clock and it will work .

just increase the CL1 and CL2 caps values around the crystal for example with 5 to 10pF additional and you will see it will help to reach your target . I have seen that in the past with others customers . Your oscilloscope is telling it also with .77 , then you will see 32,76 or lower at LSCO 

let us know 

STOne-32

[waclawek.jan]

> At this point, we have verified against manual hardware signals (GPIO) which we manually timestamp against UTC.

I meant, show code, which you use to verify the RTC/check its "speed"/generate the hardware signals.

What if the RTC runs OK and it's just your code which uses it in some improper way?

Also, read out and post content of RTC and RCC_BDCR registers.

JW

[kile · Accepted solution]

Sorry, guys. I found the issue. I had set the predividers to nonstandard values because we were using the LSI before and I hadn't fixed it before setting up the crystal.

Thanks again.

[STOne-32]

Great Job !! Well done