powerpc mvme5500 clock off by factor of 150

Peter Dufault dufault at hda.com
Tue Mar 8 12:56:03 UTC 2005

On Mar 8, 2005, at 7:07 AM, Peter Dufault wrote:

> if (excNum == ASM_DEC_VECTOR) {
>   _CPU_MSR_GET(msr);
>   new_msr = msr | MSR_EE;
>   _CPU_MSR_SET(new_msr);
>   rtems_hdl_tbl[BSP_DECREMENTER].hdl();
>   _CPU_MSR_SET(msr);
>   return;
>  }
> It looks to me as if we save the exception enable state, enable 
> exceptions, call the handler, and then restore the exception state.
> What's the logic here?  If exceptions are disabled, we enable them, 
> the exception fires, we re-enter, call the handler once with 
> exceptions enabled, return, call the handler a second time with 
> exceptions still enabled, then disable exceptions?  If exceptions are 
> already enabled we call it once, and saving/restoring exception state 
> is probably a NOP.

OK, I see what this is doing.  Exceptions are usually disabled when we 
enter this, we enable them after taking an exception so that a 
higher-priority exception can pre-empt us.

I also put in a call to irq->on() in mvme5500/irq/irq.c in the case 
that it is a processor exception, and it doesn't die on my and 
clockOn() is called properly in that case.  Still doesn't work though.

I've verified that:
. TBEN is set on the board to enable the decrementer to count (there is 
a disable input on the processor);
. TBEN is set in HID0 to allow the decrementer to count and to 
interrupt if MSR_EE is set;
. MSR_EE is set, and exceptions are initially enabled in the MSR when 
the task starts;
. The decrementer is loaded with what corresponds to 10ms;
. Whenever I enter the decrementer handler exceptions are disabled in 
the MSR, and given what I say above about the intent of the code loop, 
that is correct.

So I don't understand why I only get an interrupt roughly every 35 


Peter Dufault
HD Associates, Inc.

More information about the users mailing list