AVR-Chat

At 07:24 PM 2/9/2004 -0500, Brian Dean wrote:
>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?

99%... :)
The pulse is just longer than the minimum that will give a guaranteed int 
on the M8 at 8 MHz.
In theory, I couldn't possibly get into the ISR at all, before it goes away.
I also do about 8 instructions before I test, to make it difficult to false.
However, I'm wondering if the host slips me a second, I could be seeing 
that strobe pulse as the long pulse for command.

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

I think it's inside a cli/sei, but I need to verify that.


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

Possible, I'll check.

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

That's what it feels like.


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

Did I mention that I have a raging case of the flu as well?