AVR Freaks

The device only seems to run for a small amount of time before it would appear that the device resets continuously. It seems to be anywhere in the range of 15-60 seconds after immediately removing the power supply. If I leave the device off for about 5 minutes and then turn it back on, it seems to be more in the range of 3 or more minutes before this starts to happen.

This may actually suggest a software issue.  If the behaviour is different for short power-cycles than it is for long-power cycles (i.e. power left off for an extended period), then it >>may<< point the finger at an uninitialised automatic variable somewhere, or another C 'gotcha' like a buffer overrun.

SRAM is not initialised by hardware (nor by the C runtime provided by avr-gcc), and remains unchanged after a reset.  Only variable specifically initialised by the code (or static or global variables) will have a known value after a reset.  When Vcc is allowed to drop below about 0.2V however, the contents of SRAM begins to get corrupted.  An AVR which has been fully powered off (Vcc drops to zero) will not, as you might think, power up with SRAM all zero.  SRAM contents after a full power off will effectively be random.  I say effectively, because it isn't random every time.  It looks random to you and me, but it's actually the result of process variations and is different from device to device.  Bottom line is the different behaviour for 15-second power down (where the power supply caps may not discharge fully, or at least not below 0.2V or so) and a 5 minute power down (where the caps are likely fully discharged) may be a symptom of this kind of coding error.

Of course, it may indeed be a hardware problem as you have suggested.  There isn't much to go on.

I would suggest trying to rule out at least uninitialised variables by combing through your code and making sure that every single variable, array, and struct is in fact initialised, whether or not you think it's necessary, and see what that does to the behaviour.  Hopefully it won't be time wasted.

Nothing to do with your issue, but I would also avoid tying AREF to VCC.  An error in code can destroy the ADC.  AVCC is already available as an internal voltage reference, so there is no value in applying it the the external reference at AREF.  Just tie AREF to GND via a 100 nF cap.

main gets called at around 0x22E with call being 4 cycles, so that's 562 cycles before the first op code happens in main. The simulator reflects this closely (cycle counter is 564 with the break point on the first line of main).

That's a coincidence.  You can't really extrapolate the number of cycles executed before main by the address at which the call to main is placed.  The C runtime startup code includes two loops, one to clear .bss variables, and one to initialise .data variables.  If one or both of those sections is sizeable, there could conceivably be many thousands of cycles before the call to main.

As Lee has mentioned, the proper way to handle this (for avr-gcc) is to use one of the .initN sections.  Likely .init3 would be best.  See here:

http://www.nongnu.org/avr-libc/user-manual/mem_sections.html

The wdt.h library has a specific example:

http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

EDIT: typos