AVR-Chat

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@c...> wrote:
> 
> Having a persistent problem that is proving resistant to standard 
debugging 
> tricks.
> I'm hoping that talking it through here, will dredge up the problem.
 
These are the worst kinds of problems to diagnose.  It's like taking 
the car in for service, and *swearing* to the service manager 
that "it was making that noise as I drove here, and it stopped when I 
entered the parking lot.  Honestly !"

With complex systems like this, I've always found tracer tags to be 
very useful, proving that it's operating the way I think it is.  In 
this case, if you have a spare port, or even just a pin, use it to 
indicate where in the code things are.

For example, dedicate a pin to the act of writing to 0x3b1.  In code 
set the pin, write the sram, clear the pin.  If you have spare pins, 
use them to indicate an ID code for each write.  Set the ID code, set 
the debug pin, write the sram, clear the debug pin.

Then logic analyzer it to death.  Run it, see the error, then spend 
evenings scrolling through the pulse data from the debug pins.  The 
only hassle with this is that it really only finds programming/logic 
errors - writes happening when you didn't expect them.  It won't find 
erroneous writes from buffer overflows etc.  If there's some bizarre 
error somewhere - bad pointer etc - it won't catch those.

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.

If every write has an appropriate debug pulse, then it's in the 
code/state-machine somewhere.  If not, then there's a rogue unplanned 
write happening, and that's when things really begin to suck.

Dean.