STM32L4 low RTC precision

[Lukasz Przenioslo]

Posted on March 05, 2018 at 07:57

Hello there,

I am using an STM32L4 family MCU. In an application, the RTC peripheral is utilized and clocked from an external crystal:

The problem I have noticed just now is that with time, the RTC timer looses sync. It is not easy to notice in short periods of time, but after leaving the application to log time for entire weekend, I noticed that the RTC timer is over 20 minutes later after my PC timer (they were both synced before the weekend).

What could be the cause of this problem? Its hard to believe for me that the RTC timer is simply this low precision, as I am using an external crystal. I would appreciate all help.

#precision #stm32l4 #rtc Note: this post was migrated and contained many threaded conversations, some content may be missing.

[henry.dick]

Posted on March 16, 2018 at 17:07

let's not focus on those major contributors to timing errors.

instead, let's focus on those minor contributors, especially those difficult ones first. we will sure get to solve the 6000ppm problem, 1ppm at a time.

[Lukasz Przenioslo]

Posted on March 17, 2018 at 09:41

Turvey.Clive

‌ I think you were right about the clock config. Using the default values in the formula the result is the following:

32768 / ((128 + 1) * (256 + 1))

= 0,98838717461466533949

Changing the values to get the desired ones after incrementing by one, not before...

32768 / ((127 + 1) * (255 + 1))

= 1

I would say this is the reason of the problem, and in that case its a bug in MxCube generated code. I will test this at monday morning and let you know. Thanks.

[waclawek.jan]

Posted on March 17, 2018 at 10:16

You seem to be more confused than before. So just for clarification: the values actually written into the RTC_PRER register, PREDIV_A and PREDIV_S, are used in the formula as fLSE/((PREDIV_A+1)*(PREDIV_S+1)). As you've told us

https://community.st.com/0D70X000006T03MSAS

, they are correctly set to 127 and 255 respectively so there's nothing to check in this regard.

Have you already performed the test to distinguish between software and hardware source of error I suggested

https://community.st.com/0D70X000006T03MSAS

?

JW

[Lukasz Przenioslo]

Posted on March 17, 2018 at 10:21

Waclawek.Jan

‌ sorry, of course you are right...

No I havent done that yet as I was forced to jump around the topics, just found time to get back to it now, thus the confusion maybe (also wanting to replace the whole crystal with caps as mentioned here too).

I will prepare a test program (as you suggested) at Monday instead, thanks.

[waclawek.jan]

Posted on March 17, 2018 at 10:22

Szymon,

I've just noticed this (in your recommendation to set LSE to MCO):

Regarding pin configuration, please keep default slope setting, which is low:

Why would that be necessary - or even appropriate, once we are talking about measuring the LSE frequency as precisely as possible? I'd expect we would want to eliminate the possible influence of external circuitry on the measured time between edges (whether consecutive or being multiple pulses apart), and setting the output drive to low would just allow that, IMO. Is there something I've overlooked?

JW

[waclawek.jan]

Posted on March 17, 2018 at 10:23

Please do just one change at a time, and tell us of the result.

Jan

[Szymon PANECKI]

Posted on March 17, 2018 at 15:26

Hello Jan,

Slope setting of I/O pin impacts speed of signal switching from low to high and from high to low on the pin. For low-frequency signals it is enough to set low speed, while for high frequency signals it is recommended to set this speed to higher value.

Some time ago I made an exercise with outputing different clock signals on MCO pin and capturing them by scope. I noticed that for LSE (32.768kHz) shape of the signal was the best when slope setting was set to low. For different settings I observed something like overshoot shown below.

These other settings (medium, high and very high) are better for high frequency signals. For example when MCO outputs System clock set to 80MHz (PLL). Then very high speed is appropriate (if IO speed would be set to low or medium when MCO outputs 80MHz clock, then there would be no signal on the pin, as signal would be changing faster than IO is able to switch).

As a result my conclusion from the exercise was that it makes sense to set low IO speed for low frequency signals to avoid overshoots and high IO speed for high frequency signals to keep IO switching fast enough for outputing the signal.

Regards

Szymon

[waclawek.jan]

Posted on March 17, 2018 at 16:27

Szymon,

Sure, for most of the applications, the output slew rate has to be set to the (s)lowest viable setting, to reduce EM emissions and limit/avoid the various HF effects on signal and power and ground. But here we want to measure the period of 32kHz signal with possibly 100ppm resolution, that's around 3ns. The max. rise/fall time for the 'L4xx for a 10pF load at 3V supply is given as 17ns for the 'low speed setting' (OSPEEDR=0b00) and 2.5ns for OSPEEDR=0b While you can argue that measuring time between the same voltage level in a two successive rising edges eliminates much of the error, yes it does, but still with lower drive the output is more prone to interferences and noises, so you are always better off in this particular regard when going to higher drive.

So, while still generally is LOW setting appropriate for a 32kHz signal, in this particular case, I personally would rather set it HIGH and then investigate and mitigate the cause for overshoot and ringing - which more often comes from the imperfect tools used for measurement (e.g. poor oscilloscope probe grounding/coupling, overcompensated divider probe) than materially existing in the measured signal.

JW

[Albert]

Posted on March 19, 2018 at 11:33

@ S/T specialists: what is the initial accuracy for the STM32 main clock ? If it is good enough, you can make a frequency meter with another STM32 by counting fclock during 32kHz period. The accuracy is made by S/T and the resolution is 1/fclock. If initial accuracy is poor, TCO's are not expensive.

If your hardware is correct, the 32kHz output will be strong enough to drive the counter input. If not, you can add a quick and dirty capacitance coupled emitter follower. Google for frequency meter input amplifier.

I think there's an application note on the S/T website with a trick to make a reciprocal counter with STM32 timer using it's hardware.

Make your own tools !

Theo

[henry.dick]

Posted on March 19, 2018 at 12:16

The internal RC clock is often 1 percent - higher for mcus capable of crytal-less USB. 

But using a crystal here is more than enough. Those are often specs to 20ppm and in reality within 10pppm. One can easily write a piece of code to use the main crystal to measure the 32k crystal, all on the same chip.