# What are some reasons my atmega32u4 loses program when disconnected from power?

I have two different boards running the same code with the same chip (ATMega32u4).

Problem Summary

THe problem is that the 2nd board seems to lose the program that has been flashed to the chip if it loses power.

Both of these boards have mini USB connectors and get power from USB and both run at 5v.

First (Working) Board

The first board is an "official" SparkFun Pro Micro.

Second (Failing) Board

The second board is a knock-off of that board which I bought on amazon. You can see the details for that board at: Pro Micro knock-off board at amazon

NOTE: I'm not expecting anyone to examine those boards perfectly and tell me the exact reason why. I'm just adding that info in case someone notices something completely different that would indicate the problem.

Programming the Boards

When I program the boards I set the Arduino IDE to the Pro Micro board at 5v and 16Mhz and the program flashing works equally well on both boards. I then run the knock-off board and it works perfectly. It's a little program that receives data from bluetooth and displays the data elsewhere.

Loss of Power, Loss of Flashed Program

On the first board, I programmed it once weeks ago and it works after being powered off for days. Obviously, that's the way it is supposed to work.

On the second board, if it loses power at all it seems to lose the program.

Common Things To Check?

I'm just wondering if there are some common things I can check to determine why the program seems to be lost.

Are there any obvious things that I'm just missing? Is it possible the manufacturer hasn't wired something up properly which would cause this --- I mean is this common problem with board manufacturing? I have 5 of these knock-off boards and have tested two so far and both seem to have the problem.

Any help is greatly appreciated.

I found the following information in a review on Amazon:

Like some other reviewers, my Pro Micro seemed to be losing the sketch when disconnected from power. However, I've now figured out that the Pro Micro isn't actually losing the sketch, there is a different problem altogether. When the Pro Micro is reconnected to power, for some reason the bootloader isn't running the sketch. If you then do a soft-reset by connecting the RST pin to ground, upon reset the bootloader starts running the sketch successfully.

So the issue can be worked around by wiring a button to the RST pin and hitting the button every time you plug in the Pro Micro so that it will reset and run the sketch. It's annoying that the issue exists, but at least it's workable.

1. Can anyone explain this phenomena?
2. Might there be another workaround that is an automated solution-- versus pushing a button each time?
• A question like this should really be supported by your software, or a minimal test case which demonstrates the issue, as it is quite likely that the problem is not loss of the program per se, but some condition the software requires. Have you tried connecting and disconnecting the USB, without programming? Does the issue occur if you power cycle right after programming, or only when you let it sit for days? – Chris Stratton Aug 29 '16 at 14:47
• Your comments are definitely something to consider. I will try them out and get back about what I find. Thanks. – raddevus Aug 29 '16 at 15:05
• @daylight please consider editing your title to better fit the situation you actually have. – user2943160 Aug 31 '16 at 3:03

Can anyone explain this phenomena?

Yes, the bootloader installed simply waits for a new sketch indefinitely, without timing out and entering the existing one after a certain period.

Might there be another workaround that is an automated solution-- versus pushing a button each time?

Install a new bootloader. I have a sketch described on my page about burning bootloaders which installs the Leonardo bootloader. I think the Pro Micro bootloader is similar or identical (it is the same chip after all).

You just need a second board (your other Micro would do) to use for the programming. Wiring for a Leonardo is described on my page - however see below for the Micro. The code is at Arduino sketches on GitHub - in particular in the "Atmega_Board_Programmer" directory.

You need to connect together the two boards as follows:

SCK  <--> SCK  (pin labelled 15 on the Pro Micro board) *
MISO <--> MISO (pin labelled 14 on the Pro Micro board)
MOSI <--> MOSI (pin labelled 16 on the Pro Micro board)
VCC  <--> VCC
Gnd  <--> Gnd
D10  <--> Reset (pin labelled 10 on the programming board to Reset on the
board to be programmed)


* As far as I can tell from your photo and the schematic

Possibly (probably) after installing the bootloader the board will identify itself to your PC as a Leonardo and not a Micro, but that doesn't matter since it is the same underlying chip.

• This is a great definitive answer. I also checked out your site and it is very nice and helpful. I believe this is the answer but I haven't been able to wire everything up yet. Tonight I will try it and if flashing the new bootloader works I will mark this as the answer. Thanks – raddevus Aug 30 '16 at 12:46
• I am now going to mark this as the answer, because you were correct and I needed to flash a new bootloader to my knock-off boards. That was the answer I needed so I could know what direction to go in. Thanks very much. My solution was slightly different because I have a usbasp programmer, so i will add an answer with those details for anyone else who has this issue. So great to have a fantastic site like this to get direction. – raddevus Aug 31 '16 at 0:18

