Can't burn pro mini bootloader: mismatch at byte 0x0000

Development Tools Uploading
1

Good day community,
I came here because recently my arduino pro mini stoped working and I can't get it working again.
At first I tried uploading the blink program, but it does not work.

So I decided to burn the bootloader again on the pro mini, using an arduino UNO (original arduino uno) as an ISP programmer, doing the connections as listed:

UNO | PRO MINI
5V--------------Vcc
GND------------GND
13--------------13
12--------------12
11---------------11
10--------------RST

The arduino pro mini is a 5V 16Mhz clone.

After clicking the burn bootloader on arduino IDE i get the following error:

***failed;  
avrdude: verification error, first mismatch at byte 0x0000
        0xde != 0xda
avrdude: verification error; content mismatch
Error quemando bootloader

Does anyone know what this error means?
Is it possible to burn the bootloader into the pro mini in other way?

Thanks in advance
Lucas

Screenshot.png
Screenshot.png1311×673 56.3 KB

2

here's the tutorial https://www.arduino.cc/en/Tutorial/ArduinoISP

I have done Uno to Uno never Pro Mini but I don't see why that wouldn't work.

.

3

Thanks for the repply ieee488, I have made the connections indicated in that page to burn the bootloader of the pro mini but it can't complete the bootloader transfer, i would say that it never starts the bootloader transfer because the TX and RX leds of the arduino uno only blinks a few times (like 0.2 sg or so).
Is there any difference if I try to do it using the ICSP connector insted of connecting the SPI wires to the pins 11, 12 and 13 of the arduino uno?

4

Enable verbose upload, and try again, and post the output - without verbose upload enabled, some very helpful information is omitted.

5

Thank you DrAzzy, I dind't realize there was a detailed log of every upload with the verbose upload.
Here is what the IDE says when I try to upload, of course I cheked the connections and they are all ok.

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Lucas\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

         Using Port                    : COM3
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000 (retrying)

Error quemando bootloader
Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.
6

What does it mean to have an invalid device signature? (0x000000)
How can I fix this problem?

Thank you

7

Check all your wiring. On mine, not having pin 10 of the "Arduino as ISP" connected to the target Arduino Reset will cause that failure.

8

I have triple checked all the wiring kprims, it isn't a wiring problem, what else could it be?
Is there any simple test that I can do to make shure the arduino pro mini isn't broken? It can't receive the bootloader by ISP or any program through RX and TX pins

9

I have triple checked all the wiring

Checked each wire for continuity? Did you change fuse bits other than trying to burn the bootloader using the Arduino IDE?

A bad/loose crystal will also cause this, "avrdude: Device signature = 0x000000".

Do you have another Arduino you could burn the bootloader on, just to make sure your test setup is working correctly?

Is there any simple test that I can do to make shure the arduino pro mini isn't broken?

These are simple tests. You can post pictures of your wiring and show you have good connections. Some people just poke the wires in the holes of the Pro Mini and expect things to work, and they do sometimes. :slight_smile:

10

I have followed your recommendations kprims, and i got this results:

  1. I checked all wires for continuity and they are all ok
  2. I connected the pro mini on a breadboard, connecting +5 and GND from the arduino uno. Then I did the connections of the SPI (pins 13, 12 and 11), and the reset pin going from the pin 10 of the uno to the RST pin of the pro mini. I put a 10k pull-up resistor too.
  3. Then I burned the bootloader.

