Arduino: 1.6.7 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
Sketch uses 1,066 bytes (3%) of program storage space. Maximum is 30,720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2,039 bytes for local variables. Maximum is 2,048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xc3
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xc3
Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.
I'm aligning DTR>DTR, TXO>RX, RXI>TX, VCC>VCC, GND>CTS, GND>GND. If these connections are correct, then may be I have a loose connection?
=========================================
More Info: The Pro Mini seems to come with a Blink sketch pre-installed. Does that eliminate the possibility of missing bootloader?
Well go ahead and get the header soldered for the FTDI connection. It is common to put your choice of a straight or right angle male header soldered on the Pro Mini, and a female header soldered on the FTDI adapter. Then you can connect them and get a reliable connection. Don't bother with unreliable and unsoldered connections, that is not worth the hassle.
You can verify whether you have a 3V3 Pro Mini or 5V Pro Mini by connecting a 6 to 12 V power source to the RAW and GND pins, then measure with a multimeter the voltage on the VCC pin.
Tried the reset button trick. It's not working. One thing I noticed in the log: Overriding Baud Rate: 57600. Is this correct for a 3.3V/8MHz Pro Mini?
Log:
Arduino: 1.6.7 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
[redacted due to post size limit]
Sketch uses 2,274 bytes (7%) of program storage space. Maximum is 30,720 bytes.
Global variables use 182 bytes (8%) of dynamic memory, leaving 1,866 bytes for local variables. Maximum is 2,048 bytes.
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM4 -b57600 -D -Uflash:w:C:\Users\user\AppData\Local\Temp\build66d3f84c0e9f88f9ac76f0a1444b8464.tmp/Blink2.ino.hex:i
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM4
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x6d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x6d
avrdude done. Thank you.
Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
Ok I just fixed my issue, and hopefully someone else's.
My arduino's (or possibly my solder job on the header?) RXI pin on the 6pin header side was not connected to the same pin as the RXI on the other side of the board. It seems that there was no connectivity to that pin to anything else on the board.
I solved my problem by jumping my dead RXI pin (on the 6pin side) to the other RXI in to achieve full connectivity.
Kyle
and also this:
Hi all,
I had the same problem with my Arduino Mini Pro 8MHz/3.3v and found my/the answer.
The key is the bootloader that is on the Mini Pro:
If the default pattern of the led is (_ = off, * = on) : **__**** (simple slow pace blinking) ... you must choose in the Arduino software "Board = Arduino Mini Pro" (my first Mini Pro was like that and working)
**** BUT ****
if the pattern is *_____*_***** (like a drum rolling faster) you must choose "Board = Arduino Duemillanove w/ ATMega 328" ! And it started working just fine !
It took me a few hours to desperately try that, and it worked just fine I think the key is that the "older" generation came with a old bootloader with a specific signature, but the new ones come with another signature that match the Duemillanove 328.
Hope this helps. At least it saved me from throwing my 3 Mini Pro to the bin! And no need for any kind of rewiring the FTDI connector, the Sparfun 3.3v works just fine it you plug it the right way (not upside down).
Cheers,
Alan.
...in the same link.
I have a feeling that the second trick is gonna work. Good luck!
Srijal97:
There is this:
and also this:
...in the same link.
I have a feeling that the second trick is gonna work. Good luck!
The second trick doesn't seem to be applicable in my case. In my case, the default blink sketch seems to go like this: ----, where * is high for 1 second, and - is low for 0.5 second. Please see video 1 to get an idea. In this case (video 1), I used jumper cables to get better control of connections. Then I disconnected the TX, RX pins, and the behavior of LED or error codes in IDE didn't change at all. So, it seems it could be one or more of those 4 pins at fault here.
Video 1: https://www.youtube.com/watch?v=v3q2ZaaWiZo
Here are the soldering connections: Imgur: The magic of the Internet. The FTDI came pre-soldered, and I recently soldered the Pro Mini headers. The soldering seems decent to me. However, from my experiment with the TX, RX connections, those connections might be faulty.
In video 2 you can see how the FTDI and Pro Mini behave when I power off and on. The Pro Mini LED flashes a few times, then the Blink sketch resumes.
Video 2: https://www.youtube.com/watch?v=iktRQolNcJA
In video 3, at around 15s you can see the pin13 flashing twice. This is the IDE trying to push my sketch. I think this is where the ProMini gets reset by the FTDI.
Video 3: https://www.youtube.com/watch?v=P44gA4S_CZo
These are just my amateur observations. It's help me a lot if you kindly verify. This is my first arduino project involving any kind of soldering, Pro Mini, FTDI, etc. In fact, the only thing I've done before is Blink on Uno.
Anything else I can try before taking it back to vendor? Also, let me know if you would like to see something else. I can make more videos.
srk999:
These are just my amateur observations. It's help me a lot if you kindly verify. This is my first arduino project involving any kind of soldering, Pro Mini, FTDI, etc. In fact, the only thing I've done before is Blink on Uno.
Anything else I can try before taking it back to vendor? Also, let me know if you would like to see something else. I can make more videos.
If you edit your posts, and use the link button to turn your links into clickable links, it would help a lot. Without clickable links, it is really hard on some browsers to select and copy the text and paste in a browser window, such as on a mobile phone or tablet.
Yes, 57600 is the standard baud rate for 8MHz and 16MHz Pro Mini. You can find the boards.txt file that is part of your IDE installation and have a look at it, and it contains the settings used for each board type.
It is good you checked by observing the blink pattern that the ProMini gets reset by the FTDI. That means your problem is not with the auto reset circuit.
I think for a recently purchased Pro Mini, it is likely to have a good bootloader on it and just work if the right board is selected in the IDE.
My suspicion is on the FTDI adapter, because unless purchased from a reputable dealer such as SparkFun or Adafruit, it is very likely to have a counterfeit FTDI chip. Huge number of those sold on Amazon, eBay, and other online sources have counterfeit FTDI chip. It seems people with non-Windows computers are not having problems, but Windows drivers for FTDI have countermeasures that keep the counterfeit chips from working for Arduino uploads. You can disconnect the Pro Mini and connect just the FTDI adapter with the USB cable to your computer. Connect the RX and TX pins together on the FTDI adapter. Select the correct port of the FTDI adapter in the IDE. Click the Serial Monitor button. Type a sentence or two into the Serial Monitor and send, and verify your text comes back as a response. There was another recent post where a user revealed that during the loop back test the driver introduced extra text in the serial stream. The serial monitor displayed "NON GENUINE DEVICE FOUND!" That would mess up a program upload/verification. So, I recommend checking that out.
dmjlambert:
If you edit your posts, and use the link button to turn your links into clickable links, it would help a lot. Without clickable links, it is really hard on some browsers to select and copy the text and paste in a browser window, such as on a mobile phone or tablet.
Yes, 57600 is the standard baud rate for 8MHz and 16MHz Pro Mini. You can find the boards.txt file that is part of your IDE installation and have a look at it, and it contains the settings used for each board type.
It is good you checked by observing the blink pattern that the ProMini gets reset by the FTDI. That means your problem is not with the auto reset circuit.
I think for a recently purchased Pro Mini, it is likely to have a good bootloader on it and just work if the right board is selected in the IDE.
My suspicion is on the FTDI adapter, because unless purchased from a reputable dealer such as SparkFun or Adafruit, it is very likely to have a counterfeit FTDI chip. Huge number of those sold on Amazon, eBay, and other online sources have counterfeit FTDI chip. It seems people with non-Windows computers are not having problems, but Windows drivers for FTDI have countermeasures that keep the counterfeit chips from working for Arduino uploads. You can disconnect the Pro Mini and connect just the FTDI adapter with the USB cable to your computer. Connect the RX and TX pins together on the FTDI adapter. Select the correct port of the FTDI adapter in the IDE. Click the Serial Monitor button. Type a sentence or two into the Serial Monitor and send, and verify your text comes back as a response. There was another recent post where a user revealed that during the loop back test the driver introduced extra text in the serial stream. The serial monitor displayed "NON GENUINE DEVICE FOUND!" That would mess up a program upload/verification. So, I recommend checking that out.
Then I fired up the IDE, and kept the settings for 3.3V Pro Mini. Then opened the Serial Monitor. The Baud Rate in Serial Monitor was 9600, and left that alone. Then entered "Hello World!" into the text box and pressed Send. It appeared in the window below. Repeated it a few times with loads of text. Works the same.
So, it seems the FTDI is working as expected. That leaves the RX-TX in the Pro Mini, right?
There is no automatic linkifying, although that would be a nice feature.
Yes, I agree with you, that leaves the RX-TX connection being one of the only problems left. I have seen on the forum people showing photos of FDTI adapters that have incorrect markings of the pins. So, you could try swapping the RX and TX pins, so you connect TX on the FTDI to TX on the Pro Mini, and Connect RX on the FTDI to RX on the Pro Mini.
Another thing to try is the Uno board selection. If somebody has loaded the Pro Mini 16MHz bootloader on a Pro Mini 8MHz board, or if the board was accidentally outfitted with a 16MHz crystal, it would make the bootloader listen at 115200 baud, and that is the baud rate of the Uno.
I am surprised at what you have found so far, and how difficult getting this going has been.
If you have another working Arduino you can use it as an ISP programmer, and burn a fresh bootloader on the Pro Mini. That way there will be less mystery and more just knowing what bootloader it has on it.
yes, it seems like the ftdi is not the problem. Did you try selecting "Arduino Deumilanove" as board while uploading? Try some Atmega328 bards as well like the Uno and Nano.
Also try uploading with the DTR pin from ftdi plugged to the RST(reset) pin on the pro mini. If that doesnt work, try interchanging Tx and Rx pins.
I suggest you get another pro mini, if possible, to see if yours is faulty.
dmjlambert:
There is no automatic linkifying, although that would be a nice feature.
Yes, I agree with you, that leaves the RX-TX connection being one of the only problems left. I have seen on the forum people showing photos of FDTI adapters that have incorrect markings of the pins. So, you could try swapping the RX and TX pins, so you connect TX on the FTDI to TX on the Pro Mini, and Connect RX on the FTDI to RX on the Pro Mini.
Another thing to try is the Uno board selection. If somebody has loaded the Pro Mini 16MHz bootloader on a Pro Mini 8MHz board, or if the board was accidentally outfitted with a 16MHz crystal, it would make the bootloader listen at 115200 baud, and that is the baud rate of the Uno.
I am surprised at what you have found so far, and how difficult getting this going has been.
If you have another working Arduino you can use it as an ISP programmer, and burn a fresh bootloader on the Pro Mini. That way there will be less mystery and more just knowing what bootloader it has on it.
Tried swapping the RX-TX connections. Same result.
Tried changing board to Uno, and 5V Pro Mini. Both with aligned and crossed RX-TX. Same result.
I do have an Uno, and planning to reburn the bootloader. Do these seem like good guides to you? 123 Which one should I follow?
Srijal97:
yes, it seems like the ftdi is not the problem. Did you try selecting "Arduino Deumilanove" as board while uploading? Try some Atmega328 bards as well like the Uno and Nano.
Also try uploading with the DTR pin from ftdi plugged to the RST(reset) pin on the pro mini. If that doesnt work, try interchanging Tx and Rx pins.
I suggest you get another pro mini, if possible, to see if yours is faulty.
Tried changing board to Deumilanove, Uno, Nano. Same result.
Connecting FTDI's DTR to Mini's RST has the same effect as holding down the reset button on Mini.
I'll get another mini if reburning bootloader fails.
One thing I noticed, the FTDI connects to COM4, but the Uno connects to COM3, even though I am using the same USB port.
srk999:
One thing I noticed, the FTDI connects to COM4, but the Uno connects to COM3, even though I am using the same USB port.
I think that is OK.
Burning bootloader using Uno as ISP:
Upload onto the Uno the sketch from the Examples menu: ArdunioISP
Disconnect USB cable
Connect a 10uF or larger capacitor to Uno with striped or neg lead on GND and positive lead on Reset. This will prevent the Uno from resetting when the IDE connects to it via serial to use the Uno as a programmer.
Connect from Uno to Pro Mini:
Uno Pro Mini
5V VCC
GND GND
10 RST
11 11
12 12
13 13
Reconnect USB cable to Uno
On the Tools, Board and Processor menus select Pro Mini 3.3V 8MHz.
On the Tools, Programmer menu select "Arduino as ISP"
On the Tools, Port menu the Uno's port.
On the Tools menu select Burn Bootloader
You should get a Done Burning Bootloader message at the bottom of the IDE window after a few seconds to a minute.
If you do, disconnect all wiring. Try FTDI upload again.
Note, it is OK to power the Pro Mini with 5V on the VCC lead when programming with ISP or during FTDI upload. You can also have a look at that jumper on the FTDI adapter and see if it is on the 5V setting. That is one more thing to try...
Upload onto the Uno the sketch from the Examples menu: ArdunioISP
Disconnect USB cable
Connect a 10uF or larger capacitor to Uno with striped or neg lead on GND and positive lead on Reset. This will prevent the Uno from resetting when the IDE connects to it via serial to use the Uno as a programmer.
Connect from Uno to Pro Mini:
Uno Pro Mini
5V VCC
GND GND
10 RST
11 11
12 12
13 13
Reconnect USB cable to Uno
On the Tools, Board and Processor menus select Pro Mini 3.3V 8MHz.
On the Tools, Programmer menu select "Arduino as ISP"
On the Tools, Port menu the Uno's port.
On the Tools menu select Burn Bootloader
You should get a Done Burning Bootloader message at the bottom of the IDE window after a few seconds to a minute.
If you do, disconnect all wiring. Try FTDI upload again.
Note, it is OK to power the Pro Mini with 5V on the VCC lead when programming with ISP or during FTDI upload. You can also have a look at that jumper on the FTDI adapter and see if it is on the 5V setting. That is one more thing to try...
That worked! I had to forego the capacitor since the max I have is 0.1uF, but it still worked.
Burned the bootloader following your instructions, and voila, sketches are uploading as easily as with Uno.
Thank you, and everyone else here for helping me out. This is one of the best community I've been a part of.
That is great news! I don't know exactly what the deal is on disabling auto reset of the programmer Arduino. I have found sometimes I don't need it. Perhaps in the latest version of the ArduinoISP sketch it is no longer necessary to disable auto reset.
I wonder why your Pro Mini came with a bad bootloader.
After trying a number of fixes for this problem, I finally found the easiest one! You don't need to upload bootloaders to fix it.
I had the same problem uploading sketches to Arduino Pro Mini 3v3 8MHz using a CH340G USB-to-Serial converter. The root of the problem is that the DTR pin of the CH340G chip is not connected to the DTR pin of the Arduino. If your USB-to-Serial module has this pin, you just have to connect it to the same pin on the Arduino.
But some of the USB-to-Serial modules (including mine) do not have this pin. If this is the case, all you need to do is to press and hold the reset button after clicking on the "upload to board" button, during the compilation process, and releasing it after seeing the "uploading to board" message.
skepticmind:
After trying a number of fixes for this problem, I finally found the easiest one! You don't need to upload bootloaders to fix it.
I had the same problem uploading sketches to Arduino Pro Mini 3v3 8MHz using a CH340G USB-to-Serial converter. The root of the problem is that the DTR pin of the CH340G chip is not connected to the DTR pin of the Arduino. If your USB-to-Serial module has this pin, you just have to connect it to the same pin on the Arduino.
But some of the USB-to-Serial modules (including mine) do not have this pin. If this is the case, all you need to do is to press and hold the reset button after clicking on the "upload to board" button, during the compilation process, and releasing it after seeing the "uploading to board" message.
Good Luck!
Well, that is a late reply!
Arduino does not have a DTR pin, you should connect the DTR to reset through a 0.1uF capacitor. That should make it work.
I think the key is that the "older" generation came with a old bootloader with a specific signature, but the new ones come with another signature that match the Duemillanove 328.
