Resolved: UNO sometimes fails to start after upload

My UNO fails to start after an upload maybe 1 time in 5 or 6. To fix it, all I have to do is upload again or press restart. When this happens, there are no errors reported and the software indicates "Done uploading". What might be causing this?

Authentic Arduino UNO Windows 10 Arduino 1.8.9

This is not a typical failure mode, more information is required.

Does it happen with a simple sketch like blink?

Does it happen with nothing else connected to the Arduino?

Does it happen with blink and nothing else connected to the arduino?

The answers to these questions will determine where to look for the problem.

Unless the problem occurs with blink, you need to post your code, because that's probably where your problem is. Post a complete sketch that demonstrates the problem.

Unless the problem occurs with blink and no external hardware, we also need to see a schematic or wiring diagram.

If the problem occurs with blink and no external hardware, you have a problem that I've never heard of before. I think this is extremely unlikely.

It turns out the arduino is starting but it stops in the setup routine.

I pulled the arduino out of my project and removed the shield, loaded up blink and it worked every time. I put it all back together and started adding Serial.println commands at various placed until I located the place where it stops. i am using an MPU6050 And when its MPU6050_setup is called, it calls the MPU6050_read routine. In that routine there is a Wire.beginTransmission , a Wire.write, and a Wire.endTransmission.

When things lockup, I see the message, “Before Wire.endTransmission” but not the message, “After Wire.endTransmission”. It always locks at this point and always the first time through. So I believe I have located where the trouble is, now I have to isolate the cause. There are no other I2C devices on this project so no possible conflicts.

Since it always locks up the first time through, I will try using a short delay before setting up the MPU6050 in case it needs to stabilize. If that doesn’t help, there is about 2’ of unshielded 4-wire cable between the arduino and the mPU6050. I can make up a short cable to see if that helps. I might also try putting a bypass cap at the MPU6050 between 5V and Gnd to see if that helps. I am using the default Wire library so i’m guessing/hoping that is fairly stable.

  // MPU6050_read n bytes
int MPU6050_read(int start, uint8_t *buffer, int size)
{
  int i, n, error;
//  Serial.println("Before Wire.beginTransmission ");
  Wire.beginTransmission(MPU6050_I2C_ADDRESS);
//  Serial.println("After Wire.beginTransmission ");
  n = Wire.write(start);
//  Serial.println("After Wire.write ");
  if (n != 1)
    return (-10);
  Serial.println("Before Wire,endTransmission");
  n = Wire.endTransmission(false);                // hold the I2C-bus
  Serial.println("After Wire.endTransmission");
  if (n != 0)
    return (n);

  // Third parameter is true: relase I2C-bus after data is read.
  Wire.requestFrom(MPU6050_I2C_ADDRESS, size, true);
  i = 0;
  while (Wire.available() && i < size)
  {
    buffer[i++] = Wire.read();
  }
  if ( i != size)
    return (-11);

  return (0);  // return : no error
}

The 2' 4-wire cable from the UNO to the MPU6050 was replaced with a cat 5E cable that is about 4" shorter. Since then, the system no longer locks up. I suspect it is the twisted pairs in that cable rather than the length that resolved the problem.

In any case, this is now resolved.

Just as a bit of background info- I2C is meant for use between ICs that are together on a PCB, so 2' between the two devices is definitely pushing it. You did well isolating the cause of the problem you were having though. If you do keep having issues you can get I2C bus extenders which are ideally suited to your situation.

Thanks BJHenry!

I didn't know about these. I now have 2 of them on order. :-)

Another trick for long I2C wires is to lower the I2C clock speed. I've heard stories of people making I2C work with cable lengths in the tens of feet, slowing the bus frequency down to like 100hz or something.