Associate III

Question

STM32L4 low RTC precision

Forum|Forum|8 years ago
March 5, 2018
14 replies
22100 views

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.

This topic has been closed for replies.

waclawek.jan

Super User

Posted on March 05, 2018 at 11:54

Check (read out) respective RCC register (RCC_BDCR.RTCSEL) whether you are clocking RTC from LSE indeed.

Check (read out) the RTC divider registers.

If you have HSE as system clock source, measure LSE frequency using the TIM15/TIM16 remap.

JW

Lukasz PrzeniosloAuthor

Associate III

Posted on March 05, 2018 at 12:38

Check (read out) respective RCC register (RCC_BDCR.RTCSEL) whether you are clocking RTC from LSE indeed.

Checked:

Check (read out) the RTC divider registers.

Checked. According to this its fine:

If you have HSE as system clock source, measure LSE frequency using the TIM15/TIM16 remap.

Yes I am using HSE. Could you please elaborate more on what am I exactly to do?

waclawek.jan

Super User

Posted on March 05, 2018 at 15:09

In option register of TIM15 you set CHi to be redirected to LSE, and the proceed with measuring period as you'd do with measuring external signal's period.

However, it's very unlikely a crystal oscillator would depart >5000ppm from its nominal.

Can't this be

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

? Note that it does not need to be reset as such; it may be wakeups going through the same flawed Cube/HAL routine.

JW

Lukasz PrzeniosloAuthor

Associate III

Posted on March 05, 2018 at 15:29

However, it's very unlikely a crystal oscillator would depart >5000ppm from its nominal.

I doubt that as well.

Regarding your link, I am not sure either those situations can be alike, since I do not put the MCU to sleep at any point as well as reset it. The MCU simply runs at max frequency (80 Mhz) all the time.

I just run a quick test in order to check either the RTC really looses time after resetting. This seems to be true. I have reset the device by pulling #RESET pin low couple time while observing the logs. I pulled the reset low for around 300 ms - 1s. Each time after I deasserted it the time did not change, as it would stop.

Then again, I am not sure this addresses my issue.

Maybe its the way I read the date and time? Each time after I get the time by issuing HAL_RTC_GetTime, I then also read out the DR shadow register in order to obtain proper date. Even If I dont read the date after I read time, I read the shadow register in my routine. Could this be the case?

/*

* @brief Reads the current time from logger RTC register.

* @param date: pointer under which the time struct is going to be saved.

* @return HAL_OK on successful time reading.

*/

HAL_StatusTypeDef cal_getTime(RTC_TimeTypeDef* const time)

