AnsweredAssumed Answered

MPC860 internal RTC issues

Question asked by Yuri Tikhonov on Jul 16, 2010
Latest reply on Sep 20, 2010 by Yuri Tikhonov


 Hello,

 I observe a strange behaviour of the internal RTC on my MPC860-based
board when using 32.768KHz oscillator as the RTC clock source (OSCM).
The problem can be boiled down to the following two issues:
(I) the internal MPC860's RTC counts seconds not correctly;
(II) the observed RTC mistake depends on such an unrelated stuff like
other interrupts presence in the processor module (e.g. Decrementer
and Program Exception).

 If, instead of OSCM, I use 66MHz from the EXTCLK as the RTC clock
source, then the most upsetting issue (II) disappears.

 To investigate this problem I performed the following experiments
with my MPC860-based board (the code sources are attached, the
definitions (#define) mentioned below are from sys/main.c of these
sources):

(a) init Ethernet on SCC0 of MPC860;
(b) init RTC of MPC860 and configure it to use OSCM as a clock source
(#undef RTC_USE_EXT), and to generate 1-sec RTC interrupts;
(c) optionally I init and enable Decrementer counter (#define
DEC_ENABLE) and/or generation of Program Exception interrups with
the 'trap' assembler instruction (#define TRAP_ENABLE) in an infinite
loop;
(d) in the 1-sec RTC interrupt handler I send some frame to ethernet;
(e) capture ethernet frames sent from my 1-sec RTC handler with
Ethereal working on PC connected to my MPC860-based module;
(f) check the time differences between frames captured with the
Ethereal on PC expecting these to be equal to 1.000000 second.

 And here are the results (the time values, of course, are not
reproduced exactly from run to run, but the trend - remains the same):

(1*) scenario:
 #undef RTC_USE_EXT     /* use OSCM */
 #undef DEC_ENABLE      /* no Decrementer interrupts */
 #undef TRAP_ENABLE     /* no Trap interrupts */

 results to the following deltas between frames captured with Ethereal:

 Frame No.:     01              02              03             04              05          ...
 Time:               0.000000 1.000051 1.000049 1.000049 1.000039    ...
 ...
 Frame No.:     09              10             11            ...
 Time:               1.000051 1.000038 1.000051      ...

(2*) scenario:
 #undef RTC_USE_EXT     /* use OSCM */
 #define DEC_ENABLE     /* enable Decrementer running & interrupts */
 #undef TRAP_ENABLE     /* no Trap interrupts */

 results to the following deltas between frames captured with Ethereal:

 Frame No.:     01              02              03             04              05          ...
 Time:               0.000000 0.995802 0.996082 0.995969 0.996158    ...
 ...
 Frame No.:     09             10              11            ...
 Time:               0.995916 0.995827 0.996274      ...

(3*) scenario:
 #undef RTC_USE_EXT     /* use OSCM */
 #undef DEC_ENABLE      /* no Decrementer interrupts */
 #define TRAP_ENABLE    /* generate Trap interrupts */

 results to the following deltas between frames captured with Ethereal:

 Frame No.:     01              02              03             04              05          ...
 Time:               0.000000 0.996018 0.995724 0.995430 0.995801    ...
 ...
 Frame No.:     09             10              11            ...
 Time:               0.995558 0.995685 0.995685      ...

(4*) scenario:
 #undef RTC_USE_EXT     /* use OSCM */
 #define DEC_ENABLE     /* enable Decrementer running & interrupts */
 #define TRAP_ENABLE    /* generate Trap interrupts */

 results to the following deltas between frames captured with Ethereal:

 Frame No.:     01             02              03              04              05          ...
 Time:               0.000000 0.994956 0.995097 0.995174 0.994867    ...
 ...
 Frame No.:     09             10              11            ...
 Time:               0.994738 0.995431 0.995466      ...


 So, as it follows from (1*)-(4*): the more interrupts I have, the
more RTC mistake is observed. And it seems strange to me: OK, at
moment T(i) of triggering 1-sec RTC interrupt there could be a delay
caused by executing of DEC&TRAP interrupt handlers right now, and at
the moment T(i+1) there could be no such delay - so the time delta
between the frames sent at T(i) and T(i+1) may be _less_ than 1
second; but in this case I'd expect the time delta between frames sent
at T(i-1) and T(i) to be _more_ than 1 second (because T(i) frame had
been delayed) - but there are no such deltas in the Ethereal capture:
instead, deltas between frames become strongly less than expected, as
if the MPC860's RTC, indeed, counts more fast in case of DEC&TRAP
interrupts presence & handling.

 If I spend less time in the DEC & TRAP interrupt handlers (i.e. just
save & restore regs, without brancning to the C functions), then the
frame time delta mistakes observed in (2*)-(4*) becomes less.

 What is not clear to me too - why such effect disappears in cases of
using EXTCLK as the source clock for RTC:

(5*) scenario:
 #define RTC_USE_EXT    /* use EXTCLK */
 #undef DEC_ENABLE      /* no Decrementer interrupts */
 #undef TRAP_ENABLE     /* no Trap interrupts */

 results to the following deltas between frames captured with Ethereal:

 Frame No.:     01             02              03             04              05          ...
 Time:              0.000000 1.032123 1.032124 1.032124 1.032124    ...
 ...
 Frame No.:     09             10              11            ...
 Time:               1.032124 1.032125 1.032124      ...

(6*) scenario:
 #define RTC_USE_EXT    /* use EXTCLK */
 #define DEC_ENABLE     /* enable Decrementer running & interrupts */
 #define TRAP_ENABLE    /* generate Trap interrupts */

 results to the following deltas between frames captured with Ethereal:

 Frame No.:     01              02              03             04              05          ...
 Time:               0.000000 1.032124 1.032123 1.032138 1.032111    ...
 ...
 Frame No.:     09             10              11            ...
 Time:               1.032112 1.032136 1.032123      ...


 That is, as opposite to (1*)-vs-(4*), there are no RTC clocking
dependency on DEC & TRAP if I use EXTCLK as a source, as it follows
from (5*)-vs-(6*).

 Note, that in case of utilizing EXTCLK (5* and 6*), I use different
settings of 32K/38K and DIV_4/_512 for RTC. Using these settings with
OSCM (i.e. 38K and DIV_512) don't help: the (1*)-vs-(4*) trend still
remains.

 Are there any ideas what could be the reasons of (I) & (II) issues?

 Thanks in advance for any tips,

 Yuri

P.S. There is a "SIU10. RTC/PIT does not count properly when the
pre-divider is four" chapter in MPC860CE Rev. 1.8 Errata. This isn't
the case here, see my Note after (6*) above.

P.P.S. Here, I guess, is a some similar topic started by Steven Scholz
at 2003, don't know how did it end:

http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg25130.html

P.P.P.S Attached is the vmpc860.zip tarball with the sources for my MPC860-based
board, which I used for tests decsribed above (I used the BDM
connection to run the binary with the VisionProbeII debugger):
- sys/main.c with main() & interrupt handlers;
- sys/timer.c with RTC & Decrementer functions;
- sys/vectors.s with the MPC860 interrupt vectors used;
- comm/ethernet.c with MPC860 SCC0 ethernet implementation;
- init/ with the C-environment init code;
- sdram.reg with the register values written to target with the
debugger at the playback step.


Outcomes