2018-03-04 10:57 PM
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.2018-03-08 07:52 AM
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
2018-03-08 09:07 AM
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.
2018-03-08 09:12 AM
Should be able to refine things coarsely via the prescalers, and finely via clock insertion/removal
2018-03-08 09:25 AM
that's a non-solution solution, as it deals with the symptom of timing error, not the root cause of the timing error.
the issue (why a 600ppm clock becomes a 6000ppm clock) is fairly easy to identify and solve.
2018-03-08 10:44 AM
henry.****
I thought the sulution-solution is to replace the caps and fix prescalers as suggested by bothTurvey.Clive.002
andDUPUIS.Jean_Luc
. So what is the exact solution, as this is getting pretty mysterious?2018-03-08 01:41 PM
I doubt your oscilloscope has the precision to measure at the level you need. Just to put the things in perspective, the 600 ppm measured, would readily become 6000 ppm (actual situation) if instead of 30,5 us you would read 30,34 us or 30,65 us, which is difficult to distinguish on your instrument (even the 8192 samples per 100 MHz are a source of potential imprecision). Therefore only a calibrated frequency meter with at least a decimal after the Hz reading (i.e. 0,1 Hz precision) can help here.
It is very true that a crystal cannot drift so much, but if the capacitors are not properly selected (to match the crystal), then the STM oscillator can oscillate on a totally different frequency (free-running mode).
2018-03-08 02:58 PM
we are speculating here but I would suspect that the 5us measurement is likely correct. very unlikely a crystal would be 6000ppm off. ceramic resonators generally don't operate down this low to 32Khz.
so the issue is likely bad software (the RTC was inadvertently written to, for example. or LSE is used, wrong prescaler, ...), or bad observation (it really is 2 minutes off over a 50-hour period, ...).
either one is fairly easy to confirm, fortunately.
2018-03-09 08:41 AM
If I would be in your position, this is what I would do:
1) First and foremost, I would make sure that the oscillator's frequency is indeed 32767 Hz; without this information and this accuracy, it makes no sense to look further. And your oscilloscope is of no use here, its accuracy is not sufficient.
2) Now, if the frequency is indeed
32767 +/- 3 Hz (3 Hz means about 100 ppm at this frequency, which is already at the limit for an RTC, but it is the what the cheapest crystals would exhibit), then I would look at the software, if the prescalers are correctly configured -- there are a lot of examples on the ST web site.
3) If the frequency is much further away, then probably you have selected incorrect capacitors for the crystal you use. Or, your crystal is defective (quite improbable). Anyway, at this point I would know that the issue is with the crystal and capacitors, or possibly with the layout. These oscillators operate at very high impedances and as someone already noted, tend to be very sensitive to moisture. You may also want to look at the
RCC backup domain control register, in particular the LSEDRV bits to select the proper crystal drive (maybe your crystal is a bit 'lazy' and needs more drive).So I am afraid there is no way around a good frequency meter...
PS: you may also want to read ST's application note AN2867 “Oscillator design guide for ST microcontrollers�?.
2018-03-09 09:26 AM
>>PS: you may also want to read ST's application note AN2867 “Oscillator design guide for ST microcontrollers�?.
Yes, and perhaps probe ST for L4 specific details. I've seen one of the NUCLEO docs showing a note about larger caps on the L4 model, but I'm not clear is the BOM is otherwise identical or a different crystal is in use.
Determine what you've actually built.
Determine if that behaves within design parameters, or not.
Determine if you want to fix the circuit to correct the behaviour.
Determine if you want to adjust the software to work with the circuit you have built.
2018-03-09 09:56 AM
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.