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.

[waclawek.jan]

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 Przenioslo]

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?

[Lukasz Przenioslo]

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.

[waclawek.jan]

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 Przenioslo]

Posted on March 05, 2018 at 20:06

Do you have any more insights?

[Tesla DeLorean]

Posted on March 05, 2018 at 20:23

The red outlined portion could be confusing it defines PREDIV_A as 127 (128-1), and PREDIV_S as 255 (256-1), allowing the Fck_spre formula to be correct.

abs25-32.768khz-6

http://www.abracon.com/Resonators/abs25.pdf

 

Are we sure the 6.8pF capacitors are actually suitable for a 6pF crystal? Would these need to be closer to 3pF? You've specified the 6pF part not the 12pF one. If you screw up the loading it is likely to be off frequency.

Would strongly recommend pushing the LSE out of MCO (or whatever works on the L4) and measuring with a calibrated precision frequency counter, or clock HSE from a ppb source and measure with the TIM internally.

[Lukasz Przenioslo]

Posted on March 05, 2018 at 20:26

I will check the caps tommorow. I could also push the LSE on a pin and measure the frequency with a scope (if thats possible). Thanks.

[Tesla DeLorean]

Posted on March 05, 2018 at 22:32

I think the time base in a precision frequency counter would be preferable (OCXO timebase option), or a GPS disciplined frequency source.

[henry.dick]

Posted on March 05, 2018 at 23:09

Don't bother - crystals pull ability isn't going to be remotely close the kind of errors you saw here.

I would make sure that the etc is set up right first. Then the right clock is used, then the crystal is the correct one / working, and then your code is correct - you aren't writing to the etc incorrect values, ....