List of possible reasons for crash/hang?

What are the possible reasons for Uno to crash or hang? I mean nothing is happening. I do not expect it is possible for the LED to stop blinking, yet it has stopped. I waited much longer than a minute. When looking at the EEPROM data, it stopped many minutes before I arrived. The data does not look suspicious. The purpose of my code is to log sounds outside. The minutes are not exact they are meant to be calibrated in Excel later. It does not appear to happen again, but I have to wait 10-20 hours to be sure. Let me start the list with things that did NOT happen here.

Infinite loop
memory full
low voltage PS
disconnected hardware
interrupts

Just realized the LED would not flash every minute if the Mic failed or got disconnected. But it was not disconnected!
I pushed reset and it began flashing immediately with my noise, as it should.

What if n overflows (it did), then iminu-sincemin would be negative. What happens when you write a negative value to EEPROM?

#include <EEPROM.h>
#define LEDON digitalWrite(13,HIGH);
#define LEDOFF digitalWrite(13,LOW);
#define WR32 Serial.write(32);
int iavg,imax=0,c12=0,n=0,iminu,sincemin,eep=0;

void setup(){
pinMode(13,OUTPUT);
Serial.begin(115200);
while(eep<1022){  //1022
  Serial.print  (EEPROM.read(eep++));WR32
  Serial.print  (EEPROM.read(eep++));WR32
  Serial.println(EEPROM.read(eep++));
}
eep=0;
iavg=avg();
}
void loop(){
delay(50);  //50 wo 250 w Narco
if(++n%1000==0) iavg=avg();  //takes 307ms throws off timing
if(n%180>=3)LEDOFF
if(mx()){
  LEDON
  c12++;
}
if(n%(12*15)==0) if((imax>10)||(c12>2)) { 
    iminu=n/12/15;  //180
    LEDON
    Serial.print(iminu-sincemin);WR32
    Serial.print(imax);WR32
    Serial.println(c12);
    EEPROM.write(eep++,iminu-sincemin);
    EEPROM.write(eep++,imax);
    EEPROM.write(eep++,c12);    
    EEPROM.write(eep,0);  //eof
    sincemin=iminu;
    c12=imax=0;
    }
}
int avg(){  //307ms
long ii=0;
for(int i=0;i<500;i++){
ii+=analogRead(0);
delayMicroseconds(500); 
}
ii/=500;
return(ii);
}
int mx(){
int j=0,ii,was=0;
for(int i=0;i<500;i++){
ii=analogRead(0);
if((ii>j)&&(ii>was+1))j=ii;
was=ii;
delayMicroseconds(400); //0.25 sec
}
ii=j-iavg-10;  //was4 works2 w batt
if(ii<0)ii=0;
if(ii>imax)imax=ii;
return(ii);
}

Not the cause of your problem, but I do wish that you had used the spacebar a little more liberally.
if((ii>j)&&(ii>was+1))j=ii;is difficult to read and interpret whereas  if ((ii > j) && (ii > was + 1)) j=ii;is clearer. What it does not reveal is the intended scope of the if statement.

   if ((ii > j) && (ii > was + 1))
{
  j=ii;
}

would be better otherwise the if block is not clear. This is even more so in

 if(ii<0)ii=0;
  if(ii>imax)imax=ii;
  return(ii);

I’m sincerely sorry to put you thru it HeliBob. I write C++ every day for my job. I’ve been doing it for nearly 30 years. I’m in the mode where I didn’t plan on sharing this code. It’s so simple! It is my own style that I like best for me. I have a different style at work, the recommended way of formatting for others to read. Can you help me with a more general list of:

Common and less common Reasons the Uno hangs?

Then maybe look at my code.

Common reasons for a crash are buffer overflow or the heap and stack colliding.

I'm struggling to follow your code, but it seems that the led flashing isn't unconditional - it appears to be impacted by what you get from analogRead. I'd suggest some more serial prints, or perhaps a blink without delay flash of a different led unconditionally at the top of loop so that you can be certain that there has actually been a crash.

Buffer overflow? Which buffer? You're correct. The LED would not blink if there was no change in voltage. This cannot happen with my simple hardware setup when there is sound. To test this I carefully hit reset without bumping the wires which are connected securely. It works as expected.

sbright33: I write C++ every day for my job. I've been doing it for nearly 30 years.

Then you really should know better than to do things like this:

#define LEDON digitalWrite(13,HIGH);
#define LEDOFF digitalWrite(13,LOW);
#define WR32 Serial.write(32);

Firstly, if you want to abstract these actions, write a function to do it, don't hack it in the pre-processor. Second, if you are going to hack it with a macro, design it so that calls to your macro leave source code which is syntactically valid. Your code layout may be your personal preference but in general it strikes me as appallingly bad.

None of this relates to your problem but leaves me with little sympathy when you're struggling to see what the sketch is doing and why.

Back to the problem. Most likely causes IMO are:

External reset trigger causing the board to reset. Power brown-out causing the board to crash or reset. Noise on the power supply causing the board to crash or reset. Memory exhaustion causing the board to crash or reset. Memory corruption causing the board to crash or reset. It's not crashing or resetting - your sketch is just not doing what you expect, either because of a bug in the sketch, or inputs different to what you assumed.

sbright33: Buffer overflow? Which buffer? You're correct. The LED would not blink if there was no change in voltage. This cannot happen with my simple hardware setup when there is sound. To test this I carefully hit reset without bumping the wires which are connected securely. It works as expected.

I still say put a heartbeat LED in there to prove to yourself whether it's crashing or not, with a ten second delay with it on in setup so you can detect a reset.

Thanks for the wonderful Compliments and a comprehensive list! Even though it doesn't apply. Not being sarcastic, that's what I asked for.

Many possibilities come to mind. None of them likely. Will add a heart beat. I know it's resetting when I press the reset button. Here's one: Somehow avg is calculated way too high. Then noise will not trigger the LED. avg is calculated every 5 minutes. Never had this problem during testing inside...

WAIT A MINUTE that's it! Thanks everyone for listening. ii overflowed in avg()? Let me look. No. Back to the drawing board...

Keep in mind this happens after 10 hours. Not before. Yes, n overflows. But it overflows TWICE. Didn't crash the first time. Fixed.

Cannot reproduce the error. Maybe it was a leaf or stick resting against the Uno. The next day left it out all night in the rain, it didn't fail!