Problem using Arduino Pro Mini as ISP


I'm new to the forum, so nice to meet you!

I'll go to my problem real quick:

I own two Pro Minis and an FTDI-USB interface. I need to program the "slave" Pro Mini (a 3.3v, 8Mhz variant) using the "master" Pro Mini (a 5v, 16Mhz variant) as an ISP.

First thing I did, I uploaded the "ArduinoISP" sketch to the "master" pro mini normally, and it worked. I set all the options correcly, of course (to see if the the FTDI interface worked properly, I tested both pro minis with the "Blink" sketch, and by modifying the delay values, I get a proper response from both Pro Minis).

The I connected the Pro Minis together by soldering the appropriate pins, following this connection:


pin 10 --> RST pin
pin 11 --> pin 11 (should be MOSI)
pin 12 --> pin 12 (should be MISO)
pin 13 --> pin 13 (should be SCK)

The master pro mini is connected to the ftdi serial interface normally, and feeds off the 5V on the vcc pin. Since the FTDI can provide both 3.3v and 5v at the same time, I connected the slave pro mini VCC and other GND pin to the FTDI's 3.3v and GND pins respectively.

Connecting the USB cable, I can see both Pro Minis powering on correctly. I then select the sketch to flash to the slave mini (PsNee v7.1), select the appropriate options, set "Arduino as ISP" on the Programmer option and hit the "Upload with programmer" button (after compiling).

The IDE returns me the following error:

"The selected serial port avrdude: stk500_disable(): unknown response=0x12 does not exist or the board is not connected"

I checked my soldering with a multimeter, but it seems fine.

Does anyone know what I could have done wrong?

Thanks in advance

Put a 10uF capacitor, stripe toward GND, between Reset and GND on the Pro Mini used as "Arduino as ISP".

Ok, thank you. That changed something.

now it gives me this other error:

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

I should also mention that I programmed the "master" Pro Mini (the one used as the ISP) with this uncommented line in the "ArduinoISP" sketch:

// Uncomment following line to use the old Uno style wiring
// (using pin 11, 12 and 13 instead of the SPI header) on Leonardo, Due...



#define PIN_MOSI 11
#define PIN_MISO 12
#define PIN_SCK 13

Reading the code it made sense to uncomment the line, but feel free to tell me if it shouldn't be uncommented.

Ok, tried again, and now I got a different error:

"avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x0c
avrdude: verification error; content mismatch
avrdude: verification error; content mismatch"

I should also mention that I programmed the "master" Pro Mini (the one used as the ISP) with this uncommented line in the "ArduinoISP" sketch:

// Uncomment following line to use the old Uno style wiring
// (using pin 11, 12 and 13 instead of the SPI header) on Leonardo, Due...


You don't have to uncomment the // #define USE_OLD_STYLE_WIRING line.

"avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x0c

Double check your leads and soldering.

You've supplied the 'slave' Mini with 3.3V on the VCC line, but put 5V on the inputs (from the 'master' Mini). This will have damaged the slave Mini.

Unlocked at the request of @davesp

(Thank you to the moderator for unlocking this thread at my request.)

My attempts to use a generic Pro Mini as an ISP programmer weren't working until I removed the LED from the SPI "SCK" line (which is delicate work and isn't recommended unless you have a fine-tipped soldering iron), then the Pro Mini worked for an hour or so as an ISP programmer, then it began failing again.

Adding the 10uF capacitor between the ground and reset lines (as instructed above by @kprims) seems to have resolved the issue.

Why does adding this capacitor resolve the issue?

The process of uploading to the Pro Mini (as well as Uno, Nano, and Mega) boards is:

  • Compile sketch
  • Reset microcontroller to run the bootloader
  • Send compiled sketch to the bootloader over the serial port
  • Bootloader exits
  • Sketch runs

When the bootloader runs, it waits for a short time for an upload to begin. If that doesn't happen, it times out and exits to the sketch. So the timing of the reset and upload need to be pretty close. In the early days of Arduino, the user had to manually reset the board at the start of the upload. This is the origin of the practice of putting a reset button on most boards.

But it's annoying and not beginner friendly to have to press that reset button at just the right time. It's not so easy as pressing as soon as you click the "Upload" button in the Arduino IDE because the sketch is compiled before the upload so the bootloader would have timed out before the actual upload started if you reset it then. It was later discovered that by adding a simple circuit to the Arduino boards, the reset could be automatically triggered by the serial connection opened by the upload process itself!

The problem this presents when using an "Arduino as ISP" is that you aren't uploading to the Arduino board used as a programmer. So if the serial connection being opened at the start of the "Burn Bootloader" or "Upload Using Programmer" causes your Arduino as ISP board to reset, that's a big problem! The fix is to add that capacitor to disable the auto-reset circuit on the board you're using as an "Arduino as ISP".

Where it gets more murky is that most people find that this capacitor is not needed. You yourself found that you could sometimes get by without it. So I think the electrical conditions are such that, unlike during uploads, when using the board as a programmer the auto reset is not triggered consistently by the serial connection. So some boards need the reset disabling capacitor, and others don't.

This is also affected by the software configuration of the avrdude tool used for the Burn Bootloader and Upload Using Programmer processes. A few years back, Arduino changed this configuration to allow the ATmega32U4-based boards (e.g., Leonardo, Micro) to be used as "Arduino as ISP" programmers, but this had a side effect of a large number of people finding that they suddenly couldn't use their Arduino boards as "Arduino as ISP' programmers without this capacitor. In response, Arduino reverted the avrdude configuration change and added a dedicated "Arduino as ISP (ATmega32U4)" programmer with the modified configuration (Add ATmega32U4-compatible Arduino as ISP programmer by per1234 · Pull Request #56 · arduino/ArduinoCore-avr · GitHub).

Ah, interesting point -- the reset. I've been using a micro-USB-to-FTDI interface which I believe asserts a reset via the CTS and/or DTR line. If I take the reset out of the equation (by only allowing Gnd/TxD/Rxd/Pwr), the capacitor does not seem to be needed.

I believe asserts a reset via the CTS and/or DTR line.

You got it. That is connected to the reset pin via a 0.1 uF capacitor. In combination with the pull-up resistor on the reset pin, this forms the "auto-reset" circuit that produces the low pulse on the reset pin needed to reset the microcontroller. This is also why the board resets every time you open the Arduino IDE's Serial Monitor.

It does appear to be a function of the IDE version being used. I'm still on v1.8.8, and I have to add the reset capacitor to whatever Arduino I'm using as an ISP. But it seems that newer IDE versions do not require that, as pert explained.

It's actually a matter of which Arduino AVR Boards platform version you have installed. As I mentioned above, there were some versions of that platform that had a problematic configuration for the "Arduino as ISP" programmer.

The Arduino AVR Boards platform version is loosely coupled to the Arduino IDE version because the Arduino IDE installation comes with a bundled copy of the latest Arduino AVR Boards platform version at the time of the IDE release. But Boards Manager allows you to install any version of Arduino AVR Boards with any version of the Arduino IDE, so it doesn't really make sense to talk about this in relation to Arduino IDE versions.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.