LSE RTC calibration

electrobling Mon Feb 19, 2018 9:28 pm

I have made progress with software to calibrate the STM32F103C8 RTC. I did my first testing today on 3 different Blue Pill boards. If you look at ST app note AN2604, http://www.st.com/content/ccc/resource/ … 167326.pdf you will see that it is possible to apply a cal factor to the LSE divider chain, so as to compensate for frequency error in the oscillator circuit. I began by modifying the RTClock library because it lacked some features I needed (or wanted). The technique is to apply an accurate PPS signal from a GPS receiver to an input pin, and compare with the 32kHz divider. That yields an accurate measurement of the frequency. Then an appropriate compensation value is calculated and loaded into the processor’s calibration register, which is in the backup domain and will remain intact as long as a battery is connected. The result is that the RTC can be automatically calibrated to about +/-1PPM. Here is a sample run:

acquired PPS pulse... starting calibration
0: diff = 0 ................................

32: diff = 1 ................................

64: diff = 2 ................................

96: diff = 3 ................................

128: diff = 5 ................................

160: diff = 6 ................................

192: diff = 7 ................................

224: diff = 8 ................................
*** Calibration completed ***

Calibration cycles:8

Calibration time:256 seconds

measured divider difference:9

calculated correction factor:1.12

rounded correction factor:1.00

calibration value result:65

Calibration values applied, testing now...
0: diff = 0 ................................

32: diff = 1 ................................

64: diff = 1 ................................

96: diff = 1 ................................

128: diff = 1 ................................

160: diff = 1 ................................

192: diff = 1 ................................

224: diff = 1 ................................

256: diff = 1 ................................

288: diff = 1 ................................

320: diff = 2 ................................

352: diff = 2 ................................

384: diff = 2 ................................

416: diff = 2 ................................

448: diff = 2 ................................

480: diff = 2 ................................
*** Test Cycle completed ***

Test time:512 seconds

measured divider difference:2

calibrated accuracy:0.131 PPM

Calibration test complete...

To calibrate again press a key to continue:

Replies

electrobling Mon Apr 02, 2018 1:35 pm

[hyperion – Fri Mar 23, 2018 3:16 am] –
create PR to calibrate RTC which enables tamper output on PC13 pin
https://github.com/rogerclarkmelbourne/ … 2/pull/467

Maybe I should try to fold this request into an new request for an upgrade to RTClock since I have already implemented everything else I mentioned in the previous post?

chinhduy Tue Apr 03, 2018 8:23 am

What circuit are you using to provide a voltage at VBAT? I discovered that it is important to have a stable external voltage there. I’m now using a pair of Schottky diodes to supply it either from a battery, or VCC.

I already have a compensated clock running on my desk. I just haven’t tackled the problem of how to share the code. For example, the RTC library currently doesn’t provide access to the calibration constant register. I had to mod it to do that.

I simply connected the CR2025 battery to the VBAT.

electrobling Thu Apr 05, 2018 1:42 pm

[chinhduy – Tue Apr 03, 2018 8:23 am] –
I simply connected the CR2025 battery to the VBAT.

Be aware that ST documents a small current surge to the battery on VBAT at power up time. Some batteries might not like that. The other disadvantage with that approach is that the battery will always be powering the backup domain. With the dual diodes, power comes from VCC when the device is on (which, for my application, is mostly all the time… not sure what your usage is). That means that the battery will not last as long. Also unlike VCC, the voltage on the battery will drop over time, which will affect timing.

chinhduy Fri Apr 06, 2018 8:53 am

My application is Real Time clock, the VCC is not always available. I used two new battery with 2 new Blue Pill to compare. After one day, the first one was late 2-3s compare to my laptop time and the other was late 3 hours.
And my locale board vendor said that it was normal, the RTC of stm32f103c8t6 was that unstable, he advised me to use the DS3231 module.

ahull Fri Apr 06, 2018 9:33 am

I suspect the STM32F103XX is not the problem.

More likely the crystal or the associated capacitors are the reason for the poor clock performance.

The STM datasheet is very specific about what type of crystal to use and the type and values of the caps and the board layout, but bluepill vendors completely ignore all of this and use whatever was cheapest at the Shenzhen market that day, and as a result, things either work acceptably well, or not at all. All of the boards I have tried, worked fine, including one that I added a salvaged crystal from an old clock module. I didn’t expect it to work, but it too was fine.

If you get a board with a decent crystal and the correct caps, it works fine, but it is a bit of a lottery. The DS3231 is completely self contained, so it is difficult for the cheap board manufacturers to screw things up. Difficult, but not impossible, such are the joys of using low cost boards from no-name vendors. :lol:

If you have the time, you could try substituting the crystal on the “3hrs a day” board, and see if it improves.

electrobling Tue Apr 10, 2018 4:52 pm

Yes, the layout is thoughtless. It’s verging on criminal to route the crystal connections to I/O headers, as the Blue Pill does. I’ve only tried 4 BP’s so far, the RTC has been fine on all of them, but I have been omitting the pin headers on PC14 and PC15 when I assemble. There are some traces you can cut, but it’s not worth the hassle. If I saw one that was say, 3 hours a day off, I would be looking for cold solder joins – more likely than a component defect. Try reflowing them.

Pray tell – what type of battery did you use?

ahull Tue Apr 10, 2018 6:20 pm

[chinhduy – Fri Apr 06, 2018 8:53 am] –
My application is Real Time clock, the VCC is not always available. I used two new battery with 2 new Blue Pill to compare. After one day, the first one was late 2-3s compare to my laptop time and the other was late 3 hours.
And my locale board vendor said that it was normal, the RTC of stm32f103c8t6 was that unstable, he advised me to use the DS3231 module.

There have been a couple of other threads about RTC issues, and so far as I recall they all turned out to be crystal related, or poor soldering by the board producer, rather than a faulty STM32F103

For example here-> viewtopic.php?f=3&t=2421&p=32443&hilit= … bay#p32443
.. and here.. viewtopic.php?f=15&t=132 (although this thread does get a little long, I blame the OP )

Wong value, damaged or missing load capacitors, or load capacitors inappropriate for the crystal will have a marked effect on accuracy, or may stop the thing from oscillating completely. Likewise an cracked, or stressed crystal will have different characteristics from a good one. Damaging the crystal with poor handling during manufacture can cause it to end up with stress cracks due to aggressive bending of its pins or overheating it when soldering.

chinhduy Tue Apr 17, 2018 9:54 am

There have been a couple of other threads about RTC issues, and so far as I recall they all turned out to be crystal related, or poor soldering by the board producer, rather than a faulty STM32F103

That should be, I didn’t think that STM would sell bad MCU. The Blue Bill board I got was cheap Chinese clones, poor quality was acceptable.
DS3231 is a good solution for RTC and external EEPROM. No need to emulate the eeprom anymore.