{

assert_param(time);

assert_param(logger.rtc);

HAL_StatusTypeDef retVal = HAL_RTC_GetTime(logger.rtc, time, RTC_FORMAT_BIN);

if (HAL_OK == retVal)

{

// unlock the shadow register by reading

volatile uint32_t dump = logger.rtc->Instance->DR & RTC_DR_RESERVED_MASK;

(void)dump;

}

return retVal;

I am not sure... Nothing else comes up in my mind.

T J

Senior III

Posted on March 06, 2018 at 02:58

To get good Time of Day,

Year after Year...

Dallas DS3232

otherwise,

once you have attained the correct quality xtal/caps values,

you must protect them from any humidity influence.

baking and conformal coating is your best chance.

Lukasz PrzeniosloAuthor

Associate III

Posted on March 06, 2018 at 05:34

Additional component just for date/time tracking here is not an option.

I can always sync with NTP server, what I do anyways. I just want to do it as rarely as I can (I was thinking once a week will be a good choice). But after around 50 hours I am 20 minutes off, so there has to be something wrong.

T J

Senior III

Posted on March 06, 2018 at 22:04

Like Clive said, you should use a frequency counter to check the crystal.

and the Caps should match the crystal load parameters. Then you should be much closer.

Albert

Visitor II

Posted on March 08, 2018 at 11:56

Your design is wrong. You should have 6pF for (C16.C17/C16+C17) + Cx, with Cx tracks + STM32 pins capacitance (few pF).

Crystals with CL=6pF are made for direct connection to microcontroller/RTC and hard to design.

Take a 12.5pF crystal (the most used value) and C16=C17=22pF. Have a look on the STM32 hardware manual regarding the crystal power.

Theo.

Tesla DeLorean

Guru

Posted on March 09, 2018 at 17:56

The original STM32 designs needed 6pF 32.768KHz crystals, and didn't work at all well with more common 9pF or 12pF ones. Not starting being a particular issue for F1, F2 and F4 models.

These issues have been addressed in newer designs.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

henry.dick

Associate II

Posted on March 09, 2018 at 21:11

the issue there is related to insufficient drive, to my undrestanding, on F1 chips -> i'm not aware of F2/F4 chips having similar issues.

not sure if that applies here as the oscillator is obviously working, unless the clock is switched to LSE -> if so, the error of 6000ppm wouldn't sufficient.

the whole thing is fairly easy to debug.

Danilotto Runi

Associate

Posted on March 08, 2018 at 13:57

In the meanwhile, here is an interesting reading about the hardware pov

http://www.st.com/content/ccc/resource/technical/document/application_note/c6/eb/5e/11/e3/69/43/eb/CD00221665.pdf/files/CD00221665.pdf/jcr:content/translations/en.CD00221665.pdf

Albert

Visitor II

Posted on March 08, 2018 at 14:01

thanks for the like.

To be complete, capacitors should be 22pF/C0G class and at 32kHz, the crystal is thick and you can't destroy it even at full power. But you can tweak it to reduce power consumption.

Theo

Lukasz PrzeniosloAuthor

Associate III

Posted on March 08, 2018 at 14:05

Ok, so now I have choosen these:

https://www.tme.eu/gb/details/abs25-32.768khz/smd-quartz-crystals/abracon/abs25-32768khz-t/

https://www.tme.eu/gb/details/cc0603frnpo9220/0603-mlcc-smd-capacitors/yageo/cc0603frnpo9bn220/

Thank you.

Albert

Visitor II

Posted on March 08, 2018 at 14:40

Fine. As suggested by Danilotto Runi, make a quick calculations with the Application Note regarding ESR and max power for your resonator.

Theo

henry.dick

Associate II

Posted on March 08, 2018 at 15:16

There are two parts to this issue?

1. Why is the crystal 600ppm off?

2. Why is the rtc 6000ppm off?

Once you lay that out, it becomes crystal clear where to focus your effort.

henry.dick

Associate II

Posted on March 08, 2018 at 17:07

All the effort to get the crystal to run close to its target frequency is basically mis-read directed. At 600ppm off, the crystal is slight above the high end of its possible range. More importantly is only small part of the observed error. To put it another way, even if you get the crystal to run on target, the rtc is still off 5000ppm+.

If you want to solve the problem, you have to answer this question: why a 600ppm off clock becomes a 6000ppm clock?

I offer you two possibilities that no one has been willing to explore:

1. Wrong software.

2. Wrong observation.

You just need to eliminate each, one at a time.

Spending any more time on the crystal is a waste of your time. Until you get to as point where the rtc is 600ppm off as well.

Tesla DeLorean

Guru

Posted on March 08, 2018 at 17:12

Should be able to refine things coarsely via the prescalers, and finely via clock insertion/removal

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

jnalasco

Associate

Posted on March 08, 2018 at 16:52

We had a similar problem but with a different part (we used an STM32F765)

Short of changing components we found a fix by adjusting the LSEDRV bits in RCC_BDCR. You'd need to check if this field is even in the RCC_BDCR of your device

gbm

Super User

Posted on March 11, 2018 at 10:31

I tried to read all the answers in this topic and I cannot find an answer similar to my experiences - excuse me if overlooked it. Here are my suggestions:

The L4 LSE circuit is EXTREMELY sensitive to interferences. Any change of state on the tracks on the PCB going close to the oscillator (even if no current flows through them) results in LSE skipping several pulses and getting out of sync. What you observe is not a surprise, it's how it typically behaves.

To eliminate the problem, make sure that:

- the connections between MCU and crystal ale short,

- there are ABSOLUTELY NO SIGNAL TRACES in top layer under the crystal and in the next layer under the traces connecting the crystal to MCU,

- if there are such traces - use a crystal with a metal can and ground its case - it may help a little on your prototype board,

- there is a solid ground plane under the crystal and its traces to the MCU,

- the capacitors are between the MCU and the crystal or at the crystal pins, not outside of the crystal with long connecting traces,

- the MCU pins close to the LSE pins are not used for any waveform output (including MCO) - better don't use them at all.

Fiddling with LSEDRV setting may help.

Also note that if your LSE circuit is not perfect and you use it for synchronizing the main clock (a very useful option in L4 for eliminating the HSE crystal), you will encounter UART and USB data errors (like I did).

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

Lukasz PrzeniosloAuthor

Associate III

Posted on March 11, 2018 at 10:47

Thank you for answer,

To answer your questions, here is screenshot of how the crystal is routed:

Its the Y2 crystal.

I would not say that your guidelines were followed. I paid a lot more attention to the HSE placement to be fair, as I thought at this frequency (32 kHz) there are not hard constraints when it comes to placement. This is a 2 layer board so the is no solid GND plane underneath the crystal. Do you really think that this could make the difference?

T J

Senior III

Posted on March 11, 2018 at 13:29

If

Mazur.Grzegorz

‌ is correct, you have noise injection from the ground fills, from the switchers.

I would remove the ground fill from the crystal circuit area totally and off C16, C17, try to move underside tracks away if possible.

Run a 15thou trace from C17,C16(Gnd), to pin 10 Vss, before it hits C25, then connecting to the remaining ground fill/track.

This will mostly block any switcher noise you have propagating along Vss,.along your ground fills.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded