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

[Joel Sherrill <joel@OARcorp.com>]

Till Straumann wrote:
> 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));

cpukit/score/cpu/powerpc/rtems/score/cpu.h has these:

#define PPC_Set_decrementer( _clicks ) \
   do { \
     asm volatile( "mtdec %0" : : "r" ((_clicks)) ); \
   } while (0)

#define PPC_Get_decrementer( _clicks ) \
     asm volatile( "mfdec  %0" : "=r" (_clicks) )


Note that there is no & in the get.  Even the get and set timebase
register don't have them.  Is this right?

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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985