| Author |
Topic |
|
|
ellewellyn
9 Posts |
 Posted - 14 Aug 2003 : 11:31:31
|
I'm using the CE function GetTickCount() with an ADS XScale
board, and am seeing some very weird behavior. It works
fine for about 4 hours, and then successive calls to
GetTickCount() show a time jump of 19.4 minutes. GetSystemTime()
shows only a few second gap for the same time period.
Has anyone seen this in CE 4.10? It happens randomly with
regards to what the tick count is, but the time jump reported
by GetTickCount() is always around 19.4 minutes. This has
happened about 6 times already in my testing.
Any help or clues would be appreciated. In my application,
I'm also using a serial port, CAN bus, ethernet, and
watchdog timer.
--Ed L.
ellewellyn2003@yahoo.com
|
|
|
chick
8 Posts |
Posted - 02 Sep 2003 : 09:30:45
|
We've noticed that GetSystemTime() or CTime::GetCurrentTime() will take about 5 seconds to return on approximately every 120th call. This is on an XScale board running CE 4.10. Our target system doesn't have a real-time clock connected yet. (Not sure if that would have any impact, but thought I would mention it).
|
 |
|
|
akidder
1519 Posts |
Posted - 02 Sep 2003 : 11:04:51
|
| Thanks for pointing this out. We have noticed this ourselves and plan to release an update image the end of this week with a fix for this issue. Thanks! |
|
|
|
akidder
1519 Posts |
Posted - 10 Oct 2003 : 16:41:51
|
Issue Corrected in BitsyX build 4.10.28
BitsyX build 4.10.28 corrects this issue (ok, so it's been a little more than a week  ).
Take a look at the BitsyX CE build selector to download and test. |
|
|
|
chick
8 Posts |
Posted - 02 Aug 2005 : 14:05:30
|
FYI, we are still seeing discontinuities in the value that is returned by GetTickCount(). It will jump by many minutes on successive calls that are about 20 msec apart. These discontinuities are sporadic in frequency. They may occur once/day, once every couple days, or twice within an hour.
We have 2 different products where this is occuring. One is running OS 4.10.36. The other is running OS 4.20.08.
Currently, we check for and ignore these discontinuities. But it would be good to know what is going on.
Thanks,
Jim Chickering
Zoe Medical |
|
|
|
akidder
1519 Posts |
Posted - 02 Aug 2005 : 14:47:30
|
Hi Jim. Thanks for the follow-up. Do you recall if GetTickCount() jumps forward or back and by how much? Are they similar to the times ellewellyn reported?
The system timer on our PXA255 products runs at 3.6864 MHz; 19.4 minutes is the time it takes the 32-bit system timer to roll over at that frequency.
You're running the BitsyX, but I think the issue applied to all our CE products at one time or another. We'll run some test in our lab to see which builds are affected. Any details you can share will help. |
|
|
|
dwallace
1 Posts |
Posted - 13 Oct 2005 : 14:39:31
|
Hello,
Our current platform is not an ADS platform, but we have an ADS development system and are thinking of using ADS for an upcoming design. We ran across this same issue on our current platform. The symptom is that a call to GetTickCount() returns a value 19.4 minutes ahead of where it should be. It took us about 3 months with Microsoft’s help to “solve” this issue. The frequency of this event appears random, but the condition is accelerated with heavy activity on serial port (I’m guessing any heavy I/O would do it). We set up a stress test with constant, high speed serial activity and we could get this condition to occur pretty frequently.
The problem occurs because CurMSec, the value returned by GetTickCount(), gets corrupted in OEMIdle(). Initially, we commented out OEMIdle() completely and the problem went away. After some digging, we verified that the call to PerfCountSinceTick() in OEMIdle() would return a negative number, which would cause CurMSec to get corrupted. At the very end of OEMIdle(), the M0 (timer match) register is restored and then any pending interrupts are cleared. When we added some dummy code (artificial delay) between the osmr0 register write and the clear of the M0 interrupts, the problem went away. The Microsoft representative we worked with said he thinks the cause for this is a timer match interrupt for M0 occurring slightly after osmr0 is restored, but the processor not setting the M0 interrupt bit until just after software clears it. He thinks any propagation delay that might exist between a timer match and the processor setting the interrupt pending bit is hidden by adding an artificial delay. The heavy serial activity makes this issue worse, since OEMIdle() is frequently exited prematurely whenever serial interrupts come in.
Don Wallace
Life Fitness
|
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
GetTickCount is intermittently slow, BitsyX
Forum Locked
Send Topic to a Friend
Printer Friendly