Panda II RTC acts like it's not ticking

Something simple this has to be. I use the very brief code below to set the RTC and print out the time every two seconds - that works. I then comment out the line that sets the RTC and reload the Panda II, but the local clock set still gets loaded with the time that was in the commented line - it’s as if I can set the RTC clock time, but the RTC doesn’t tick. Any ideas? Code and output below:

using System;
using System.Threading;

using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

using GHIElectronics.NETMF.FEZ;
using GHIElectronics.NETMF.Hardware;

namespace RTC_Test
{
    public class Program
    {
        public static void Main()
        {
            // the next line gets commented out after the RTC is set - then relaod the Panda II
            // RealTimeClock.SetTime(new DateTime(2011, 04, 08, 12, 00, 0, 0));
            Utility.SetLocalTime(RealTimeClock.GetTime());
            while (true)
            {
                Debug.Print(DateTime.Now.ToString());
                Thread.Sleep(2000);
            }
        }

    }
}

Output on first debug run:

The thread ‘’ (0x2) has exited with code 0 (0x0).
04/08/2011 12:00:00
04/08/2011 12:00:02
04/08/2011 12:00:04
04/08/2011 12:00:06
04/08/2011 12:00:08

Output from next debug run with “// RealTimeClock.SetTime(new DateTime(2011, 04, 08, 12, 00, 0, 0));” commented out:

The thread ‘’ (0x2) has exited with code 0 (0x0).
04/08/2011 12:00:00
04/08/2011 12:00:02
04/08/2011 12:00:04
04/08/2011 12:00:06
04/08/2011 12:00:08

Print out RealTimeClock.GetTime() instead of DateTime.Now

My Panda II gives an expected result

The thread ‘’ (0x2) has exited with code 0 (0x0).
04/08/2011 12:00:00
04/08/2011 12:00:02
04/08/2011 12:00:04
04/08/2011 12:00:06
04/08/2011 12:00:08
04/08/2011 12:00:10
04/08/2011 12:00:12
04/08/2011 12:00:14

The thread ‘’ (0x2) has exited with code 0 (0x0).
04/08/2011 12:00:58
04/08/2011 12:01:00
04/08/2011 12:01:02
04/08/2011 12:01:04
04/08/2011 12:01:06

Joe, per your request here’s what I added and the resulting output - still no ticking:

                Debug.Print(" here's local time: " + DateTime.Now.ToString());
                Debug.Print(" here's RTC time: " + RealTimeClock.GetTime().ToString());

Output:

The thread ‘’ (0x2) has exited with code 0 (0x0).
here’s local time: 04/08/2011 12:00:00
here’s RTC time: 04/08/2011 12:00:00

here’s local time: 04/08/2011 12:00:02
here’s RTC time: 04/08/2011 12:00:00

here’s local time: 04/08/2011 12:00:04
here’s RTC time: 04/08/2011 12:00:00

here’s local time: 04/08/2011 12:00:06
here’s RTC time: 04/08/2011 12:00:00

here’s local time: 04/08/2011 12:00:08
here’s RTC time: 04/08/2011 12:00:00

here’s local time: 04/08/2011 12:00:10
here’s RTC time: 04/08/2011 12:00:00

here’s local time: 04/08/2011 12:00:12
here’s RTC time: 04/08/2011 12:00:00

RTC is not incrementing! It could be a problem on your board. Please contact GHI directly

I’ve been working this issue for a couple of weeks now and GHI has helped tremendously in trying to establish if there is or is not a problem when the RTC gets into unknown state and stops ticking.

The potential problem arises if a power interruption puts the RTC in an indeterminate state until it is reset either during the boot sequence or by program. This is important when your application needs to get right back up and running when a user replaces a backup battery or some other problem puts the RTC in an indeterminate state.

