AVR-Chat

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@c...> wrote:
> 
> >If that doesn't work, then expand the logic analyzer.  Keep the 
debug
> >pin operation as above, but track the address/data lines to the
> >sram.  Flag every time a write happens to 0x3b1, and verify that 
the
> >debug pin is being toggled around it.  This will prove that the
> >writes are or aren't happening at places in code where you expect
> >them to be happening.
> 
> Did I mention that it's internal SRAM?

Argh - dang.  You probably did.  I was commiserating too much to 
notice.  That makes things a little tougher :)

Hrm.  I suppose really all you can do is start instrumenting each 
routine, one at a time.  Pepper the code with diagnostic port 
outputs, before every section that can write *anywhere* to sram.  
Output an ID code, then the current value of 0x3b1, do the 
operation/loop/whatever, then output 0x3b1 again.

Logic analyzer on the debug port, and watch for 0x3b1 to change when 
it shouldn't.  Do it one or two routines at a time, to keep the scope 
of the reams of debug data at least a little bit manageable.  Also 
lets you put a ticky mark next to each one as you eliminate them, to 
narrow the search down.

You have to put that debug code around everything though, even stuff 
you think is pretty simple and obvious.  I've been bitten by slap-the-
forehead things an embarrasing number of times :(

Dean.