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 23:44:23 UTC 2005
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
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));
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);
> I'll put this on hold unless I think of something.
> Peter Dufault
> HD Associates, Inc.
More information about the users