The problem I’ve experienced with two Panda II’s I’m testing is that when they default to a startup date of 1/1/1977, the RTC may not tick even after resetting it to a current date and time. I was advised to test this by writing a short program that would use a button (LDR in this case) to reset the RTC when it was pushed. To monitor this the program starts up by printing out RTC time and local tine every two seconds, and of course they should be in synch. When the LDR button is pushed both clocks reset to
04/19/2011 12:00:00 and if all is well they keep ticking along in lockstep ad infinitum.

The problem I am observing in the two Panda’s I’m testing is that sometimes after installing and removing a backup battery, ultracapacitor, or even just powering down, the Panda comes back up with the default time in an indeterminate state and even setting the RTC with this program won’t get it ticking again. Right now I have one Panda running this program and a LDR button push gets the right times and ticks, and the other Panda with the identical program that will not get a ticking RTC no matter what I push.

Now it’s possible that I have the only two Pandas that exhibit this behavior or it may even be that time relativity is even more exaggerated than Einstein thought here in the Idaho outback, or it may also be that I’m making some incredibly stupid mistake, but I frequently see the RTC ticking stop when I run my tests.

If anyone is interested or bored and would like to verify or disprove this behavior please load the following program and check their results against what I’ve described. The problem won’t show up unless the RTC gets into an indeterminate state so it may require installing some form of backup Vbatt and the removing it to get the Panda’s RTC in an indeterminate state, or it may enter this state simply when system power is removed with no Vbatt. I’ve not found a reliable way to get into this mode.

If nothing else the code snippet below may be useful for illustrating how to use the LDR button for a user initiated interrupt. It was adapted from section 8.2.1 in the Beginner’s Guide to .NETMF, and shows some changes that had to made to the code in the Guide.

Thanks to anyone who wants to try explain what might cause this behavior or who finds an error in how I’ve described the problem . Here’s the code followed by a screen shot of the Visual Studio output for the Panda that currently won’t tick:

/* RTC_Test_button - C# .NETMF SOLUTION
 * Written to verify RTC operation
 * Depending on its initial state a RTC may or may not increment properly.
 * Setting the RTC should establish a known state.  This short program tests  
 * the RTC and local clock for any timekeeping anamolies in a Panda II.
*/

using System;
using System.Threading;

using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

using GHIElectronics.NETMF.FEZ;
using GHIElectronics.NETMF.Hardware;


namespace RTC_Test_button
{
    public class Program
    {
        public static void Main()
        {
            // the next line can be uncommented if you want start with a known RTC setting
            // RealTimeClock.SetTime(new DateTime(2011, 04, 19, 09, 0, 0, 0));
            Utility.SetLocalTime(RealTimeClock.GetTime());
            // set up the LDR button to generate an interrupt on high edge
            InterruptPort IntButton = new InterruptPort((Cpu.Pin)FEZ_Pin.Interrupt.LDR, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeHigh);
            // add an interrupt handler to the pin
            IntButton.OnInterrupt += new NativeEventHandler(IntButton_OnInterrupt);
            // start a loop to print out times every two seconds
            while (true)
            {
                // print out local time and RTC time every two seconds
                Debug.Print(" here's local time: " + DateTime.Now.ToString());
                Debug.Print(" here's RTC time: " + RealTimeClock.GetTime().ToString());
                Debug.Print("");
                Thread.Sleep(2000);
            }
        }
        static void IntButton_OnInterrupt(uint port, uint state, DateTime time)
        {
            // LDR button has been pushed - reset clocks to known value
            RealTimeClock.SetTime(new DateTime(2011, 04, 19, 12, 0, 0, 0));
            Utility.SetLocalTime(RealTimeClock.GetTime());
            Debug.Print(" RTC and local time have been reset to 04/19/2011 12:00:00 ");
            Debug.Print(" here's local time: " + DateTime.Now.ToString());
            Debug.Print(" here's RTC time: " + RealTimeClock.GetTime().ToString());
            Debug.Print("");
        }
    }
}

A picture is worth a million words. I see it much better now. So does this board work sometimes or it never worked?

Also, what is connected on VBAT?

