AVR Freaks

I certainly agree with Lee and JS, Brown Out Detection certainly needs to be enabled.

Also, as an vehicle app, I assume the power is WELL FILTERED against Load Dump type spec's, that includes both the power rail, AND every sensor / input that comes from something connected to the vehicle power bus.

Starting up the vehicle is one of the noisiest times on the power rails, and hence on any signal input, as well, although that is actually a continuous problem on vehicle apps.

With your description so far, you really don't know if the uC "failed" at some point in the 20-30 minute idle time, or "failed" right with engine startup.

My first guess would be that it fails during engine startup, with noise / glitch trashing the poor micro's digital bits.

Do you have a "spare" LED on the PCB?  (A project can never have too many LED's, I think that was Moore's Second Law of computers (smirk)).

If you simply flash an LED 5 times on power up you have confirmed that your clock is running, and that the micro is running.

With the temperature extremes of vehicle apps, that is a good idea anyways, not just for initial debugging / validation. 

Since you have your "spare" LED sitting there, might as well put it to good use after startup, also.

How about waking up every now and then and flashing the LED.

Don't need to do that in the final code, perhaps, but would be helpful now.

With that you can see if the micro is still behaving during your 20-30 minute wait.

Next, as is always the case, you really, really, what to find the underlying cause of the problem, otherwise it is very difficult to be certain that you have ever actually fixed the problem.

Do you have a good, decent BW DSO, so you can watch the power buss and other signals on start up, and see if the noise gets through to the micro's pins?

Watch the vehicle bus on one channel, the pins on the micro with another channel.

Gotta mention the occasional culprit on custom PCB's, although I suspect you know this one well:

Are ALL Vcc and AVcc; and ALL Ground pins on the micro connected to V+ & Ground?

Are they ALL by-passed with 0.1 uF caps?

Do you have lots of extra filtering on the power supply rail?

Almost forgot:

Related to the BOD requirement.

What does your main V+ do during the engine crank?

It isn't unusual for it to dip quite low during the crank, especially if the engine is cold, (your neck of the woods!).

Easy to watch the power supply during startup for this one, also.

An "easy" check here, of course, is to power the PCB from a battery, with a common Ground to the vehicle's power bus.

That wouldn't explain, however, why it works with the short delay, but not with the long one.

You mentioned:

But If I wait 20-30 minutes the app won't run.

Anytime I see that kind of symptom I also think one has to consider Stack Overflow, etc., where the problem is somewhat time dependent.

When the app runs long enough, and Interrupt X has fired enough times, etc., system crashes.

Related to that, also, is variables that get trashed after a period of time, as at some point an interrupt fires while the variable is being updated, totally trashing it.

(I spend 3 months tracking down an atomicity bug in a GPS tracking / mapping app a few years ago, and still have nightmares of the darn bug!)

Again, with a few second delay, you get lucky and the program works.

Wait a bit, (20-30 minutes in this case) and the bug has a chance to manifest itself.

Is the micro waking up and doing anything during the 20-30 min null period?

So, like always, one of the first steps is determining: "Is this a HW problem or a SW problem?".

Bench testing with clean signals will go a long way towards helping make that determination.

SW bugs should still show up, the HW bugs will disappear.

Good luck with your project!

JC

Edit: Typo

I've had this problem in the past.  I had to reflash to get it to run.  I think I used a bootloader, but I'm not sure.  I'm pretty sure it was not flash corruption and it was not BOD.  I don't remember what it was.

Does the problem happen when the Atmel ICE is not connected?

So is it the case that the mega runs when the programmer is attached and does not run otherwise?   This is a fairly common occurrence around here.   Two causes I've seen are a bad ground that the programmer attachment fixes, and a resistor on the reset pin.