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 3:59 PM, Till Straumann wrote:
>
>> OK, I wasn't careful enough, thinking that the GT_GPP_IntHandlers 
>> clear any pending interrupt
>> used by the BSP [not -1 in config table]. However, the IRQ status is 
>> (who knows why) anded
>> with the current mask at entry.
>>
>> --> if a serial IRQ is pending during init, the init code will mask 
>> GPP interrupts (but not clear any
>>     pending ones).
>> --> pending irq ends up dispatching GT_GPP_IntHandler
>>         - if it's a 'configured' IRQ it is not cleared as long as no 
>> handler is installed (i.e., masked
>>           in the BSP 'cache').
>>         - if it's a 'unconfigured' IRQ it is never cleared.
>>
>> Try clearing all pending GPP irqs in 'BSP_rtems_irq_mngt_set()'
>> (probably 'outl(0, BT_BPP_Int_Cause)') after the
>> BSP_GPP_IRQ_LOWEST_OFFSET loop.
>>
>
> This doesn't look too promising as I understand you, since I do have a 
> serial port ISR installed. 

Sure - the possible problem I try to address here is an issue only 
during the time frame from
IRQ management being initialized [with a serial IRQ pending that causes 
a serial IRQ storm]
until the console is initialized. Once the console is initialized the 
serial IRQ should be properly handled.

If , however, an interrupt is pending and never cleared, everything 
slows down dramatically
since the CPU spends most of the time looping through the isr dispatcher 
only to find that
there is no work to be done.

You could have triggered this problem by enabling 'printk()' statements 
in the irq code while
debugging the timer problem.

>
>
> The serial port ISR has been working great, until I tried to use the 
> network I was happily invoking functions and dumping data structures 
> over the serial port using "printf" and "cexp" while my servo loop ran 
> at 10KHz, and only when I tried to start using the network did I 
> realize that basic timing was broken.  My data acquisition interrupt 
> must run at a higher priority than the serial port.
>
> But since I don't understand the interrupt dispatch code either, I'll 
> try what you suggest.
>
> Hmm.  I don't see any BT_BPP_Int_Cause registers, there are three 
> G_GPP_Int{1,2,3}_Cause registers, that might be byte counterparts, 
> I'll try zeroing them after that loop.

Well, I meant GT_GPP_Interrupt_Cause as a 32-bit register. Why Kate 
accesses it as four byte-wide regs
is one of the mysteries to me. Note that it seems that you missed the 
crucial #0 one where the serial
IRQ is probably pending.

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

If you indeed missed to clear GT_GPP_Interrupt_Cause [which correspond 
to GT_GPP_Int0_Cause],
I'd expect no change in behavior.

T.

>
>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>