I would like your advice relating to using the Arduino IDE and avrdude to program an ATmega328 which is preloaded with an Arduino bootloader. I am using a USB to TTL-serial breakout board based on an FTDI chip.

I bought a "FTDI Basic Program Downloader USB to TTL FT232 for Arduino ACC" off ebay

I followed exactly this setup:

1. Connect the DTR pin to pin 1 on the ATmega through the 0.1uF capacitor.

2. Connect the RX pin to pin 3 on the ATmega (TX)

3. Connect the TX pin to pin 2 on the ATmega (RX)

4. Connect the 5V pin to the 5V rail of the board to supply the board with power from the USB interface.

5. Connect the GND pin to the GND rail of the board

avrdude: stk500_getsync(): not in sync: resp=0x00

Here's what I have tried so far:

Connecting the header pins of the Arduino "shield" to the chip on the breadboard. In doing so I am using the ATmega16U2 on board to send the program. Result: Flawless! the program boots and everyone is happy.

Back to the FTDI breakout board. Switch RX and TX (never know?) still nothing so switched back to initial TX - RX configuration.

The DTR pin out of the FTDI board is successfully resetting the ATmega328 for sure as it goes through its magical blinking sequence when I try to upload something.

Now, I've tested to see if the ATmega328 can send serial info through the breakout board to by computer. It can.

I've noticed a few interesting things:

Both the TX and RX lines are always at 5 V. I know this because if I connect a LED in parallel with the lines, they light up. But, the little tiny LEDs on the breakout board labeled TX and RX are not always on... why is that? Could that explain my problem?

If you'd like any more info, let me know, I'll get it for you.

---------------------------------------------EDIT------------------------------------------

Hello again,

