[SOLVED]: FTDI to breadboard Arduino - not in sync error

The symptoms are all in the thread. The solution was painfully simple (thanks Nick Gammon!!), adding 1k pullup resistors to the TX and RX pins of the Atmega328 did the trick. I've seen a ton of posts with not in sync errors all over the internet, but not many solutions other than the usual "check the right COM port, correct board etc". I haven't seen anybody recommend what I had done, or what Nick suggested, so hopefully this will help someone in the future.
That said, I still have no clue why the pull-up resistors solved the problem. There are no breadboard Arduino guies that I can find that suggest including those. If anyone wants to try and explain that, I would love to know why that is the case.
Thanks again to everyone who helped!

Hi all,

At this point, I don't really need help so much as I need an answer to put this thing to bed once and for all.

I was trying to program an atmega328p (with UNO bootloader) on a breadboard using an FTDI chip. I kept getting this error:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

After some experimenting, I was able to get the FTDI chip to upload to the Atmega328 correctly by putting the Atmega328 into my R2 Arduino UNO, and connecting Vin, GND, RX and TX to the respective pins on the FTDI board and reset the Atmega328 chip manually during uploading. An image of this setup is below (excuse the poor drawing):

After a little MORE experimentation, I came across another configuration that worked, shown below (again, please excuse the drawing). This time, I used the DTR pin. In the diagram, you can assume all components are present on the breadboard (yes, including the pullup resistor to pin 1!). THE ONLY CONNECTION TO MY COMPUTER IS THROUGH THE FTDI BOARD, SO THE BREADBOARD, AND EMPTY ARDUINO ARE BEING POWERED BY THE FTDI:

However, if I try to upload the sketch WITHOUT having that connection to the TX and RX pins on the UNO board, it does not upload. This leads me to believe that the Atmega8u2 on the UNO board is somehow facilitating the upload. It makes no sense to me but maybe someone here will be able to tell me what's happening.

At this point I don't even care about my project, I literally just want to know why!!! I've checked the UNO R2 schematic and that has not yielded any answers for me. If anyone has any idea please please please tell me because I'm pulling my hair out here trying to figure out what's gone wrong!!!



However, if I try to upload the sketch WITHOUT having that connection to the TX and RX pins on the UNO board, it does not upload.

That is the correct behavior. The bootloader receives the new code via the serial “port”. Without these connections, the programmer (avrdude) has no way to communicate with the chip.


I think you have misunderstood me. The chip being programmed is on the breadboard. The sketch is being uploaded via a separate FTDI board. My question is, how come the sketch only uploads successfully if I connect the RX and TX lines to the RX/TX headers of an Arduino UNO without an Atmega328

Please look at my diagrams again, particularly the second one. It is messy, but that's exactly how I have things connected. Notice that the blue board has no atmega328 chip on it

Without looking at the Eagle files, my initial reaction here is "pull-up resistors". If I plug a LED shield into my Uno ... the Blinkenlight Shield which has high-power LEDs - D0 and D1 light up and stay lit up. Now I think that is because the Atmega8U2 sends the Rx line (at least) high via a 1K series resistor.

The fact that your circuit works with the board paralleled up but no chip suggests to me that the Atmega8U2 and the 1K resistor are playing a part here. Try measuring those pins for a voltage (without the Atmega328 inserted). That would confirm it. Now if I'm right, provide your own pull-up on one or both pins and see what happens.

Now I didn't need to do that with my own bread-boarded Atmega328, but I'm not using the same FTDI interface that you are.

I understand the set-up and the problem..

I know you said you have all components on breadboard.. does this include the crystal and caps then too?

Thanks! That's exactly the kind of thing I was looking for. I had a feeling the 1k resistors to the 8u2 TX/RX pins had something to do with that, but I had no way of knowing if they were acting as pull-ups or pull-downs. I tried reading the 8u2 datasheet but couldn't really get any useful information from that. I guess this is as good a reason as any to get an oscilloscope :).

Yup, all components includes the crystal and caps. The setup on the breadboard functions fine, just not when uploading!

I'll try the suggestions here and report back.


This issue has been thoroughly SOLVED (though not explained...yet)

Thanks all.

how?..what was it you had to do?

What Nick posted sorta went over my head a bit.. lol


Ok so here's the gist of it.

See in my second diagram where I have the yellow and orange wires running to D0 and D1 of the empty Arduino board? I took those out, and instead replaced them with 1k resistors to the 5v rail on my breadboard (pullups).

If you look at the schematics for the UNO R2, you'll see that the TX and RX pins go through two 1k resistors to the RX and TX pins of the Atmega8u2. Since the 8u2 was obviously not transmitting any data to the chip on the breadboard, that only left the 1k resistors as being the reason why my second setup worked.

This much I had figured out on my own, but the real breakthrough came when Nick mentioned his experiences with an LED shield, mentioning that LEDs connected to D0 and D1 would stay lit. He suggested taking a multimeter to those two pins and seeing if I pick up a voltage. Sure enough, he was right, and I read 5v on both those pins. This meant that the 1k resistors were acting as pullups, which was why my FTDI board would only upload when connected to D0 and D1 or my Arduino.

By adding those two 1k pullups to my breadboard, I was able to replicate the configuration in my second diagram without the Arduino. The rest, as they say, is history!

Again I should add that I still don't know WHY this worked, but I did notice that the FTDIfriend (FT232RL breakout board) sold at www.adafruit.com includes a 10k pullup series resistor on the TX line, yet the Sparkfun board does not; I'm not sure what that is there for. I followed the Sparkfun schematic in making my board (except I added a 0.1uf cap on the DTR line) hence my issues.

As far as I can tell, not many people have tried adding pullups to the TX and RX pins on the atmega as a solution to the "not in sync" and "protocol errors" that seem to be so rampant when using and FTDI chip +breadboard Arduino.


Thanks for the feedback. BTW just to explain why (maybe) it works…

The idle state for async serial is a series of 1 bits (eg. 1111111111). In the case of the Arduino that is +5V.

A byte starts with a “start” bit which is a zero. So now you have 111111111110xxxxxxxx1111111111 … where the start bit is in yellow and the data bits are underlined.

Without the pull-up(s) one or both sides are either seeing noise or perhaps just zeroes. Now when the chip finishes booting it seizes control of the lines and sets them to a known state, but there would be a period where those zeroes (or noise) would look like a whole lot of start bits, potentially corrupting what it thinks it is receiving.

By forcing it high with a pull-up you are making the hardware instantly go into the idle state, until such time as it boots and the processor takes over.

The series resistor you mentioned would have another purpose - to limit current to avoid damage to the chip(s).

Nick that makes a lot of sense, and the experimental evidence checks out. Strange that those pull-ups aren't mentioned on any of the arduino-to-breadboard guides available on the internet though... How do people successfully upload sketches without them? Is it possible that my circuit design (on the FTDI board and/or the breadboard) is introducing noise into the tx rx lines, where normally you'd get by just fine without the pull-ups? What's the variable here?

EDIT: I see on the data sheet that port D on the atmega 328 has internal pull-ups. The only way I know of to activate internal pull-ups is through the Arduino IDE by calling digitalWrite() to an input pin. Obviously since this has to be done in a sketch, the pins probably wouldn't be pulled high until the sketch is actually running (but I could be wrong about this). Is there any way to set those two pins pulled high and keep them like that regardless of whether the pull-ups have been enabled in code? I feel like this might be a bootloader or fuse setting but that's just a wild assumption. I'd be interested in knowing...


Is there any way to set those two pins pulled high and keep them like that regardless of whether the pull-ups have been enabled in code?

I doubt it. Short of hardware, like resistors.