I got a more detailed description of the burning process, here it is:

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Lucas\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

         Using Port                    : COM3
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xFD"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFD:
avrdude: load data efuse data from input file 0xFD:
avrdude: input file 0xFD contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xDA"
avrdude: writing hfuse (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.11s

Error quemando bootloader
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDA:
avrdude: load data hfuse data from input file 0xDA:
avrdude: input file 0xDA contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xde != 0xda
avrdude: verification error; content mismatch

avrdude done.  Thank you.
11

kprims:
Checked each wire for continuity? Did you change fuse bits other than trying to burn the bootloader using the Arduino IDE?

I tried to burn the "Arduino Pro or Pro Mini" bootloader several times, but i didn't use a personal setup on "boards.txt" or something similar.

kprims:
A bad/loose crystal will also cause this, "avrdude: Device signature = 0x000000".

Maybe is a failure in the crystal, I dont know.

kprims:
Do you have another Arduino you could burn the bootloader on, just to make sure your test setup is working correctly?

Unfurtunately I don't have another arduino pro mini, I only have another standalone atmega 328p

12

The pro Mini can be bootloaded as a UNO. Would you be willing to try selecting Board/Arduino Genuino Uno, and then Burn Bootloader? Let's see if you can get a successful burn that way. You are real close to getting it to work.

13

Today I had some time to try to burn the UNO bootloader on a PRO MINI, I got an error again, the full log is in the .txt file attachment (since the forum won't accept a repply of more than 9000 characters I can't put it here), the ending part of the log is:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7e00
         0xff != 0x11
Error quemando bootloader
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Do I need a high voltage programmer to solve the problem? Or the pro mini is definitly broken?

Error burning UNO bootloader on PRO MINI.txt (9.11 KB)

14

Do I need a high voltage programmer to solve the problem? Or the pro mini is definitly broken?

I have never used a high voltage programmer. In this case your fuses seem to be set the same as mine and I am able to burn bootloader with no problems. I would replace the pro mini for now and come back to the original later on.

Maybe someone else can spot something we have missed.

15

I know this thread hasn't been active for a while, but having waded through countless related posts today, I was a little loath to start another one.

Basically, I am having the subject problem with my 3.3V 8MHz Pro Minis (they are of the Chinese variety). I have had the same issue with two processors (so far). I have been reading various posts, and following the suggestions therein all day without success. The problem started off as the “avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00” problem discribed elsewhere but has ended up with my seemingly having hosed the bootloader.

Suffice to say that I have tried two different 3.3V 8MHz Pro Minis, each with four different USB loaders (two SLAB varieties, another that identifies itself as A5XK3RJT, and an IDUINO UNO set up in ISP mode, with or without processor installed), using both IDE 1.8.5 (because one post suggested that this might fix the problem) and the most recent 1.8.10, on Mac OS X 10.11.6 and 10.14.5, and a whole range of different board options (including the 5V 16MHz Pro Mini, again because some posts suggested this might solve my problem), but all of these give the same result—the sync problem first up, and then when I tried to burn a new bootloader, the present problem.

I have tried loading a new bootloader using the ‘Arduino as ISP’ configuration, using the IDUINO UNO, on two separate Pro Minis (I have two more to play with, but I don’t really want to get them into the same state without a fix), with the same result—bascially the burn process fails, and now I'm left with two processors, seemingly without bootloaders...

The Pro Minis seem to be OK as delivered—they appear to be running the ‘Blink’ sketch when powered on, and they remain running the ‘Blink’ sketch (the original sync problem has meant that I am unable to load any other sketch over this) until I clobber the bootloader, when I end up where I now find myself.

The error log from typical burn processes are attached (too large to include in-line), but the typical failure message is as follows (this is the log from the attempt to burn the Pro Mini bootloader, but it's almost identical if I try the UNO (Optiboot) version):

Writing | ################################################## | 100% 0.00s

avrdude: 32652 bytes of flash written
avrdude: verifying flash memory against /Applications/Arduino.app/Contents/Java/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude: load data flash data from input file /Applications/Arduino.app/Contents/Java/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex:
avrdude: input file /Applications/Arduino.app/Contents/Java/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex contains 32652 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7800
         0x00 != 0x0c
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Error while burning bootloader.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Photo also attached (I hope—there was a message at one point suggesting that there may have been a problem uploading it, and the preview doesn't seem to show whether or not it's actually there), just in case that triggers anything with anyone.

There is plenty of promising LED flashing (on both the UNO and Pro Mini) during the attempt to burn the bootloader, and the log messages would appear to confirm that all the 'communications lines' are open, but there is clearly a problem somewhere in the verification process.

It seems that quite often discussion leads to a solution, even if not directly, so any help would be appreciated, especially if it applies to experience with 3.3V 8MHz Chinese Pro Mini clones.

191110 Mini Log File.txt (9.58 KB)

191110 Uno Log File.txt (9.49 KB)

16

Stop Press!

I've managed to burn the bootloader with the UNO 'Arduino as ISP' configuration by simply pressing the reset button before selecting 'Tools -> Burn Bootloader' and holding it down until the process is complete.

And, if it's of interest to anyone, sketches now load as they should using the USB loaders mentioned in my original post.

So here's a summary of the process I followed, because I found it difficult, reading endless threads, to sometimes work out exactly where people started and where they ended.

My original problem was that I couldn't load a sketch onto a 3.3V 8MHz Arduion Pro Mini (Chinese clone), with a sync error message as described here.

I then tried to burn a new bootloader using an Arduino UNO (IDUINO) as ISP, as described here and in many other posts (noting that all the time I was making the appropriate changes to reflect the fact that I was using a 3.3V 8MHz Mini—taking 3.3V, rather than 5V, from the UNO and selecting the 3.3V 8MHz board option in the IDE). Now, on this occasion, I didn't configure in the 10uF capacitor as recommended in various posts because I didn't think it was necessary on a UNO (but apparently it is). This process failed as described in the present thread.

I added the 10uF capacitor into the configuration, as illustrated here, with no effect.

Then, for whatever reason and using the 'Arduino as ISP' configuration described in the previous paragraphs (including the 10uF capacitor), I pressed the Reset button on the Pro Mini while executing the 'Tools -> Burn Bootloader' command (and kept it pressed throughout the burn process—I'm not sure how long you actually have to keep it held down, but I did note that if I released it at various points before the process was complete, the burn failed), with the 'Ardunio Pro or Pro Mini' board option selected in the IDE, and everything suddenly worked as expected—the burn was successful and thereafter I was able to load sketches onto the Pro Mini using one of my USB loaders.

Note that, in my case at least, the burn fails, with or without holding down the reset button, if the 10uF capacitor is not included in the configuration as described.

So, the essence of the above is that in my case at least:

  1. The 10uF capacitor MUST be configured;
  2. The Pro Mini Reset button MUST be held down throughout the burn process.

To date I've not been able to successfully burn the Optiboot (UNO) bootloader, but I'll leave that for another day.

17

When using an arduino as isp, other than one using the 32u4 MCU, the 10uF capacitor is required to prevent the MCU from being reset when starting an upload.

The MCU being programmed, with the isp programmer, must have it's reset pin held low during the entire uploading process. That will happen if you hold the reset button down.

However, holding the reset low is the function of connecting pin 10 (on an UNO as isp programmer) to the reset of the MCU being programmed. If you have a cap inline with the reset pin it will not work. I suggest you check that the reset connection is a direct one between the reset pin on the MCU and pin 10 (if using an UNO). Also check the value of any onboard pull-up resistor connected to the reset pin (if it has one), if too low it may prevent the isp programmer from holding the reset low.

Willem.

18

I can't really tell if there's a cap inline with the reset pin on the MCU... There does appear to be one immediately adjacent to the RST pin on the PCB, and it does appear to be connected to that pin (simple resistance check), but I'm afraid I don't have the wherewithal to check how that's actually connected to the MCU, nor can I tell if there's an onboard pull-up resistor.

But thanks for the explanation. At least now I have a better understanding of why things are behaving the way they are.