OK I've added a 100uF electrolytic capacitor along with a 0.1uF one between 5v and GND. This isn't the suggested 47uF and 0.1uF but I guess it`ll help filter out none the less. ( while at it. What would it change?)

I've replaced my 1k pull-up resistor with a 10k one

I still am not able to upload a sketch and get the same error. DTR line calls a reset and I still get serial output. (I have a sketch on it that sends incrementing integers through serial every second)

Also interestingly, (although I was still unable to send a sketch before this happened) any LED I plug on pin 13 (aka 19) is now much dimmer... maybe that utlra bright white LED I had earlier was pulling to much current with a 270 ohm resitor... -_- )

To popular demand here are pictures of my board and the USB to FTDI breakout board I am using.

• TX and RX are generally pulled (or driven) high. I don't think your problem is there... – bitsmack Apr 17 '14 at 5:48
• Any specific reason you went with serial programming instead of ISP? – Ignacio Vazquez-Abrams Apr 17 '14 at 5:54
• To expand on bitsmack's comment: The TX and RX lines will default to high, and briefly pulse low for data. Can be seen on a scope, but not on a meter. You can see it if you connect an LED+resistor from 5V to TX or RX (anode to 5V). The breakout board TX and RX lights are not directly wired to the actual TX/RX wires. – gwideman Apr 17 '14 at 7:34
• Ignacio: I believe the ISP capability of this board is only a stopgap -- I think using bitbang. It's not a proper SPI I/O. Also, programming via the bootloader avoids accidentally programming things that ISP can program that are usually unintended. – gwideman Apr 17 '14 at 7:36
• Anyway add a resistor for those led, they are not going to last long... – Vladimir Cravero Apr 17 '14 at 8:37

Couple of suggestions:

Looking at the picture you appear to be following here:

There is almost certainly an error which will cause Reset not to work as expected.

I think the Reset circuit is supposed to mimic the one in an actual Arduino, which has DTR connected via a 100nF (0.1uF) capacitor to /RESET (pin 1). The actual Arduino (eg: Deumilanove) schematic shows a 10k pullup resistor from pin 1 to +5V. This will force /RESET to become deasserted some brief time after being asserted by DTR going low.

However, on the breadboard in the photo, the 10k resistor is connected to the wrong end of the cap, attaching to DTR. This will have no effect, and means that the /RESET recovery will be only due to the in-built pullup, which is purportedly a higher value like 30 to 60k, and will thus take 3 to 6 times as long to reset, and will be more susceptible to noise.

Moving the 10k resistor pullup to pin 1 may solve the problem outright.

Another thing to check is whether to are actually getting 5V out of the 5V pin on the FTDI adapter. Many of those boards come with jumper headers or unsoldered jumper pads to allow you to wire the "Power out" pin to either 5V or the 3.3V regulator on the FTDI chip.

And add resistors (say 330 to 1k) in series with each of your LEDs to avoid the causing excessive load. The photo appears to show an LED wired directly across 5V-Gnd, and another from Vcc to D13. The first one by all rights should burn out immediately or cause some other havoc. However, it's possible these are LEDs with built-in series resistors.

It would also be good to add parallel 0.1uF and a 47uF capacitors across Gnd and VCC near the 328, to give it a clean supply.

• The LEDs in the higher resolution version of that photo do seem to have resistors soldered to them under red heat-shrink tubing. – RedGrittyBrick Apr 17 '14 at 10:08
• Ah, right, the first photo with the partially-completed breadboard shows that more distinctly. Thanks for pointing that out. Highly misleading for "young players" though! – gwideman Apr 17 '14 at 10:10
• Thanks for the help. I did have resistances for the leds on my board. Ya, sorry for not posting my actual board, had no cameras on me at the time I posted. I didn't even notice the capacitor not being wired up inappropriately on the picture! That said, I initially had a look at the actual arduino schematic so I knew not to put the cap in series with the node connecting the pullup resistor and the cap-DTR, but , I used a 1k pull-up resistor, rather then a 10k. Could that be the problem? Ill test it out. and adding extra caps for GND and VCC. Thanks again. – Ethienne Apr 17 '14 at 17:44
• Please post a sketch of what you actually did, because it's not clear from your verbal description that what you did is workable. – gwideman Apr 17 '14 at 23:19
• Yup, will do the moment I get a bit of free time. if the corrections don't work that is – Ethienne Apr 18 '14 at 0:34

I also came here because my standalone, bootloaded ATmega328 didn't want to load my program and gave that avrdude error. I solved my situation, and would like to share it so maybe it will help others.

What eventually turned out to be the issue was that the ATmega328 chip was not properly 'clicked' in the breadboard. However, when I initially placed the ATmega chip on the breadboard directly, it made a 'click' sound. It really seemed like it was in properly, not loose, couldn't go any deeper, wouldn't fall out when you shake it upside down etc. But when I tried loading a program, I got the avrdude message.

While uploading some pins were flashing, even the LED I hooked up to the pin 19 (pin 13 on Arduino board). I bought the breadboard in the Netherlands, so I can't say if it is Chinese or not, but apparently it also has some deep connectors and difficulty connecting with the pins of DIP chips. Luckily I had a chip socket mount (IC Socket 28 Pin DIP) which I placed between ATmega chip and breadboard. My problem was immediately solved, and the happiness returned.

I used a FTDI basic to program it, almost exactly just like the picture in the link of Gwideman gave above. Only the pull-up resistor of the RESET is falsely connected in that picture. Like Gwideman correctly stipulates, the resistor needs to go to pin 1, and not to the DTR-side of the cap.

In the Arduino IDE I have the 'Arduino Uno' selected.

Hope it helps somebody.

• Welcome to EE.stackexchange! You wrote a nice explanatory answer, keep up the good work! – WalyKu Feb 19 '15 at 13:15

I had a very similar issue and it was caused by lousy connections on my breadboard between the FTDI's DTR --- 0.1uF ceramic cap --- AtMega328p's RESET.

The issue was solved when I inserted the male wires into the same holes as the legs of the cap, so that the connection was stronger. I was able to upload sketches, but it was still not very reliable. When I exchanged the 0.1uF cap for a 10uF ceramic cap, it seemed to fix the issue completely.

EDIT: Another issue causing similar behavior was using an "USB overcurrent protector" module between my laptop and the FTDI module. So I stopped using it although my previous laptop was burned by one of my wirings :o( Together with a tighter breadboard uploading sketches works like a charm.

The only thing I can think of when I see this error, is that the wrong board is selected in the Arduino IDE. You probably need to select a board that uses the atmega328p.

• I do have the UNO selected. – Ethienne Apr 17 '14 at 17:40

I came here seeking answers to a very similar (identical seemingly) problem -- 382P in breadboard, already with a bootloader & code on it but not responding to programming attempts via a 'cheap' ebay FTDI breakout - though the reset appeared to be working. Many different possibilities for error.

After verifying my circuit was the same and double checking my IDE setup, the answer by matthijs triggered a thought -- I had "Arduino Uno" selected in the Board menu, so presumably the IDE (or avrdude) was attempting to reach the ATmega16u2 on the Uno (which itself is emulating stk500 IIRC). From my attempts (eventually successful) to bootstrap the bootloader previously via a donor Uno I had downloaded a Board config "Atmega328 on a Breadboard" -- which I tried and it worked. Other non-Uno Board configs such as "Arduino Nano w/ATmega328" and "Duemilanove w/ATmega238" also worked.

You can now buy USPasp programmers for atmega chip and Arduinos for 5\$ They connect to the ICSP 6 pin programming port on Arduinos but have a 10 pin connection for other devices, like a bare atmega you have here.

The Arduino software supports USPasp programmers, so do lots of 3rd part programmers. They are electrically very similar to the USB-TTL convertor, but they are explicitly designed to program bare chips and in-circuit using popular software. See:

http://www.ebay.co.uk/itm/131743272473

I have purchased one to re-flash an Arduino Mega 2560 clone which is known to have bad watchdog timing. Later HEX images fix that, but you must use the 6pin CPU programming port on the Arduino.

regards Paul BSc Elec Eng

I have landed on this StackExchange answer looking for a solution to the same problem. I learnt a lot from reading all the answers, but none of them appeared to solve my case. Eventually I fixed the problem and thought of sharing the solution.

I purchased an AVR 328P + crystal + 22pf capacitors kit on Amazon as a "barebone Arduino kit" to try it out. The vendor claimed that the AVR would have an unspecified "arduino bootloader" installed.

I put the circuit together following a few examples and bits of documentation found googling around on how to program an AVR using the FTDI breakout. I had used the FTDI boards before to successfully program some Nano Pros before so I kind of knew what to expect.

Once wired the FTDI and connected to USB, from which the AVR was also drawing power, I added the canonical LED setup to D13 at the end and, lo and behold, it started blinking familiarly. It turned out that vendor had pre-flashed the AVR with the Blink demo. The chip appeared to be clocked correctly and working as expected.

I fired up the Arduino IDE and loaded the Blink demo. If they can do it, so can I, right?

Nope. No matter how hard I tried, I could not upload the program to the AVR with any combination of board/programmer selections. Triple checked all connections, googled around, found this question, tried all solutions, nothing. avrdude could start, reset the chip correctly (I could see it from the blinking pattern), attempt to send data (FTDI tx led blinked) but uploading

At this point I began wondering whether the bootloader was out of date, so went for the nuclear option:

• loaded the ArduinoISP sample into the Arduino IDE
• connected a spare Arduino to be used as the programmer
• uncommented "#define USE_OLD_STYLE_WIRING"
• wired D11, D12, D13 to D11, D12 D13 of the bare AVR chip
• wired D10 of the programmer to the Reset pin of the AVR chip
• add a 10Kohm pull-up resistor to V+ at the Reset pin
• uploaded ArduinoISP to the "programmer"
• selected "Tools/Programmer" -> "Arduino as ISP"
• crossed my fingers

The "crossed my fingers" must have worked, because avrdude was happy and the chip was no longer blinking - meaning that at least I was able to upload something and likely there was nothing wrong with the chip and the wiring, even if it likely meant that I had bricked the chip.

I only had to try again, so I unhooked the "programmer" from the AVR, went back to the "Blink" sample, uploaded after selecting the "Arduino/Genuino Uno" board, and, yay!, there was the cheerful light!

So, all in all it was not that difficult. All I had to do was to cross my fingers at the right time.

There are many diagrams and articles on how to flash the bootloader to a bare AVR using "Arduino as ISP", here's one I found useful:

Running Atmega328 in a standalone mode without Arduino Shield

ive found that the 328 and 328p in avr dude are recognised as different chips, edit the avrdude.conf for the 328p and add this signature instead 0x1e 0x95 0x14

You need a 10uf cap connected to the reset pin and DTR. Here is a working example of how you should be connected:

The 3 other caps are 22pF

• Please remove or rewrite this entirely incorrect posting which can only lead readers to frustration. A large capacitor between reset and ground would prevent the auto reset circuit from entering the bootloader. Nor is that what this picture you are using shows - it shows a capacitor between DTR and reset. Further, 22pf is woefully inadequate for supply bypassing. – Chris Stratton Jul 8 '16 at 7:38
• No, it is incorrect! The problem with your post is that you specify a "10uf cap connected to the reset pin and ground" THIS IS UNWORKABLE. The correct location for the capacitor is between DTR and reset, but that is not what you posted. Also, 22pf is effectively the same as having no power bypass capacitor at all - it may still work, but it is not sound design. You need to remove the matching, equally incorrect, comment on the question, too. – Chris Stratton Jul 8 '16 at 19:22
• You are still giving a faulty recommendation on the supply bypass. We deal in engineering facts here - it doesn't matter if you got that idea from elsewhere, it is still wrong. – Chris Stratton Jul 8 '16 at 19:30
• Your apparently fundamental misunderstanding of bypass capacitors is something you could correct with any reference on the subject. There is nothing to "chat" about here. – Chris Stratton Jul 10 '16 at 0:30
• If you look at the bypass caps C4, C5, C6, C7 on the reference design you link to they are 100nF not 22pF. – Pete Kirkham Aug 22 '16 at 12:05

protected by Community♦Aug 18 '17 at 22:50

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).