STM32H7 RTC accuracy with 32.768 kHz LSE quartz in VDD mode and VBAT mode

[ChrSch]

Hello,

in our design with STM32H753ZIT6 I've adjusted the C0G load capacitors on the LSE 32.768 kHz crystal so that the real-time clock is now very accurate (less than 1 second error in 24 hours). I've always performed the calibration in VBAT mode at a voltage between 2.3 and 3.2 V.

However, now I've noticed that in normal VDD mode with active controller, the real-time clock is running significantly too slow, with an error of 90 seconds in 24 hours. I've ruled out the VBAT supply voltage as the cause. Any ideas what could be causing this large error in normal VDD mode?

Thank you!

[mbarg.1]

I would rule out any cristal or Vxx or chip related problem - it seem you are switching from crystal to LSI oscillator running 32kHz.

Usually large error like this are due to selecting wrong oscillator.

[ChrSch]

Thank you for the quick reply.

I had a similar thought, but isn't this sufficient:

PeriphClkInitStruct.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;

in the SystemClock_Config() function.

[AScha.3]

Or other possible problem:

in run  mode with VDD , you have switching signals close to crystal or the RTC pins, most sensitive is next pin to RTC pins (PC13) ; this can "disturb" the 32khz .... 

and obviously this is quiet when cpu is not powered.

+

How did you do calibration in VBAT mode , cpu not running to do "smooth calibration" ?

[waclawek.jan]

It's not necessarily PC13 which disturbs the LSE (although that may do that a lot). Any other signal in the oscillator's vicinity may do that. And, maybe even more importantly, also currents flowing through common ground tracks/planes.

It may be hard to capture a disturbance whih causes 1000ppm deviation, especially if the source is some sudden burst. You can test this hypothesis, though, by running the circuit under VDD with a firmware which is "quiet", i.e.does not exercise its outputs, and also with no external input signals.

You can also increase LSE drive, but I personally would recommend to track down the disturbance's source first.

Unless you do something directly with the RTC, such as put it into INIT mode often; that's not LSE-related.

JW

[LCE]

Completely independent of noise and crystal:

wasn't there a problem in RTC initialisation that might produce some sub-second reset, if that is done each time the CPU "wakes up" or is re-started ?

... which would not apply if the CPU is never sleeping.

Can't find the thread right now.

I have something like this in my H7 source:

/* RTC - only init if off, otherwise lose subseconds */
	if( (RCC->BDCR & RCC_BDCR_RTCEN) != RCC_BDCR_RTCEN ) RtcInit();