RTC running fast on STM32L433

[Scott Dev]

Hi

I have setup the RTC on the STM32L433 and the clock is running about 5 second fast in 24 hours. I am using a 32.768KHz crystal, which is directly next to the processor . I have set the

RTC->PREDIV_A to 0x 7f, and RTC->PREDIV_A to 0x ff, and selected the LSE clock, cant think what it can be, anyone help?

Thanks

Scott

[Scott Dev]

Thanks everyone for your help. I am still learning parts of the stm32, and never new about the MCO pin, and the SetSmoothCalib (I only use the HAL for initilialisation then use the registers). Looking at the processor I am using , the MCO pin seems to be on PA8, which unfortunatly I dont use (I will have to make sure my other boards has this going to a pad for testing). I then can measure the correct frequency. I assume if I have x amount of boards with one design, and components the same, then I should only really have to do this on one board and the rest should (well, approx) be the same?

One thing, I dont have any load capacitors on the crystal. The dev board I started on didnt, so I assumed this is the way to go. Is this correct?

Thanks again, I will look into these.:thumbs_up:

[waclawek.jan]

> SetSmoothCalib (I only use the HAL for initilialisation then use the registers)

HAL is open source so you can look at that function. Its sole purpose is to write concatenation of the input parameters to RTC_CALR register. Before doing so it performs the usual RTC unlock and checks for RECALPF flag (which would be set only if previous write to the same register would have occurred closer than 3 ticks of the synchronous part of RTC counter).

Read the RTC smooth digital calibration subchapter in RM.

> One thing, I dont have any load capacitors on the crystal. The dev board I started on didnt, so I assumed this is the way to go. Is this correct?

It's not impossible that the tracks capacitances are enough, but it also may be the source of the deviation. Don't be afraid to experiment, a few pF at a time. And don't forget to read AN2867.

JW

[sarp daltaban]

I have the same exact problem using STM32F413VGTX.

5 secs per 24 hours.

Have you found a solution so far?

Bests

[VaZso]

I have recently ran into this issue, so I had to find out how this works as data sheet does not really provide much information.

I am using an STM32F4 series MCU.

First of all, I have a 32 kHz quartz, so at first, the two dividers are have to set correctly for being in the correct range.

Basically, it can add 1 pulse per 2^11 clock cycles if "RTC_SMOOTHCALIB_PLUSPULSES" is set.

Also, it can subtract given pulses in the specified "smoothcalib" period, which is 32 seconds for me.

So, I have a quartz with a 32768 theoretical frequency.

It provides 1048576 pulses per the 32 seconds period where it can generate 512 additional pulses based on 2^11 per 1 cycle during this 32 seconds period.

Generally, it does not really make sence, but the 512 pulses written above comes from here.

That means, it you enable plus impulses and subtract 512 pulses, then it behaves if you were not doing anything, so by decreasing 512, the clock will receive more and more pulses, thus, it will be faster than original state.

In this 32 seconds period, it can subtract up to 32767 pulses, which means the clock can be adjusted about +42 to - 2700 seconds per day.

Also, in a whole day, 32 seconds are exactly happen 2700 times.

Thus, it can subtract n*2700/32768 seconds per day, where n is the value can be given to subtract as "SmouthCalibMinusPulsesValue" parameter.

That means the modification of this value by +-1 will have a theoretical effect of +-0.0823974609375 seconds per day.

So, here is the number written above comes from.

Sorry if I wrote something you knew, just wanted to make it more clear.

Also, what I have ran into second time is the HAL-generated RTC initialization code still halts the RTC clock for some hundred milliseconds by every restart, so the clock will be behind more than it should depending on the number of restarts.

So a check is also needed to ensure unnecessary initialization when RTC clock is running.