Clock not running (was Re: RTEMS4.7 and its tool chain (Re: powerpc mvme5500 clock off by factor of 150))

Peter Dufault dufault at hda.com
Tue Mar 8 21:34:13 UTC 2005


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.

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.

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.

Peter

Peter Dufault
HD Associates, Inc.




More information about the users mailing list