Both boards work, but both have also shown the same problem periodically. In fact the board that wasn’t working when I posted an hour ago is now ticking along nicely for about 25 minutes. I was able to get the RTC ticking after reinstalling the backup battery while the Panda was powered via USB (as NXP says it should be installed). Don’t know why that worked this time but I expect it has something to do with with transient voltage changes on VBAT.

VBAT is connected to a CR2032 coin cell in series with a 1N4004 diode.

I’ll continue running these to see if I can pin down more specifics, but I welcome any suggestions.

Here is the errata and I am not seeing anything unusual http://ics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2387.pdf

I have never seen what you are seeing before and I checked with the guys at GHI and they never seen this before.

Maybe someone else from the community try it out please?

I dont think the 4004 in series is a good idea as the current would be too low in a pulsed way. Maybe the 4004 is too slow and RTC stucks without starting the oscillator.

I’ve never seen a diode in series with a caoin as it reduces its life (By the dropped voltage). Why dont you try the ussual way of limiting current using a resistor ?

The sole purpose of the diode is to prevent reverse current flow into the battery. The RTC is already ticking when you plug in the battery or at least it should be if you follow the NXP errata instructions.

The RTC must be connected to the 3.3V supply before VBAT is connected or there will be excessive current draw from the backup battery. The errata sheet explains why.

I understand now that I read the errata…

I think you are powering VBAT from 3.3V an Cell Coin through 2 diodes right ?

If so, when you remove 3.3V there is a brief time where the diode is not conducting and maybe the pin is left floating. Maybe a Cap will help.

I think you are powering VBAT from 3.3V an Cell Coin through 2 diodes right ?[line]…

One diode and a 3 volt coin cell (CR2032).

Actually, Pablo, since the board is being powered by the 3.3V bus via USB the voltage at the VBAT pin is not floating and there shouldn’t be any power interruption to the RTC. GHI connected the 3.3V bus to VBAT through a Shottky diode so that it isn’t left floating.

Can we try this…do not connect anything to your FEZ beside USB cable and/or power. Can you get it to fail? You can use MFDeploy to see the debug messages.

Gus, There is a chance I may have found the cause of the problem and if I am correct it is totally external to the Panda. Let me test out this theory for another 24 hours and if both clocks hang in there I will describe what I’ve found.

Right now I am running both Pandas with nothing connected except USB an am using MFDeploy to monitor the output. I’ll get back to you as soon as I’m certain of the results - don’t want to waste anyone’s time unless I continue to find an unresolved problem (actually I don’t ever want to waste anyone’s time).

I’ll be back with the results tomorrow - thanks.

I believe I’ve pinned down the reason the RTC would stop ticking and it does not appear to be a problem with the Panda II. The two Panda IIs were being tested on anti-static pads on the workbench. Both pads were supposed to be insulating, but one of the pads was slightly conductive for shipping ICs and was interfering with the Panda clock circuits. Everything else worked fine, boot up, program, etc. but the small conductivity of the one pad evidently was enough to lock up the clock.

Pad is gone and both Pandas are keeping time with no glitches for over 24 hours. We’ll keep testing but pretty confident the problem has been found.

Good thing two Pandas were being tested because it finally helped to see that the problem only showed up with whatever Panda was on the pad. Gus’s trouble shooting suggestions and the fact that no one else had seen a similar problem helped isolate the problem - thanks.

So while this may have been wild goose chase there are probably a few worthwhile observations:

[ol]Be careful what you place your FEZ on

There are some needed work arounds in the NXP errata for the LPC23xx chips if you plan on using the RTC

If your backup battery current is > 20 microamps check the errata

The RTC can stop ticking - since the “IsTimeValid” property is no longer supported, check the RTC on startup[/ol]

Hopefully this goose chase will save someone out there some time down the road. Now I’m going to go and order more Pandas.

Make sense as those 32Khz crystal are extremely sensitive. You can touch it and it will stop ticking.

I am glad you found the problem :slight_smile: