Upload of sketch to Arduino Pro Micro is successful but sketch doesn't run until it is power-cycled

I’ve got a very strange problem with an Arduino Pro Micro (5 volt). I just assembled it and was trying to run the Blinky sketch. I have discovered that the sketch uploads properly, but does not run after the upload! I have to power-cycle the Pro Micro to get it to run the sketch. Furthermore, if I attempt to reset it (by pulling RST to ground once or twice – it doesn’t matter), the Pro Micro stops running the sketch and disappears from the USB device tree! Again, it needs to be power-cycled to be recognized and start running the sketch again. (Note that doing repeated uploads doesn’t exhibit this behavior. Although the sketch doesn’t run, the device at least sticks around on the USB bus and continues to respond.)

There are no errors reported by the IDE. It just says the upload is successful. (The same is true for repeated uploads.) Looking at the USB device tree, the VID for the board is 0x1B4F. The PID is 0x9206 before uploading and 0x9205 afterwards.

I’ve tried using the Pro Micro on two different Mac systems (a rather old one and one much newer). It makes no difference. I’ve tried powering it from a regulated 5v power supply. Again it makes no difference. I’ve checked power (using a multimeter) and it is stable at close to 5 volts, so this isn’t a “brownout” situation. There’s absolutely nothing hooked up to it anyway!

This is strange because the sketch for sure uploads correctly. It seems that the “jump” from the boot loader to the sketch fails. And as I said, reseting it makes the situation even worse with the device disappearing from the USB device tree.

So does anyone have any ideas about what’s wrong? I’ve examined the board carefully and everything seems to be in order (no loose components or accidental solder bridges for example as far as I can tell). If it helps, the packaging says it’s from Batch #94517 (DEV-12640, Pro Micro - 5V/16MHz).

I do really like the product, so I’d very much like to see it working properly!

Check that the IDE serial monitor closed when you upload and no other program is linked/connected to the USB ?

Why ?

I get this all the time on an Artemis when the monitor is open on Ubuntu. The upload works without problems but the program is not executed. When I then press reset (with the monitor still open) the USB is assigned to a /dev/ttyUSB1 instead of /dev/ttyUSB0.

Maybe it helps to diagnose.

Thank you, paulvha, for the response. The serial monitor isn’t open, so that shouldn’t be an issue. As for some other process grabbing (or holding onto) the device, that’s a good point. This is a Mac so I’m not sure how its behavior will differ from Linux, but I ran the “lsof” command during and after the sketch upload. I see that avrdude opens the device port (/dev/usbmodem3201 in my case). Once the sketch is loaded, however, avrdude is no longer running. No processes are accessing that device (at least from the perspective of “lsof”).

I’m not sure what else to check.

edit: Note that I have several other Arduinos and they all work, including an Arduino Leonardo. So I know I can use a board with the ATmega32U4 chip without issues. The problem seems specific to the Pro Micro (or at least the one I have).

Please post the sketch, using code tags.

This sort of construct is frequently used, and will hang forever until the serial monitor connects.

Serial.begin(Baud_rate);
while (!Serial);

To avoid that, replace the second line with something like delay(1000);

Next to Jremington’s feedback maybe here is a clue?

https://forum.arduino.cc/t/arduino-pro- … ved/350305

