AVR-Chat

On Mon, Feb 09, 2004 at 04:36:30AM -0500, Dave VanHorn wrote:

> This system receives data from a master system, using a latch that I read,
> during the INT0 ISR.
> If the host "blips" the int line, then it won't be high by the time that I
> look at it in the ISR, (Physically impossible) and so that is "data", which
> I count, and store using X as a pointer dedicated to this ISR.

Are you 100% sure about this?  What do you mean by "blip" - how long
is the pulse?  And is it _possible_ that sometimes the "blip" is a
little longer than you expect?  What generates the pulse?

> If the host holds the int line low, then I read this data as a "command",
> and store it in a special SRAM slot, where it is acted on in the main
> routine.

I would home in on this part and see if sometimes the host's data blip
is sometimes being interpretted as a command blip.

> Also, the diag version runs fine in real hardware, producing endless
> perfect output.
> 
> In the diag version, the int0 ints can only happen at one point, when all
> the other tasks have run, so it's not a "real" test.
> Because the ints are faked by code in the target system, they can only
> occur at one point in the code, and they "slam" a full packet in before
> returning to the main program flow. Making this more scattered would be
> extremely problematic.

Is there anywhere in the code where a multibyte pointer variable is
updated or used in both interrupt routines as well as non-interrupt
routines?  Perhaps you have a classic atomic update problem - it works
when you can control when the int0 interrupt occurs, but fails when
the int0 interrupt can occur at any point.  I would also focus on this
as a possibility.  Check every where you load or change the pointer
value.  If the pointer can change inside an interrupt routine, then
double check that interrupts are disabled when the pointer is
dereferenced outside of the interrupt routine.

BTW, this reminds me of once when I struggled with weird memory
corruption bugs for week and the eventual solution was solved by the
setting of a single bit flag!

-Brian
-- 
Brian Dean, bsd@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
http://www.bdmicro.com/