A small contribution and a big question (timer/keyboard)

[DrDarius]

Cyrille,
Thank you very much for your response.
I did some brief research and performed some experiments at the same time (...while I really should have been be doing other stuff...), and here are my conclusions/experiment results.
Disclaimer: I have not opened my G2 yet. All my conclusions are based on the analysis of the picture of G2 board I found online.

1. I modified the stopwatch code and removed RTC synchronization. Here is a relevant procedure after changes:

Code:


StopwatchCore(nPreviousLaps,nPreviousTicks,nBackground)
BEGIN
  // controls stopwatch
  // nLaps: number of lap times displayed on the screen already
  // nStartTicks: time to resume counting from
  // nBackground: screen background

  LOCAL sString;
  LOCAL i,nStartTicks;
  LOCAL nLaps:=0;
  LOCAL nKey;

  // if more than 10 days, refuse to run
  IF nPreviousTicks>=864000000 THEN
    RETURN {nPreviousLaps,nPreviousTicks};
  END;

  // print zero value
  sString:=ConvertMsToTime(nPreviousTicks);
  PrintTime(sString,nBackground);

  nStartTicks:=TICKS;

  REPEAT
    nKey:=GETKEY();
    CASE
      IF nKey==30 AND nLaps+nPreviousLaps<13 THEN  // Enter and within limit
        sString:=ConvertMsToTime(TICKS-nStartTicks+nPreviousTicks);
        TEXTOUT_P(nLaps+nPreviousLaps+1+". ",4,4+(nLaps+nPreviousLaps)*14,3,RGB(0,0,0));
        TEXTOUT_P(sString,26,4+(nLaps+nPreviousLaps)*14,3,RGB(255,0,0));
        nLaps:=nLaps+1;
      END;
      IF nKey==4 OR TICKS-nStartTicks+nPreviousTicks>=864000000 THEN // Esc
        RETURN {nLaps+nPreviousLaps,TICKS-nStartTicks+nPreviousTicks};
      END;
    END;
    IF (TICKS-nStartTicks)MOD10==0 THEN
      sString:=ConvertMsToTime(TICKS-nStartTicks+nPreviousTicks);
      PrintTime(sString,nBackground);
    END;
  UNTIL 0;
END;

I ran the code taking measurement at 1.5h and 3h. The errors were:
@ 1.5h: 2.346%
@ 3.0h: 2.346%.
(Amble stopwatch was used for time measurement. During previous tests it was compared with Casio chronometer watch, and they both ran with exactly the same speed, so we can safely assume it's accurate.)
Thus, the error seems to be stable.
Please pay attention to the sign of the error: the calculator was running faster that it should.

2. From the picture mentioned above I deduced that G2 uses two crystals: one 32K for SRTC, another for the CCM. This is consistent with the fact that MCIMX6Y2DVM05AB does not have built-in oscillator driving CCM. The crystal frequency should be 24MHz (indeed, a digit "4" can be read on the crystal's enclosure in the picture; other enclosure areas are somewhat blurry).
From what you said in your e-mail ("based on the CPU bus clock"), PLL2 is used for task switching purpose in the RTOS. It's a fixed PLL, but equipped with PFDs, so, at lest theoretically, the system frequency can be modified. (I don't think it happens, though, at least not intentionally.)

3. What can be the possible sources of the frequency error? As I see it:
a) Incorrect crystal load capacitance. Rather unlikely, and even if, then it would be a few hundred ppm, not 2.4%!
b) PLL error. The MCIMX6Y2DVM05AB data sheet does not specify phase error (or jitter) for PLL2, but again, 2.4% seems excessive.
c) Bug in the code. Either a wrong value accidentally written to a PFD, or an error in procedure retrieving time from the task switching clock. (The latter one is rather unlikely, because the calculator is running faster than it should.)
d) Bug in my code?...
...Or something yet totally different. Maybe my G2 is faulty in this respect?

Whatever it is, I was not dreaming that it was happening. And synchronization with RTC removed it. For me the case is closed.

Again, thanks for interesting info you sent in your e-mail.

Darius