Don, Thanks for the video, I have a similar video and it is attached to the SPR. ECRT (Electrical)  now has one device that is exhibiting the fast time and one that had exhibited it, but was cold booted. They are currently trying to reproduce the issue on the unit which has been cold booted, and have just begun analysis on the device still showing the fast clock.

This issue has just been reported by Spanish Post in one MC75 and five MC70. Six in total, out of 2,000 MC70 + 8,000 MC75 = 10,000 units. MC75 is brand new... but those five MC70s have been working fine for four years so far!!!! Customer application has been recently upgraded, so we suspected of it... until I saw this thread. I have asked if these units have ever been sent to repair, just in case. MC75 has WAN but MC70s do not (wifi only), so I don't think this has to do with it. Both terminals application is written in C#.NET, and there is a timer thread that updates time/date and battery level on the "status" line of the display. Just in case this is relevant.

Our partner at Spanish Post has found that removing and inserting back the battery seems to fix the issue too. Also, when clock is accelerated, Program Memory (as seen in Start->Settings->System->Memory) increases and decreases all the time. It then seems as if there is a process doing something strange. Also, MSP agent log is huge and full with Date&Time errors. It seems to me it is a side-effect, not a cause.

Ken,  I have seen the problem reported on units manufactured in Sept 2008 and Feb.2009 FYI-- SPR# 18732 has now been opened against the fast clock issue on MC75. Please open a case through the Support Center and request that it be attached to this SPR.

First encountered this issue back in May of '09.  I provided engineering with a video of the issue as proof of occurrence.  At the time, it was deemed too infrequent an occurence to warrant investigating. Here is the video...a bit fuzzy; however, pay attention to the date field!! Don

First encountered this issue back in May of '09.  I provided engineering with a video of the issue as proof of occurrence.  At the time, it was deemed too infrequent an occurence to warrant investigating. Here is the video...a bit fuzzy; however, pay attention to the date field!! Don

Good for you--my customer did not want to send it in...Maybe we can get to the bottom of the issue..they have seen 1 in the failed state, but once it was cold booted they could not recreate

I brought a unit that was exhibiting the fast clock issue down to ECRT, here was the results: I immediately brought to Engineering and analysis was performed. We noticed that if unit is suspended, upon resume the clock has reverted back to the correct time and date, but immediately began jumping fast again. This led to the conclusion that the Real Time Clock (hardware on the main board) is functioning normally, but the Operating System (Bulverde) clock is not. Upon resume the OS clock will poll the RTC on the board, which explains the reversion to correct time. Then all running processes were stopped one at a time in an attempt to find a corrupt process causing the fast OS clock. This did not identify any bad process as we could not get the clock to stop running fast even after all relevant processes were stopped. Further investigation involving deep drilling into running threads was unable to reveal a root cause. Other testing required cold booting the unit?..which caused the clock to return to normal operation. I since received another unit from the TA from the same customer but on a different unit. Please not again, that this is occurring on a small percentage of units, no reproduction steps have been found, and a cold boot seems to permanently resolve the issue. Anyway, here was my response to the TA after conferring with Engineering again:
 I received the fast clock unit and asked engineering to analyze again. The clock on this unit is making larger jumps than the initial sample. We see jumps from 30 minutes per second to 90 minutes per second. Engineering believes this MAY be unique to Dunbar ’s environment. In any case, standard analysis and troubleshooting were not able to reveal root cause.

Engineering believes, “The investigation sounds like it may be monumental and unique to this customer so the account team may want to consider ways to mitigate or work around this rather than fixing it. Not pretty but sounds more efficient.

 

Again this is also due to the difficulty in reproducing the issue on any device once a cold boot has been performed. The few reports of this issue have never been combined with a reproduction scenario, nor have we seen the issue arise on the same unit twice.

Bearing the above in mind our recommendation is to perform a cold boot to resolve the issue.

 

If this option is unsatisfactory for the customer, please let me know and I will request a brainstorming session with Engineering and the account team.

