powerpc mvme5500 clock off by factor of 150

Joel Sherrill <joel@OARcorp.com> joel.sherrill at OARcorp.com
Tue Mar 8 14:18:46 UTC 2005


Peter Dufault wrote:
> 
> 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 seconds.

Long shots here...

could you check that interrupts are actually on when
the first task executes? and in all tasks.

Another possibility is that there is an unmatched ISR disable/enable
pair somewhere in the BSP.

If you can determine that interrupts are off, then we have a big hint.

FWIW the BSP is using _CPU_ISR_Disable/_CPU_ISR_Enable.  THose are
private routines.  The BSP should be using rtems_interrupt_disable
and rtems_interrupt_enable.

> 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




More information about the users mailing list