LPC17xx: Check if RTC is running

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.

Solution

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.)