LPC17xx: Check if RTC is running

Question

I am using NXP LPC17xx family microcontrollers (LPC1759 and LPC1768).

How can I determine if RTC is running for sure?

I am doing a test on

LPC_RTC->CCR & RTC_CCR_CLKEN

but it seems no much reliable. I have seen values in year 3197 or so when turning on my device.

How can I tell if RTC is running and its value is not corrupt?

---

EDIT:

I ended up adding a simple sanity check in RTC values:

bool        DateTime::validate( const RTC_TIME_Type &time_info )
{
       if ( time_info.YEAR > 2100
               || time_info.DOY > 366
               || time_info.MONTH > 12
               || time_info.DOM > 31
               || time_info.HOUR > 23
               || time_info.MIN > 59
               || time_info.SEC > 59 )
               return        false;

       return        true;
}

It is run during my POST, as suggested bellow.

Answer 1

I battled with the RTC on that chip's grandfather (LPC2148) about 5 years ago. If you look on the Yahoo LPC2000 group (it also covers the LPC1000 chips) you'll see the RTC & its issues come up a lot.

Anyway, I'm going from memory here, but I think I concluded that reading the status register wasn't reliable enough. Maybe the issue was that when power was removed, if the battery backup was absent, things would get scrambled...

So what I recall I did was the following, during the boot phase:

(1) Enable RTC peripheral

(2) Read ALL RTC registers. In firmware, have "out of bounds" min & max values for each field (e.g. year must be at least 2005, and no larger than 2030)

(3) If any value is out of range, reset date & time to some hard-coded value (e.g. Jan. 1, 2005) (product would let user adjust time/date once booted)

(4) Take snapshot of registers; wait AT LEAST one second (use timer peripheral to measure time), then make sure the value changed. I might have gone so far during boot-up as to set the values so that a 1-second tick would/should cause everything to roll over (probably 1 second before midnight, Dec. 31), ensure everything changes, then write back the original value + 1 second. (You would want to do this right as the value changes to avoid slipping seconds)

I will try to dig up the code and see if there was something more. I just recall finally concluding I had to run the damn thing & watch it work before I passed the P.O.S.T. for that peripheral.

(I kind of mentioned it in passing, but just to re-iterate... if your values seem corrupted on power-on, make sure your battery back-up circuitry is rock solid - even a basic circuit with a pair of diodes normally suffices. Could be that the clock is running when the product is running, but that when power is removed, its brains get scrambled.)

Answer 2

Also confronted with temperamental rtc's here....

I don't think a really reliable test is possible, you could store the last recorded time somewhere in non volatile memory, and check that the clock hasn't moved to a past date, and you can also test that the delta between two checks is not too big. That would catch something like the year 3000, but you cannot reduce the tested time lapse to say 1 month - you want the thing to wake up even if it was shelved for say a year.

Do you have the possibility to consult a time source at startup? Eg an ntp server or some other device that your controller speaks with that can be considered synchronized with a reliable time source?

Answer 3

You can route the RTC clock to an external pin and watch it on an oscilloscope or a logic analyzer.

IIRC I did just that for LPC1766/1768 (I have two identical boards populated with different processors).