I have read multiple posts on how to reset the sparkfun pro-micro when it gets stuck during upload, and this seems to work to get it back to a state where I can upload new code again - However, I am here to ask if it is possible that it is something in my code that is causing this issue? The reason I suspect it is my code is because I have tried:

• Different pro micro
• Different USB cable
• Tried reverting back to an older AVR boards package as suggested in a different post

Not sure if this is a coincidence, but when I upload a simple blink sketch I don't have any trouble, but as soon as I upload my code (below), it gets stuck on uploading... I can get it to eventually upload after many attempts using the reset during upload trick, but it seems to be unstable. I say unstable because sometimes it will print out the values requested, and other times it will print nothing...

int clampVal = 0;

void setup() {
Serial.begin(115200);
}

{
const int numRead = 400; //amount of calibration values we will average
double total2 = 0;                  // the running total
int calibration2 = 0;               // calibration incrementer

}
{
}
calibration2++;
}

}

void loop() {
Serial.println(clampVal);
}


EDIT: Once I reset and upload an EMPTY sketch, I can upload the empty sketch with no problems. I did it 5 times in a row with no issues. Then tried to upload the code above once, and it worked..but then tried to upload second time, and stuck in uploading again... it has to be the code, but I can't narrow down what it is.

Uno's Mega's and so on have a separate MCU (u3) that contains the boot loader and is responsible for the USB connection and for driving the virtual serial port. Micros ( and also Leonardos and Esploras ) have built in USB support in the main MCU (u4). So if your program does something that breaks the USB part of the MCU the communication breaks also. This happens for instance if you disable the interrupts.

The only thing you use in your program that might cause a problem is the Serial connection. The blink example has no serial output.

If you add a Serial.begin(115200) and a Serial.println("Hello") to the blink example, I guess the problem occurs also.

The IDE establishes the programming connection by connection to the selected com port at 1200 Baud. The boot loader recognizes that, performs an auto reset and opens a second (programming port) from then the IDE has access to this port and uses it to communicate with the boot loader. On a UNO this is handled by the separate MCU and on the Micro the main CPU is responsible for that.

Perhaps it helps if you add a time delay, before the Serial.begin(). Then you will have more time to start the programmer.

There is also a trick to enlarge the time you can start the programming after a reset to 8 seconds. https://forum.arduino.cc/index.php?topic=224416.msg1643210#msg1643210

Your code is unnecessarily complicated. If you want, you can try the program below. I think it does the same as yours. I have no compiler and no micro at the moment so it's complete untested.

You used a calibration variable. I guessed that it is for skip the first calibration values. If you need the values you can store them in a separate array.

My prog. has a lower memory footprint because I store the integer values from the analog input into an integer array. You used a double array.

You also did a lot of unnecessary computations after you read an analog value. This can slow down the readings. Perhaps therefore you missed some values you expected to see.

//amount of calibration values we will average
const int valueCount = 400;
const int calibCount =   0;

void setup()
{
Serial.begin(115200);
}

void loop()
{
int vals[ valueCount ];

for (int idx = 0; idx < valueCount + calibCount; idx++)
{
int rawValue = analogRead( A0 );
if ( idx >= calibCount )
{
vals[ idx - calibCount ] = rawValue;
}
}

double total = (double) 0.0;

for (int idx = 0; idx < valueCount; idx++)
{
total += (double) vals[ idx ];
}

Serial.println( total / valueCount );
}

• Thanks @peter Paul Kiefer for the very thorough explanation! When I get back in front of my micro later I will try your suggestions and code, fingers crossed it works! – MattG Nov 27 '19 at 20:15
• That seems to have done the trick. I put in a delay of 500ms between serial prints and now it uploads repeatably. Thanks for the help! – MattG Nov 27 '19 at 23:49