Clock not running (was Re: RTEMS4.7 and its tool chain (Re: powerpc mvme5500 clock off by factor of 150))

[Till Straumann]

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
> "Clock_Decrementer_value": 

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 
> %0":"=r(decr):"r"(Clock_Decrementer_value)); 


Hmm - I smell something: could you try to insert a '&' after the '=' ?

asm volatile ("mfdec %0; add %0, %0, %1; mtdec 
%0":"=&r(decr):"r"(Clock_Decrementer_value));


>
>
> 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? 

yes

regards
-- T.

>
>
> 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
>
> Peter Dufault
> HD Associates, Inc.
>