Kevin, I received the fast clock unit and asked engineering to analyze again. The clock on this unit is making larger jumps than the initial sample. We see jumps from 30 minutes per second to 90 minutes per second. Engineering believes this MAY be unique to Dunbar’s environment. In any case, standard analysis and troubleshooting were not able to reveal root cause.

Engineering believes, “The investigation sounds like it may be monumental and unique to this customer so the account team may want to consider ways to mitigate or work around this rather than fixing it. Not pretty but sounds more efficient.

Again this is also due to the difficulty in reproducing the issue on any device once a cold boot has been performed. The few reports of this issue have never been combined with a reproduction scenario, nor have we seen the issue arise on the same unit twice.

Bearing the above in mind our recommendation is to perform a cold boot to resolve the issue.

If this option is unsatisfactory for the customer, please let me know and I will request a brainstorming session with Engineering and the account team.

Yesterday we (Motorola account and services team) met up with partner and customer to address the fast clock issue. Going through the thread, most of the installed base are hugh - in the thousands as compared to ours of 35 units. Out of the 35, two units were exhibiting the fast clock issue. We have shared with partner and customer the recommendation is to perform a cold boot if unit exhibit the fast clock issue. Customer says that is not good enough :(  Customer still demands Motorola to reveal the root cause :( They want to know the resolution or fix to prevent future occurance. I need help on that. Btw, the manufactured date on the 35 units is 2009/11/11

Hi Howard, the unit you brough to ECRT was it manufactured on 2009/11/11?

I have also seen this on a few units. There was an earlier thread on this topic. At this time support has not been able to identify a root cause, but they did advise that performing a cold boot on the device seemed to resolve the issue..

The WM6.1 build has a feature enabled which was previously disabled,(WM5 and WM60) The feature allows the device to sync time with the telco. Initally, my customer only saw the symptom in 1 US location, and it stopped when shipped to a different location, We eventually disabled the functionality with a reg key and the problem did re-appear so we did the cold boot

Thanks Marc.  My customer is not using the MC7596 for WWAN.  They have no SIM cards installed and the cellular radio is always powered off.  It's a DSD application.  They use WiFi in the morning to sync their route info.  The application then powers off the WiFi radio until they return in the afternoon.  The WiFi radio is then powered back on for end-of-day sync functions.  They have tried a warm boot on the unit in their office and it hasn't corrected the problem.  I'm not having them try a cold boot until I find out if ECRT wants to see the unit. Ken

We got a similar issue at one of our customers. The clock ran to fast. The application itself is going to synchronize the clock, therefore it does not became a big issue. There are 3.000 units installed in the field, so far we have seen this only on one device. We sent the device to the repair center to analyze the issue. Unfortunately it was n just repaired and not analyzed by a mistake. So far, we believe that this was hardware related.

Ken,        I ran into this issue back in April '09.  Given the inconsistent nature, there was very little that engineering could have done at that time. I believe that we need to take another look at the issue now that others have reprted it.  I have attached a video that I provided to engineering.  A bit blurry; however, you can see the date change by one day, approximately every three seconds. Don

I just had a customer call me with this issue on MC7596 units.  They have about 2500 units deployed.  They are getting sporadic reports from users of the time advancing 9 hours every second.  The customer just received a unit back from the field with the problem.  Hopefully we can get it to NY for ECRT to take a look at.  So far we've heard of the problem happening on about 10 units.  The customer's application prints an invoice with payment terms and conditions.  With the clock being all messed up, the affected units are printing a payment due date of May 2032 on the invoice.  The folks in Accounting are starting to get a little concerned.  One thing they noticed is that if you suspend and resume the device, the clock goes back to a more reasonable date before taking off again advancing 9 hours every second. Ken

I saw already this issue on the MC70, we try to find out a way to reproduce it without success. So far we see only few time (4-5 terminals effected in 3 months on 4500 terminals deployement). A cold boot solve the issue and those terminal so far don't show the issue again. We open a case but due the low numbers of unit effected and the cold boot solution we close the case. Cheers Alarico