MPC860 internal RTC issues

YuriT · ‎07-16-2010

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.

TomE · ‎09-20-2010

Did you fix this or is it still a problem?

So to summarise, you're seeing the RTC run fast when there's other CPU activity and it is running from the 32768Hz crystal.

My first guess would be that you're getting noise on the crystal inputs, either directly, from nearby tracks or on the oscillator power supply.

The CPU is running fast and so are all the noise sources. The crystal is running very slowly compared to this. 32768Hz has a 30us period.

What I'm thinking is that instead of the waveform from the crystal into the MCU being:

--------------------------___________________-------------------------_________________

When there's noise present you're getting:

--------------------------_-_______________-_--_----------------------_________________

And the occasional noise pulses are counting as extra clocks.

Add some more filtering to he power supplies. Try putting some more capacitance from the crystal oscillator pins to ground.

Put a CRO probe on them - that alone might fix the problem.

Check that the crystal is being driven hard enough. Or too hard perhaps.

Check the PCB layout to make sure there are no signal tracks under the crystal or near the tracks from it to the CPU.

Good luck,

YuriT · ‎09-20-2010

Hello,

Did you fix this or is it still a problem?

No, I didn't fix this. Instead I implemented a workaround for this problem: just a software RTC basing on one of four CPM Timers (which is clocking from ExtClk through PLL); with this software RTC I don't observe any of the problems described above.

So to summarise, you're seeing the RTC run fast when there's other CPU activity and it is running from the 32768Hz crystal.

My first guess would be that you're getting noise on the crystal inputs, either directly, from nearby tracks or on the oscillator power supply.

The CPU is running fast and so are all the noise sources. The crystal is running very slowly compared to this. 32768Hz has a 30us period.

What I'm thinking is that instead of the waveform from the crystal into the MCU being:

--------------------------___________________-------------------------_________________

When there's noise present you're getting:

--------------------------_-_______________-_--_----------------------_________________

And the occasional noise pulses are counting as extra clocks.

Add some more filtering to he power supplies. Try putting some more capacitance from the crystal oscillator pins to ground.

Put a CRO probe on them - that alone might fix the problem.

Check that the crystal is being driven hard enough. Or too hard perhaps.

Check the PCB layout to make sure there are no signal tracks under the crystal or near the tracks from it to the CPU.

Thank you for your comments; all these make sense. I'll ask our hardware engineers to check if the appropriate fixes help. Certainly, we'd prefer to use the 'original' MPC860's RTC instead of wasting the CPM Timer resource.

Regards, Yuri