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 4:34 PM, Peter Dufault wrote:
>
>> OK, I zeroed the three registers after the loop.  The front panel LED 
>> is still lit at about 1/2 intensity, and the only place it is 
>> accessed is when I xor it in C_dispatch_irq_handler right near the 
>> bottom when it is calling rtems_hdl_tbl[irq].hdl() for the case 
>> "irq==56", which is the serial port interrupt.  So I think it is 
>> always going through that interrupt.
>>
>>
>
> I think I'm wrong about this.  Because the last interrupt that goes 
> out will be a FIFO empty interrupt when any serial I/O happens I think 
> I'm seeing that and imagining things.  I think Kate might be right 
> that the best way to solve this is get a 4.6 version working with the 
> older tools and then move forward, which I don't have time for.
>
> I'm not sure what's up, as I said, at least at entry to the "ticker" 
> tasks I'm seeing that the processor interrupts are enabled in the MSR, 
> the board TBEN is enabled via its I/O register, the processor TBEN is 
> enabled in HID0, and the decrement counter is set to be loaded with 
> 333330, and now that I've enabled irq->on() for processor exceptions 
> it is, so I don't know why I don't get the interrupts every 10ms 
> unless a higher priority exception is pending.  Can any PPC experts 
> suggest something else?  What's a good way to determine if this is 
> happening? 

You can try a busy loop to check if the decrementer is running at all.
 From your main/init task call

unsigned decr, tmp,msr;
asm volatile("mfdec %0":"=r"(tmp));
do {
  asm volatile("mfdec %0":"=r"(decr));
} while (decr <= tmp);
asm volatile("mfmsr %0":"=r"(msr));
printk("Decr rollover -- initial value was 0x%08x, msr is %08x\n",tmp,msr);

HTH
-T.

>
>
> I'll put this on hold unless I think of something.
>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>