Writing to RTC time registers causes a delay in code execution.

[lpcware]

Content originally posted in LPCWare by Alaric on Tue Jul 23 00:13:53 MST 2013
Hi,
I have come across a problem (to us) with the rtc on the MCB1800 (lpc1850) development board (and also
our board). The problem occurs when 2 rtc time writes are performed back-to-back.

What seems to happen is if a second write to rtc time registers is performed without a delay
(no less than ~900msec) then code execution, includes interrupts, is halted for 300-800msecs. I
know the rtc uses a 1Hz clock and rtc register access uses the CLK_M3_BUS so register updates
takes a few clock cycles but surely it shouldn't halt code execution on the processor?

Reads from the rtc are not effected even after a write to rtc.
I've included a modified blinky example application that shows the problem.

Has anyone else encountered this problem on the LPC18xx?

Original Attachment has been moved to: Blinky_0.zip

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Mon Aug 19 07:06:02 MST 2013
Now, that is odd!

And probably that applies to all LPC's that have a RTC.

What does that mean?
If buffering is applied and the register update synced with the RTC 1Hz clock, then you can never get the RTC closer than +- 1 sec to the real time, in an easy way, as you cannot reset the fractional part (of 1s) by a write. We have to reset the clock tick counter. And does that mean, the new value is used only a (full) second later? As a consequence, we have to set +1 sec and take care of all the possible carry s**t, too. OMG!

I planned to use RTC in conjunction with a (German) DCF77 decoder, but your observation puts me down. My uC for that is a LPC2146.
I will take a very close look at the behaviour.

[lpcware]

Content originally posted in LPCWare by Alaric on Mon Jul 29 00:16:42 MST 2013
Response from NXP:

This is indeed the expected behavior, and unfortunately cannot be avoided.

The first write to the RTC is buffered, but takes effect only after synchronization with the RTC's 1 Hz clock.
[color=#f00]A second write cycle, attempted before that synchronization took place, will stall the APB bus (and therefore the CPU).[/color]

There is no way but takeing care of this in an RTC driver, which should be coded such that no more than one write instruction to the RTC per second is done.

Regards,
Rolf