[clue-tech] Bad IDE hardware + compactflash, what to do?

[marcus hall]

On Sat, Dec 17, 2005 at 11:52:21AM -0700, Jim Ockers wrote:
> > Can you determine why the interrupt takes so long to reset?  My 
> > understanding is that when an interrupt happens an ISR gets run.  As 
> > soon as it's "safe" the interrupt is reset (don't know whether unmasking 
> > can happen before it's "safe").  So it seems like there's a bit of code 
> > that takes too long to get done.  If slow CF means it isn't safe to 
> > reset for 80ms then you seem to be out of luck.
> 
> How would we determine this?  We can see the lengthy interrupts
> using the oscilloscope but I'm not sure how to tell which part of
> the code is taking too long to return.  I suspect it's something
> in the hardware.

One way to see into what the software is doing, if you have any GPIO
lines available (even if they may be normally used for other things, but
can be borrowed momentarily, perhaps serial port modem control lines, or
parallel port bits, etc.) is to drive the bits high and low at various
times.  For instance, set one bit whenever the IDE interrupt handler
is entered and clear it when processing (or some particular step) is
done.  Looking at this bit along with the interrupt request from the
CF will help determine if the system is slow to respond to the interrupt
in the first place (perhaps interrupts are disabled for a long time in
some driver), or if it takes a long time to complete the service (perhaps
the driver is blocking on something that is reserved by another driver),
or whatever.  By asserting different edges at various places in the
software, you can help to determine where the time is being spent.

-- 
Marcus Hall
marcus at tuells.org
_______________________________________________
CLUE-tech mailing list
CLUE-tech at cluedenver.org
http://cluedenver.org/mailman/listinfo/clue-tech