Kind of strange interrupt behavior

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Mon Dec 10 21:53:21 UTC 2001



 > Is the BSP you are using part of the official RTEMS tree
 > - i.e. what BSP are you using?

Yes, the Mongoose V bsp- its pretty new, but based on longstanding
MIPS R3000 support.


 > Other questions, about the timers (i.e. the 1Hz irq source
 > and the system clock timer):
 > 
 > - Are their clock signals synchronous,
 >    i.e. are they derived from some common source?

Yes, the 1hz signal is divided down from a common system clock
(12mhz).


 > - How accurate
 >    are the timing intervals, i.e. are the timer periods determined
 >    by the hardware only or does the software have to restart them
 >    after expiration?

The hardware guy asserts they are determined by hardware, the ack only
resets the interrupt signal, does not reset the timers.


 > - What is the priority of your 1Hz timer IRQ compared to the
 >    system clock IRQ (higher, same or lower)? How are nested
 >    interrupts handled by your hardware (and your BSP)?

Lower, fixed by virtue of the interrupt processing order; the timer
tick is tested first.  We are not employing nested interrupts at this
time.



 > (My first, wild guess would be that the clocks beat against each other
 > with a periodicity of ~20min and that the 1Hz timer hits the
 > system clock [which is probably at a higher priority] while the
 > clock handler is working, resulting in a high latency.)

I could see that if there was one high latency interrupt every 20
minutes.  From our measurements the high latency period extends for
several minutes, then goes back to normal until the next 20 minutes
elapses.

 
 > Some suggestions:
 > 
 > - you could run your test on a completely idle system
 >    (only the idle task should be running).
 > - try to run the test without a system clock driver.
 > 
 > Do you still observe the 20min periodicity?
 > 

The high latency interrupts occur at a lower latency in an idle
system, but still occur every 20 minutes.  I've not tried it without
the clock driver yet.

>From other conversations today, I've gotten a glimmer of an idea that
this may be somehow hardware related.  The previous os for this
hardware was VxWorks, and apparently it had the same (or related)
trouble.  The interrupt signal looks fairly stable over time, but its
coming from a locally designed bus controller that manages a bunch of
other stuff.  It might be possible some pathological condition is
interfering with the interrupt signalling.  I'm reconfiguring our test
rig to try and get a handle on that.

Gregm




More information about the users mailing list