4 versions of Pro Mini fail to program (SOLVED: duh)

I’ve been programming Pro Minis for a smart home application for about a year, using IDE 1.0.5. I’ve been off on other things for a couple months and now I can’t upload sketches. The error(s) is:

programmer not responding” then
no sync” 10 times until the upload cycles out

I’ve done a loopback test on the programmer and the USB/UART connection works fine through the serial monitor. Nothing but the 5-wire interface is connected to the Mini boards, so the RXTX connection is not being corrupted by other signals.

I have tried all 4 versions (different physical PCBs) of my Mini’s and they all fail.

When the IDE first attempts to do the upload, I see three quick blinks on the TXD LED on the programmer, then periodically one blink as it cycles through its ten attempts.

The failure is identical under Linux 17.1 and Windows 8.1 and using IDE 1.0.5, 1.6.3, and 1.6.4. I was using the Linux machine almost exclusively because of the huge issue last fall about the FTDI chip on the Nano. It was totally reliable uploading to the Mini’s, and then it just quit.


Do you have DTR connected?

If you've tried 4 versions and none of them work, that suggests the problem is with what you're doing.
Are you connecting the connector the right way around?
Are the pro-mini's bootloaded properly? Test: If you briefly short RST to ground (or press reset button, if they have one), you should see the bootloader flash the led a few times)
Have you tried a different serial adapter (like a CH340G based one)?

I would hope he has DTR connected... And he says he's got 4 different pro mini's all not working. A few batches with the DTR reset cap positioned incorrectly exist, but not many.

Isaac: yes, DTR is connected. It's the same programmer and cable that was working the last time I uploaded.

Azzy: I'm sure you're right. There is something on my end that I'm screwing up--you can't have this many failures and not have some common mode problem that ought to be obvious.

When I press the reset button, I don't see any series of flashes. All 4 versions of the chips seem to have the blink sketch loaded and that's all I see--a periodic approximate 1 second flash of the pin 13 LED. The Mini doesn't have Rx or Tx LEDs, so you can't monitor comm except at the programmer. But the programmer doesn't have a DTR led, so that pin is a mystery.

I've done the loopback test at the programmer pins and at the other end of the 5-wire cable, all good. I've switched programmers. I've swtiched Mini's, not just another Mini, but another vendor's. I've switched IDEs. I've moved from Linux to Windows. On the Windows machine, the ports show a 210X (com3) port available.

I'm using the 5V version of the Mini, so there is no confusion with using the 3.3V pin on the programmer. The physical order of the programming pins is GND, GND, Vcc, Rx, Tx, DTR. It's the same on all 4 of the 5V versions, except one of them has the pins in reverse order at the end of the board, but they are in order, just reversed.

If I had two brain cells to rub together I could solve this...

Tomorrow I will remove a Mini from a working system and see if it takes an upload.

Does the board reset (does the blink sketch blink differently) when it tries to program them? That would confirm auto-reset was working.

I'd try reburning bootloader, if it is.

Try holding down the reset button when you upload. When the status bar at the bottom of the IDE changes from "Compiling" to "Uploading", release the button.

1 Like

Isaac: Holding reset down and releasing as the IDE enters upload mode didn't work. Tried it several times.

Azzy: I don't really know how to re-burn a bootloader and I'm having trouble imagining how to do it if the programmer can't upload to the Mini.

Also, there is and there isn't a difference in the blink just after releasing the reset button. A couple of the versions just go right back into the blink sketch, the other two alternate between a repetitive blink and a series of 3 blinks with one pause, then 3 more blinks. This pattern continues for some handful of repetitions, then goes into the steady blinking with no missing beats. But it doesn't seem to be related to the short period of time after the reset is released.

The ones with the three blinks are properly bootloaded. Start with those.

OK, I've been through the whole routine again with the Linux machine and using a bare Uno board as the USB to Serial programmer. Same errors, eg, programmer not responding and not in sync. (IDE 1.0.5). The port is "serial" with the drop down window only having a check mark in it.

IDE 1.6.4 doesn't see the Uno board with the chip out and the Mini connected in its place.

The Uno board uploads fine with its chip installed and using IDE 1.0.5.

IDE 1.6.4 sees the Uno as dev/ttyACM1, but will not sync and consequently will not upload.

Are there any clues here?

Please show us exactly how you have things connected. I think we all were assuming you were just plugging in a USB-serial adapter, which would leave no room for incorrect connections

