AVR-Chat

Set up a counter, break on a memory location, do something so you can catch
the processor a few cycles prior to the failure, then step through until you
catch it.  This is very painful, but entirely possible.

Could an interrupt interfere and change the flags after the test, but before
the branch?  Your results and the shifting time it takes for the failure to
occur sounds like a classic race condition between an interrupt handler and
some foreground code.

Try wrapping your test of SP in a CLI/STI and see if the problem goes away.
Maybe re-inspect your interrupt handlers to make sure they properly
save/restore the SREG, etc.

Good luck!

-----Original Message-----
From: David VanHorn [mailto:dvanhorn@cedar.net]

At 01:31 PM 1/2/2004 -0800, Larry Barello wrote:

>Since you know exactly when it trips, set up the simulator to break a
couple
>hundred cycles prior to the fault and single step your way to bliss.
>Eventually you will see the error.

How?

The SP is 045F when the test fails.
The test compares 045F to 045F, and tells me <>.
The same test passes thousands of times, before it fails.