G400 - TimeService & RealTimeClock issues

I’m experiencing different issues with the date and time on the G400 and was hoping to hear if anyone else is too. Firmware wise, I’m running for TinyBooter & TinyCLR.

The first problem I’m experiencing is the time on the G400 is increasing with around 1 sec pr. minute. This means that after around 5 minutes of execution, the G400 is around 5 seconds ahead (in my case compared with the time of an attached GPS). Has anyone else been seeing the same issue?

The G400 system time is assigned by using


and hereafter compared with the GPS-time using DateTime.UtcNow.

At this point I thought, ok no problem, I’ll just use the RealTimeClock instead through out my application. So i used RealTimeClock.SetTime and GetTime instead and things started looking really good, there was no noticeable time difference after running and comparing time stamps for about 5 minutes (difference between GPS-time and RealTimeClock-time).
But, then i discovered that the Date was way off, so I created the following code to test the RealTimeClock a bit:

int i = 0;
while (true)
    DateTime dtNew = new DateTime(2014, 1, 1 + (i++ % 30), 12, 3, i % 60);
    var dt = RealTimeClock.GetTime();

Which resulted in the following (weird) results:

01/01/2014 12:03:01
01/01/2014 12:03:02
01/01/2014 12:03:03
01/01/2014 12:03:04
01/01/1977 01:01:01
01/01/2014 12:03:06
01/01/2014 12:03:07
01/01/2014 12:03:08
01/01/2014 12:03:09
01/10/2014 12:03:10
01/10/2014 12:03:11
01/01/1977 01:01:01
01/13/2014 12:03:13
01/13/2014 12:03:14

I was expecting to see:

01/01/2014 12:03:01
01/02/2014 12:03:02
01/03/2014 12:03:03
01/04/2014 12:03:04
01/05/2014 12:03:05
01/06/2014 12:03:06

My questions number 2 is therefore, has anyone else had problems with the date when using the RealTimeClock on G400?

I have tried two different G400 boards with our own custom hardware and with the chipworkx dev-board - all setups produce the same results.

@ MD - For the date issue, we have found a bug and have fixed it and the new firmware will be released soon in the future.

As for the time being off, there is no known issue regarding this and we will investigate to verify the problem.

@ Aron - Ok, thanks for info regarding the date issue. We have worked around the issue for now by using the date part from DateTime.UtcNow and the time part from the RealTimeClock.GetTime (which is quite nasty, but we are to deliver a handful production units within 2 weeks time, so a nasty hack looks necessary).