Well, the atmega MCUs are flash-based, so they should never 'lose the program' without an explicit erase cycle. However, it's possible something is preventing the chip from starting your program. Have you tried reading out the program stored on the chip after power-cycling the board and comparing it to the original? If it matches, this will rule out the program getting 'lost'. That leaves a couple of possibilities. One is a problem with the reset circuitry that prevents the chip from exiting reset until the USB cable is connected and the programming software is started. Another possible problem is that the chip has a bad bootloader installed on it that doesn't automatically start the user code. That could be a pretty simple fix, just flash the correct bootloader using an ISP programmer or another board that's configured to act as an ISP programmer. Another possibility is the chip itself is a knockoff...in which case all bets are off.

• These are all good things to consider. I will take each one and try them out. You have provided some valuable things to think about and try. Really appreciate it. Could be bootloader failing to start program after it has lost power. That's a good one. Thanks again. – raddevus Aug 29 '16 at 15:04
• I just found another person mentioning losing the sketch. With the info I added to the bottom of my question, does it indicate a more specific answer? Thanks. – raddevus Aug 29 '16 at 15:43
• Is the brown out detector enabled in the fuse bits? It's possible that the chip is not performing the power on reset correctly due to, say, a slow power supply ramp-up. Enabling the brown out detector with a reasonable threshold may correct the issue by ensuring the chip only tries to come out of reset once the voltage is high enough. – alex.forencich Aug 29 '16 at 15:48
• Also, have you tried resetting the board to see if that causes your program to start? If it does, then that rules out the program memory and the bootloader as possible causes. – alex.forencich Aug 29 '16 at 15:52

I have a usbasp programmer so after I read @nick-gammon's great answer and it sounded like I just needed to flash a new bootloader onto my knock-off boards I wanted to try it.

I did not exactly know what I needed to do, so I decided I must go and do it quickly.

At first I browsed around @nick-gammon's great web site and I found the leonardo bootloader, but I could tell it wasn't a straight up .hex file so when I tried it and got an error I figured it wasn't going to work for my setup.

Hardware Setup

First of all I have a 10 pin connector on my usbasp programmer which looks like the following:

Here's what my hardware wiring looks like on the knock-off board. It's an ugly picture but I've labeled it at least.

A couple of things to note are that @nick-gammon mentioned that D10 would be the reset, but in my case it is not. Instead you can see that my reset line was connected to the RST pin on the board which is just above the VCC. And yes the colors on the wires are extremely confusing for the VCC and the RST but the labels are correct.

Getting the Bootloader Hex File As I had mentioned in my original question, I was wanting to get these knock-off boards to work just like my original (more expensive) SparkFun Pro Micro. I checked out the sparkfun site and they provide the bootloader that they used. That's very nice and I got lucky I could get it. You can get it at: https://www.sparkfun.com/products/12640 and then click the Arduino Addon Files link. You'll get a zip file and then you can unzip it and look in the \sparkfun\avr\bootloaders\caterina\ folder and you'll find a .hex file named: caterina-promicro16.hex. I was totally guessing that this would be the bootloader file.

It looks like:

After all of that, I went to the command line and fired up AVRDude. I gave it the following command (making sure you have the caterina-promicro16.hex file available in the same directory, of course).

avrdude -c usbasp -p m32u4 -U flash:w:Caterina-promicro16.hex


If everything is wired correctly then you'll see the following as the bootloader is flashed into your ATMega32u4.

When I saw all of that I was psyched! But, I still couldn't be sure that this was going to solve my problem. To do that I had to open up Arduino IDE and flash in my original program.

I went ahead and did that and tested the program. It worked.

Unplug and Try Again

After that, I needed to unplug the knock-off board and see if it would lose the program -- or actually if it would just loaded it as it should. I tried it and it worked great so I unplugged it a few times and it worked every time. My program is always running now as I hoped it would be.

Also, I bought 5 of these knock-off boards and I'm bootloading them -- two done so far and both work fantastically.

Thanks for all your help @nick-gammon.

• Glad it worked. I hope those wires are soldered to the pins and not just touching them. :) Nick Gammon mentioned that D10 would be the reset - you misunderstood that bit. D10 on the programming board connects to Reset on the target board - so by driving D10 low the programmer resets the target board. – Nick Gammon Aug 31 '16 at 3:06
• I found the leonardo bootloader, but I could tell it wasn't a straight up .hex file - the bootloaders are in the IDE download. Look in the "bootloaders" folder. In the "caterina" folder is a file Leonardo-prod-firmware-2012-12-10.hex - that is the Leonardo bootloader .hex file. For the Micro it would be Micro-prod-firmware-2012-12-10.hex. – Nick Gammon Aug 31 '16 at 3:10
• You are correct I was confused on the D10 reset thing. Also, those wires were not soldered. I have 5 of the boards to bootload and since it's a one-time thing, well... :) Thanks for explaining the other part with the bootloader files. Again, thanks for everything. Without your help I never would've been able to get to a solution like this. These knock-offs are only $4 and the original Pro Micro was$20. :) – raddevus Aug 31 '16 at 4:18