Clock not running (was Re: RTEMS4.7 and its tool chain (Re: powerpc mvme5500 clock off by factor of 150))
strauman at slac.stanford.edu
Tue Mar 8 20:39:12 UTC 2005
Peter Dufault wrote:
> On Mar 8, 2005, at 12:36 PM, Kate Feng wrote:
>> How did the binary I sent you run on your mvme5500 ?
>> If the clock is not running with the binary I sent you,
>> then you should contact Motorla for repair.
> It worked fine with your binary.
> There is still an interrupt always firing on mine, though. Can you
> decipher what that interrupt is from the output I posted before?
I don't have the docs but since Kate is so busy I try to jump in
(not that I'm not busy ;-)):
It seems that the four bits main interrupt 1:0x0f000000
map to 4 four groups of GPP pins
1<<24 -> GPP 0.7
1<<25 -> GPP 8..15
you are getting a GPP0..7 interrupt
The MVME5500 programming manual (pp2-4) lists the wiring
of devices to GPP0..7 on that board (unused lines not mentioned)
GPP2: abort switch
GPP3: RTC II Thermostat Output
GPP6: GT-64260 WDMNI Interrupt
GPP7: LXT971 (10/100Mb PHY)
Hence, you'd have to print the GPP_Interrupt_Cause register contents
to find the culprit [why the code in irq.c is so complicated is a
mystery to me].
It seems the BSP disables all unused GPP interrupts at init but fails to
clear pending unused interrupts. Maybe a PHY IRQ is pending? Anyways,
dumping the GPP cause reg should help.
If my speculations turn out to be right, the code needs to be fixed:
init should mask unused interrupts and clear all pending ones - the ISR
probably should also clear spurious IRQs to be on the safe side.
Preferrably, the whole PIC code should be overhauled and greatly
simplified, of course.
BTW: Looking at the linux driver [2.6.11] is quite helpful
> Peter Dufault
> HD Associates, Inc.
More information about the users