program and debug AVRs without a serial interface

[ralphd]

I made a simple and small (18-byte + 4 byte setup) function to use the EEPROM as a circular debug log, which then can be read with the same programmer used to flash your code.
http://nerdralph.blogspot.ca/2015/06/avr-eeprom-debug-log.html

[mikerj]

Just be aware that the lengthy write time of the EEPROM could easily cause timing related bugs in your code, particularly when writing long strings.

Also if you held the EEPROM log address in a separate variable rather than relying on the value in EEARL being correct, then your code could use different areas of the EEPROM for other purposes (e.g. calibration values).  Obviously this would require an extra byte of SRAM.

[ralphd]

For debugging timing-critical code, neither eeprom nor serial is practical.  For that I'd use a logic analyzer or scope.

[mikerj]

For debugging timing-critical code, neither eeprom nor serial is practical.  For that I'd use a logic analyzer or scope.

The point I was making is that it takes so long to write to EEPROM, that even code that wouldn't normally be considered timing critical could fail.  It's not a few microseconds you are tying up the micro for, it's a few milliseconds for each character which could quickly add up to many 10's or 100's of milliseconds for a string.

It would be most useful for an error handler that stops the main process running completely, and then writes a message log with e.g. stack information etc.

[nuno]

If the micro is so small that I can't spare even a single pin to make a dataout debug serial-something interface, I run it heavily under simulation 1st or develop in a bigger chip.
But the EEPROM method can still be useful, like for logging exceptional conditions on the field for later analysis

[ralphd]

I agree eeprom writes are slow.  My point is that *both* serial and eeprom are slow.  9600bps takes 1ms per character vs ~3ms for eeprom writes.