Report
3 years, 5 months ago.

LPC1768 RTC: 40 minutes too slow every day?

Hi all, I've made a device that synchronises its internal RTC every day with the time, derived from a GPS-module. All interesting events are logged into a file on an SD-card.

Now that I look at the logs, I see the time being synchronized every day at 23:20 (instead of 0:00). So every day, the RTC is 40 minutes late, compared to the GPS. The device is continuously powered, and also the backup-battery is connected to the mbed. I'm using a PWM output, some interrupts and quite some calls to RTC=time(null).

Can anyone of you think of a reason why the RTC would run too slow, or miss cycles, hickup or whatever?

Thanks, bye, Patrick

can you see if the time is slowly decrementing through out the day?? Is there a Reset somewhere?

It sounds like the GPS is originating the time-sync, correct??

posted by Gary Z 13 Nov 2015

have you installed the 32Khz crystal AND bypass caps?- are you running on main power or do you remove power and rely on the backup battery? I think you can select the clock source for the RTC on this chip?

posted by Gary Z 15 Nov 2015

Hi Gary, thanks for your reply. During the day, the RTC is decrementing (compared to the GPS-time). Once a day I synchronise the RTC, when the GPS-date changes. I've NOT installed a 32kHz crystal and bypass caps, because I assumed those are already on the mbed-board. On top of that, I do NOT remove the power but still have a backup-battery connected. There doesn't seem to be any reset during the day (which would more likely lead to a "jump" in time rather than a gradual delay).

I did NOT select a clocksource for the RTC yet. How should I do that?

posted by Patrick van Marrewijk 16 Nov 2015
Comment on this question

2 Answers

3 years, 5 months ago.

Hi Patrick.

With a 40 minute error, I suspect there may be a hardware reason for that much error. You show the LPC1768 in your profile and that does have the 32 Khz crystal.

If you have access to a scope, perhaps you could probe the crystal. Take care that on one side, it will be quite sensitive to the scope itself, and on the other it should be less-so. There may also be a way to enable a "clock out" - but I have not had the need, so I'm not sure.

Next, do you have a coin cell powering the clock? I couldn't quite tell from your note if the backup-battery is for the whole module, or just the clock. [Should that make a difference? I don't know. My modules with RTC needs all have the coin cell, so I never tried without one]

The RTC does have an adjustment register, to compensate for tolerance error - but I would not imagine it has the range to compensate for 40 minutes in a day... But, let's not rule that out. If that register picked up a bad value, perhaps that is it.

That said, I have some code that tries to make the adjustment, you're welcome to look it over, try it, and perhaps make it better. Along the way I hope you solve your issue. TimeInterface is my project, and as I recall, I had only a few seconds a day deviation to compensate for.

3 years, 5 months ago.

The spec for the LPC1768 RTC crystal is 20 ppm, so you are seeing frequency errors far out of spec. I had measured my RTC crystal frequency error at 20 ppm. You can measure frequency with a GPS PPS signal or with an NTP host. Or you can use the MCU's crystal (Timer microseconds) as in the following program https://developer.mbed.org/users/manitou/code/driftrtc/ Another way to check RTC drift is with RTC second-alarm handler (checking how many micros between RTC 1 second interrupts).

Of course, these short-term internal measurements may not reveal a problem where the RTC and/or MCU is pausing. To detect such pauses, you'd need a program to alert you when the RTC time has suddenly deviated a large amount from the GPS time.

Hi, I noticed this effect on multiple devices, so that rules out any hardware-related inaccuracies. I suspect that a lot of calls to the RTC might cause it to miss a count every now and then. Added up during the day, those missing counts might results in ca. 40 minutes delay. So far my theory: now the challenges how to confirm and fix it....

SOLVED 25-11-2015: I use interrupts now to do my things every now and then, instead of continuously reading the RTC, comparing it to a preset value and acting on it (or not). Now it seems to drift ca. 10 seconds per day. Accurate enough for my application. Thanks anyone for thinking with me!

posted by Patrick van Marrewijk 19 Nov 2015

To post an answer, please log in.