Real Time Clock Setup on LPC4357

[lpcware]

Content originally posted in LPCWare by PN on Tue Feb 18 12:43:17 MST 2014
Hi,

In my current application, I use the real time clock driver provided on lpcware. Initially, reading and writing the RTC seemed to

work well with this driver. But once I added a watchdog timer to the application, somehow the RTC seemed to have issues during

setup.

The RTC_Init() routine would always crash when stepping through it on the debugger and the clock time was always off.

I guess it could be either because it would take forever for the time value to be set and the clock to start running, or because the

clock would freeze, not get initialized with the new time and start running again from where it left off.

I tried adding a delay of 2 seconds after every RTC register write, based on what I read about the LPC RTCs. This seemed to

allow me to step through the Keil debugger but the time was still not set correctly. It would lag by several minutes.

If I take the watchdog timer out, everything works perfectly fine with no changes to the RTC driver.

On the other hand if I keep the watchdog timer in and do not write or set the RTC, everything works fine then too.

Has anyone had a similar issue with real time clock setup? Any suggestions?

Thanks in advance!

[lpcware]

Content originally posted in LPCWare by tkggitfk24 on Thu May 12 01:26:14 MST 2016

---

Quote: ollopa
So it will take about 1ms at startup to determine if the 32kHz oscillator is running. If it is, there is no need to repeat the long initialization code that disturbs the 1Hz timing. If it is not running, start it up and wait 2 seconds before accessing any RTC registers..

---

You says "So it will take about 1ms at startup to determine if the 32kHz oscillator is running."

DOWNCOUNTER and PRESET are zero after reset. And LPC user manual says that "Only write to the Alarm timer registers while the 32 kHz oscillator is running."

That's realy confused. We can't write DOWNCOUNTER and PRESET registers when not make sure 32 kHz oscillator is running. So how to check DOWNCOUNTER is down?


Can you descript it in detail?

[lpcware]

Content originally posted in LPCWare by ollopa on Mon Jan 18 17:19:04 MST 2016

---

Quote:
It's OK on my LPC4357-EVB (evaluation board). If I use my own board (with 32,768kHz crystal and LPC4357 in LQFP208), there is some problem and it doesn't leave the first do-while in init (the LED never turns off). Can you help me, where could be the problem, please?

---

It sounds like your 32kHz oscillator isn't running.  Double-check your circuit and selection of crystal.  Make sure you're using the correct load capacitance and that it's not outside the specifications of the LPC's driver.

Use the BASE_OUT_CLK register to route the 32kHz clock to the CLKOUT pin and confirm if it is running or not.  You could remove the crystal and input a 32kHz clock on RTCX1 to manually clock it for troubleshooting.

[lpcware]

Content originally posted in LPCWare by ollopa on Mon Jan 18 17:07:55 MST 2016

---

Quote:
and has commented out bits which clear the clock value (isn't that the point of a battery-backed RTC, to keep the value?) and disable calibration (why would you?).

---

I don't think these changes are as sensible as they seem.
[list=1]
  [*]The reset doesn't reset the time and date registers, it resets the counter divider that generates 1Hz from 32kHz.
  [*]Calibration is a manual process whereby you measure the actual number of counts required to elapse 1 second and load a calibration value into a register to correct for the difference.  You don't want to enable calibration (really compensation) without a meaningful value loaded into the calibration compare register.  Doing so will just lead to bad results.
[/list]

If you actually read the datasheet:

---

Quote:
1 CTCRST CTC Reset
0 No effect.
1 When one, the elements in the internal oscillator divider are
reset, and remain reset until this bit is changed to zero. This is
the divider that generates the 1 Hz clock from the 32.768 kHz
crystal. The state of the divider is not visible to software.

---

Look up CALVAL and CALDIR to understand why you don't want to enable calibration unless you've actually measured and calculated a value for CALVAL.


What NXP doesn't make clear is when you do and don't need to perform this initialization [s]and how  you can detect it[/s].

It's clear from the code and the datasheet that running through the initialization routine will disturb the 1Hz timing both by temporarily pausing it and resetting the counter divider.  This means the more often you restart the device, the more time slip the RTC will suffer.

It's also intuitive that the 32kHz/1Hz oscillator keeps running off the battery when the CPU is powered down, so I don't see any need to repeat the initialization sequence when powering the CPU back up.  A quick test shows empirically that my assumption appears correct -- once the clock is set up and battery-backed, I can remove the calls to Chip_RTC_Init(LPC_RTC) and Chip_RTC_Enable(LPC_RTC, ENABLE) and the RTC continues to keep correct time across CPU power cycles.  What's more, the long multi-second wait during initialization goes away.

So how can we detect when power is lost and the RTC clock has stopped?  We need to avoid accessing the registers when the clock is stopped or else the CPU may halt, and if we know the clock is running then we can avoid disturbing the clock generator and RTC timing.

On Edit, here is the answer from the datasheet:

---

Quote:
To confirm that the 32 kHz clock is running, read the Alarm timer counter register (DOWNCOUNTER, see Table 866), which counts down from a preset value using the 1024 Hz clock signal derived from the 32 kHz oscillator.

---

So it will take about 1ms at startup to determine if the 32kHz oscillator is running.  If it is, there is no need to repeat the long initialization code that disturbs the 1Hz timing.  If it is not running, start it up and wait 2 seconds before accessing any RTC registers.

[lpcware]

Content originally posted in LPCWare by J@N on Sat Apr 04 11:40:29 MST 2015
Hi,
I made a simple example for RTC on LPC4357 based on LPCopen. I want to init RTC, set the time and sometimes read it.

void RTC_Init (LPC_RTC_Type *RTCx)
{
LPC_CREG->CREG0 &= ~((1<<3)|(1<<2));// Reset 32Khz oscillator
LPC_CREG->CREG0 |= (1<<1)|(1<<0);// Enable 32 kHz & 1 kHz on osc32k and release reset
Wait(2000);

LED_On();

do
{
// Reset RTC clock
LPC_RTC->CCR = RTC_CCR_CTCRST | RTC_CCR_CCALEN;
}
while(LPC_RTC->CCR!=(RTC_CCR_CTCRST | RTC_CCR_CCALEN));

LED_Off();
    ....
    ....
}


RTC_Init(LPC_RTC);
RTC_SetFullTime(LPC_RTC, &time);
RTC_Cmd(LPC_RTC, ENABLE);


It's OK on my LPC4357-EVB (evaluation board). If I use my own board (with 32,768kHz crystal and LPC4357 in LQFP208), there is some problem and it doesn't leave the first do-while in init (the LED never turns off). Can you help me, where could be the problem, please?

Thanks in advance!

[lpcware]

Content originally posted in LPCWare by rgledhill on Thu May 01 01:14:25 MST 2014
There is a problem with the LPC Open code on RTC; by trying to be generic, it has a parameter which is a pointer to the RTC base address.  However if you step through with the debugger, or even just have the Locals window open with live updating of variables going on, it will crash.  This is because you mustn't try to access any RTC registers for 2s after turning on the clock, and the debugger will do so by trying to read the local variable!

I've attached our fixed RTC file which works around this problem by hard-coding the RTC base address, which is sensible as there's only one anyway!  It also uses the RITimer to wait the 2 seconds, and has commented out bits which clear the clock value (isn't that the point of a battery-backed RTC, to keep the value?) and disable calibration (why would you?).

Enjoy,
Richard

[lpcware]

Content originally posted in LPCWare by luca on Wed Apr 30 01:32:23 MST 2014
Hi,
I have a similar problem with LPC1857, writing the RTC  frequently (less than 1 second) wd reset the micro.
Thanks in advance!