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
Wed Mar 9 02:46:13 UTC 2005
Peter Dufault wrote:
> On Mar 8, 2005, at 6:44 PM, Till Straumann wrote:
>> You can try a busy loop to check if the decrementer is running at all.
>> From your main/init task call
> Huh, it's running all right, but the values I'm seeing are odd. I put
> it in a loop and got the value 10 times, and I'm seeing:
> Decr rollover -- initial value was 0x3fe18d88, msr is 0000b032
> and so on, with the value displayed varying from 0x3fbbb6611 to
> 0x4dff9215. And they aren't descending, and they don't come out at
> once it takes a while.
> But I thought that assembler in c_clock.c, which I can't read, was
> reloading the counter with
It's a little more complicated than that. If we just reloaded the
decrementer we would effectively
slow down the system clock because of the interrupt latency. Therefore
the code tries to
update the decrementer on the fly
write_decr( read_decr() + Clock_Decrementer_value )
thus, the latency is accounted for.
> asm volatile ("mfdec %0; add %0, %0, %1; mtdec
Hmm - I smell something: could you try to insert a '&' after the '=' ?
asm volatile ("mfdec %0; add %0, %0, %1; mtdec
> so if the interrupt went off and it reloaded I expect the value
> printed in the test code you gave me to be under the 333330 that
> corresponds to 10ms, right?
> So interrupts are enabled (we can see that from the MSR), the board
> TBEN is asserted (I checked, and it powers up that way), The processor
> TBEN is enabled in HID0 (I've checked many times), the decrementer is
> running (we see that above), but the reload doesn't seem to be
> happening because the interrupt isn't triggering.
> Peter Dufault
> HD Associates, Inc.
More information about the users