Also, have you tried using a different USB-serial adapter... like, instead of using an uno board with the chip pulled? USB serial adapters with the proper pinout for programming Arduino Pro Mini can be had for $3-4 on ebay (make sure it's got the right pinout), and they plug right into those 6 pins on the end and they solve any question of whether the serial adapter is connected correctly

Since you've addressed everything else that I can think of, I'll ask: What board is selected under Tools > Board?

IDE 1.6.4 doesn't see the Uno board with the chip out and the Mini connected in its place.

I can't visualize that. Can you elaborate?


You're right about the cheap USB-to-Serial adapters, their pinouts are in the correct order, except I ignore the 3.3V pin, since all my Minis are 5V. I do have one Mini where the physical order of the pins is reversed, but they are still "in order," I just have to plug it in upside down.

I'm using a CP2102 USB-serial board, connected this way:

Pgmr Mini
gnd --> gnd
+5 --> +5
TX --> RX
RX --> TX

When I use the Uno board, it's like this:

UNO Mini
gnd --> gnd
+5 --> +5
TX --> TX
RX --> RX
Rst -- > DTR

I tried all 4 versions with the UNO and even had the RX/TX lines reversed a couple of times, but no workie.

For TMD3,

Although I haven't been successful, several posts indicate that if you pull the uP chip from the UNO board, you can use the USB-serial converter on the board to accomplish the same thing as a stand-alone USB to Serial programmer.

The board selected under tools>board is "Arduino Mini" and Processor is "AT328". Oops, I notice that IDE 1.6.4 has a "Pro or Pro Mini" selection, which I have overlooked. More news on this development tomorrow. Damn. I looked "carefully" for this selection and missed it...

Now that I'm next to my own inexpensive Chinese knockoff of a Pro Mini, I find that it's quite finicky about acknowledgement of its professional status. Under IDE 1.5.4 1.6.4 [Edit: fix version number], it fails with "Arduino Mini" selected, and works with "Arduino Pro or Pro Mini."

Using the uno with chip removed as serial, rst goes to rst, not dtr.

Well, this is embarrassing. I have confirmed "finicky." Selecting "Pro or Pro Mini" seems to have solved the problem.

TMD3, you are to be congratulated for asking the obvious, aka, "is it plugged in?" KUDOS to you.

The question this raises in my mind is, how does the bootloader differ between processors/boards? It seems to me that if the only interface to the bootloader (in the Mini, for example) is through the TX, RX, and Reset pins, that uploads should work regardless of the processor selected. The uploaded software, however, might not work because of differing pinout assignments, clock speeds, and internal processor features. That, I could understand.

OK, back to work.

Look at boards.txt - the upload speed is different.

Most people here I think put the Uno bootloader onto thier Pro Mini's, since it takes up less flash and uploads a bit faster.

DrAzzy, thanks. Upload speed! Of course. Changing the bootloader or installing a bootloader is a mystery to me. If this can be done through the serial interface, it seems it would require that a bootloader would have to be present already and if you are uploading a different bootloader, it would be overwriting the one that's doing the uploading...

I'll look into the pin connections a bit more. It seems to me that RST-->DTR is the right connection, only because DTR is the way the serial interface triggers the Mini into the bootloader. I got the wiring logic from an Instructable that I can't seem to find this morning. However, this one also shows the Uno reset pin going to the Mini DTR pin.

I looked at three versions of my Minis. Two of them label the pin as DTR and the other one labels it "GRN". Reset is not broken out on the Mini header. I'm a little vague on how "DTR" interfaces with Reset in order to jump to the bootloader. The "capacitor issue" I've read about implies that there is a very short pulse applied through the DTR pin to Reset. Is this correct?

Thanks for the point out to boards.txt

I'm getting the idea that there is a permanent Flash loader embedded in the Arduinos.

Wow, really? No reset on the pro mini? The ones I've got have a reset pin broken out... TWICE (as does the official one). Look again.

DTR goes low - and stays low - during serial transfer.

RST needs to be briefly pulsed low to reset hte board, then released. So to do this, they have a 0.1uf cap between DTR and RST, capacitatively coupling them, so DTR goes low, and so RST on the other side does too - but very quickly, the pullup returns the the RST line to around VCC.

Bootloaders are programmed using different connections (MISO, MOSI, SCK, and RST) using an ISP programmer. You can use any '328 based arduino with the Arduino as ISP sketch to act as an ISP programmer

Yes, they all have two RESET pins, but I only have one with RESET broken out to a header. It has the full MISO-MOSI six-pin header, plus four additional analog lines to make a 10-pin header, but the reset push button prevents header installation.

Thanks for the insight on how DTR resets the chip. You've really helped me understand the programming interface.