AVR Freaks

Are you saving stuff to EEPROM or Flash?

If you do, and managed to save some "bad" value which "crashed" the code - then that could persist across a power cycle ...

Once the code has got into its "misbehaving" state, can you read out the flash contents ... ?

Since any computer is always doing something [1] it would be very interesting to try to find what it is doing when it is misbehaving.

Do you have any means of "instrumenting" your code and let it output rudimentary trace "info" to e.g. one (or preferably several) LEDs?

Having an ope n mind (i.e. not pre-convincing yourself about the nature of the bug), place trace-points at different spots to try to deduce where execution is when the system misbehaves.

Unless the system is of a highly real-time nature, an on-chip debugger might serve you very well. Free-run a debug session til the problem occurs, then break and start single stepping etc to see what goes on. Note that breaking or single-stepping in code that is timing- or "data-flow"-critical might provoke problems that on the surface could look like part of the problem, while in fact they are an effect of e.g. data overruns because of the slow/staggered execution and response when stepping/breaking.

So, you got an ICE?

[1] Not entirely true for all computers, I know...

One of the common sources of lockup after some operating time is stack overflow. That, however, SHOULD be corrected by a reset. 

It might be waiting for something to happen, and that something never occurs (maybe because something got turned off, or some variable got changed to an unexpected value). Thinking of something like waiting for ADC to complete a conversion, but that the ADC got disabled so that the start convert command is never acted upon.

Can you put it on a debugger and let it run until it "breaks", then do a manual break, determine where it is when you halted it, then see where it goes as you single step from there?

Jim

But, as Johan suggested, how do you know that it has stopped "completely"?

How would you distinguished "stopped completely" from just "stopped accepting serial commands" ... ?

 If the value is bad it won't be calibrated properly but it should still respond to commands.

Should it?

If, say, the timing messes up the baud rate - that would stop it responding to serial commands ...

I don't know what you're "calibrating" - so don't know how messing-up that calibration might affect things.

But grossly out-of-range values might cause strange under- and/or overflow effects ...

Again, as Johan suggested, "instrumenting" the code could help ...

If it accepts serial commands presumably the same UART can be used for output? If so I'd follow Johan's advice by instrumenting the code with liberal printf() as it enters/exits functions and conditional sections. Try to isolate where it is executing when communication has stopped.

When you  write to UDR, wait for the UDR to become empty before writing the next character. You COULD have serial problems, especially at the other end, if you change the UDR before it is empty.

Jim