The sketch is the Blinky one (Example 1) from the [Pro Micro & Fio V3 Hookup Guide. As for dealing with the Serial objects, I did one better. I commented them out altogether. Here’s the resulting sketch:

/* Pro Micro Test Code
   by: Nathan Seidle
   modified by: Jim Lindblom
   SparkFun Electronics
   date: September 16, 2013
   license: Public Domain - please use this code however you'd like.
   It's provided as a learning tool.

   This code is provided to show how to control the SparkFun
   ProMicro's TX and RX LEDs within a sketch. It also serves
   to explain the difference between Serial.print() and
   Serial1.print().
*/

int RXLED = 17;  // The RX LED has a defined Arduino pin
// Note: The TX LED was not so lucky, we'll need to use pre-defined
// macros (TXLED1, TXLED0) to control that.
// (We could use the same macros for the RX LED too -- RXLED1,
//  and RXLED0.)

void setup()
{
  pinMode(RXLED, OUTPUT);  // Set RX LED as an output
  // TX LED is set as an output behind the scenes

  //Serial.begin(9600); //This pipes to the serial monitor
  //Serial.println("Initialize Serial Monitor");
  //delay(1000);

  //Serial1.begin(9600); //This is the UART, pipes to sensors attached to board
  //Serial1.println("Initialize Serial Hardware UART Pins");
  //delay(1000);
}

void loop()
{
  //Serial.println("Hello world!");  // Print "Hello World" to the Serial Monitor
  //Serial1.println("Hello! Can anybody hear me?");  // Print "Hello!" over hardware UART

  digitalWrite(RXLED, LOW);   // set the RX LED ON
  TXLED0; //TX LED is not tied to a normally controlled pin so a macro is needed, turn LED OFF
  delay(1000);              // wait for a second

  digitalWrite(RXLED, HIGH);    // set the RX LED OFF
  TXLED1; //TX LED macro to turn LED ON
  delay(1000);              // wait for a second
}

The change made no difference. And paulvha, I read through your referenced forum entry. Unfortunately the symptoms there are different (and far worse). In that case the board wasn’t being recognized. The COM port wasn’t showing up at all. In my case the /dev device shows up just fine. Also, the upload works just fine. The problem as I mentioned is the “jump” (however it’s done) from the boot loader to the sketch. Something goes wrong with that and the sketch doesn’t run. However, when I power cycle the board, then it runs! So the upload is fine. (Searching the internet, I see plenty of cases where someone “bricked” the Pro Micro, or the board doesn’t show up at all, or uploads don’t work at all, etc. But I haven’t found a single case where the upload works but execution failed immediately afterwards, but is fixed by a power cycle.)

The other nasty problem I mentioned is how reset is handled. For me, doing a board reset causes the board to no longer be recognized. It falls off the USB device list. It also doesn’t run the sketch. But again, power cycling the board fixes the problem. It shows up in the USB device list and runs the sketch.

The reset problem is what’s really bothering me. I can see the boot loader somehow failing to “jump” to the sketch. But the IDE resets the board! So how is a manual reset not working? I realize the reset the IDE is doing is through USB whereas I’m doing it by grounding the RST pin. But still. The behavior makes me feel like I have a defective board. But I’m not giving up yet.

The other thing I’ve wondered is if I have a corrupted boot loader. However, if that were true, I’d think something else would (severely) fail, and not just the final “jump” to the sketch. Also, what gives with the board reset? That also could be a bad boot loader, but why would a reset via USB work but a reset via the RST pin not? And that’d mean there were not one but two very targeted failures of the boot loader.

edit: Ah. As for the reset behavior, probably what’s happening there is the boot loader resets, sees that there’s nothing else for it to do, and tries to “jump” to the sketch and fails. So the problems are likely the same. But with that said, why would reseting the board (or uploading a sketch) cause the sketch to fail to run, but power cycling the board (which also resets the boot loader I’d think) work properly?](Pro Micro & Fio V3 Hookup Guide - SparkFun Learn)

I wish I could help you more.

I looked at the schematics and see that actually it looks to miss the connection between RESET from JP6 -3 to pin 13 of the AMtmega32U4, but the board layout is showing it. It also does “something” as your device disappears in the MAC.

I saw in the hookup guide that additional files need to be downloaded, select the Sparkfun Pro Micro and the correct settings in IDE ( e.g. the 5V is different than 3v3). I assume you have done all that. I see in these files that it performs a reset after upload: use_1200bps_touch=true.

MAYBE… maybe you can get hold of a windows PC, download the IDE and try to upload blinky. If that fails as well it must be the board.

Thank you, Paul, for taking the time to think about this. (And thanks to the others who have responded. This has thus far been a great introduction to this community!) So I’ve got a plan… First, I’m ordering another Pro Micro (since they’re pretty inexpensive). Second, I’m going to try burning the Bootloader onto the board. I’m honestly expecting that not to help, but we’ll see.

And yes, I’d added the needed board definitions and selected Pro Micro plus the correct voltage. (Truth be told I made a mistake the first time and uploaded for the Leonardo. However, the board didn’t brick. I’m assuming doing something like that won’t actually damage the Bootloader, considering I don’t see any reports of that.)

And there are a couple more potentially important details. The Pro Micro I’m using had been sitting in its unopened poly bag for about 3 or 4 years. (I just finally got around to using it.) I don’t know if they have a “shelf life” (due to electron migration for example). Also, I did solder the headers on it before testing it. I don’t know if the soldering process damaged the board in some way. The next one I’m ordering, when it arrives, I’ll test before doing anything else.

I’ll keep you all posted when I have an update.

I ordered a new Arduino Pro Micro and tried the same procedure (I loaded the Blinky example) and it worked fine, so something is simply wrong with the first one. I can try refreshing the boot loader to see if it was corrupted somehow. Otherwise, it’s trash.

Thanks for sharing and good to hear it works.

Too bad you had to start off with a bad experience with the board, but I am sure you learned more than you wanted.