Go Down

Topic: avrdude: not in sync again (Read 29323 times) previous topic - next topic


yes, i checked the fuses [lfuse 0xff, hfuse 0xdd, efuse 0x00] against the AVR Fuse Calculator and they were set to use external crystal. i'm just a bit confused because the fuse calculator does only show external crystal frequencies up to 8MHz for the atmega168.

the crystal reads "8.000 KD0817" so i guess it's really 8MHz and not 16. i took some photos of my board :

i bought at  http://www.watterott.com (german vendor) but i couldn't find any bad references about it. will give them a call later.



did your board come with that 4 pin connector mounted next to the FTDI chip? or did you install it yourself.

just trying to figure out if you have been sold a prototype by mistake



i started to work with Arduino, and I have some problems..
I tried one of the examples (EEprom write), and since then the LED in it is flashing, and i can't sync to it.
Arduino Decimila
I tried to restart it but, it didn't help, how can I clean the EEprom?
avrdude: stk500_getsync(): not in sync resp:=0x00
avrdude: stk5600_siable(): protocol error, expect=0x14, resp=0x51


Feb 19, 2009, 05:37 pm Last Edit: Feb 19, 2009, 06:08 pm by Stephan_Watterott Reason: 1
Please contact me with your order number at our shop.

Can you make an photo also from the bottom side of the Duemilanove?
( Specially the crystal section)


Feb 19, 2009, 07:40 pm Last Edit: Feb 19, 2009, 10:08 pm by KidCrazy Reason: 1
@Massimo Banzi: no, i installed the connector by myself because i was in need for a possibility to flash the chip.

@Stephan Watterott: ahh, perfect. i already tried to reach you by phone :) backside of the duemilanove comes here: duemilanove4.JPG. please ignore the bad soldering points at where the additional 4 pin connector is. i didn't have the best equipment when i made it. lighting is a bit bad at this hour but i hope you can see most of it. I also sent an email to you through the contact form in your webshop.

okay, it seems as if the wrong crystal was put on the board.
Mr. Watterott gave me choice to exchange the whole board or just send me a new 16MHz crystal. I chose to take the crystal and solder it in by myself. So everybody's fine again and i can go on with work :)


Interesting.  This is one of those "that can happen" sorts of things; sometimes a part will get filed in the wrong bin, or shipped in the wrong tube, or whatever, and no one notices till... much later.

Sometimes it happens with a whole batch.  Is there anyone else who has been getting this error who can read that "8.000" on their crystal?

I wonder if it would be possible to build some sort of diagnostic sketch into the normal program space of "brand new" arduinos, instead of shipping them with a plain bootloader.  It ought to be possible to do that withouy changing the apparently first-time experience, say by only doing "active" diagnostics if a certain bit-pattern is preset on the input pins..


nice idea. i'm just not sure how i would approach to this in case of checking the external crystal. you would have to compare the speed of the external signal to any other periodic signal you can rely on. e.g. compare it to an internal clock signal. but i don't think it's possible to use internal and external clock at the same time, is it?


i don't think it's possible to use internal and external clock at the same time, is it?

I think the watchdog has an independent RC clock.  It's not terribly accurate, but it ought to be good enough to notice the crystal being off by 50%.

And there's the USB chip - IT will transmit accurately at 19200bps even if the AVRclock is wrong, so you could "easily" write a program that sent bootloader commands at various speeds to check for appropriate response  (although I guess an appropriate set of AVRDUDE attempts would have detected the problem with your board even without any additional diagnostics.  But having to plug a board IN to things to test it is a pretty significant pain for a distributor.)


Hey all!

i had also this out of sync problem when i wanted to burn the bootloader to a 328p chip.

the avrdude out of sync happened when i had the avrispmkII at the isp AND the Arduino/USB/Ftdi attached together. When i detached the isp everything was fine! Therefore i had to power the board over an external adaptor.
I think, when the FTDI chip is connected to USB, it acts somehow. When you have then something other on a port the FTDI also works on, something what takes current or so... you may have a problem. For me this was the unpowered, but connected avrispmkII. After detaching it, everything worked fine. Both the ftdi and the mkII are connected to ports. So i had to detach the mkII completely.

First i had headaches about that and some other problems. Checked drivers, cables, connections, ... whatelse.

I had now a quick look at the circuit of the board - i think then we should have a look  also at the reset connections.... and for everything regarding ISP - bootloader burning - we should have nothing attached to pin 13 to 10 of the arduino when doing so.
My problem was the reset line i think now.

take a look here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1234964990


I have now had the avrdude not in sync problem twice: error =>
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

MOST FRUSTRATING, especially when there does not appear to be a consensus as to why it happens and what to do about it. Anyhow, my Due is now working again, maybe my experience will help, maybe not. Before that, however...

1. I have had my Duemilanove about six weeks and done a load of 'learning' stuff. It was definately not d.o.a.

2. I'm no microprocessor expert, all I want to do is plug the 2009 into the USB download sketches and have them run. Hardware on the breadboard are switches, led's etc. ok, now I have a breakoutboard and a 3-axis acc, but it outputs a voltage proportional to acc, so no different really to a potentimeter. All dead basic.

3. I'm not interested in burning bootloaders, makefiles etc or other stuff like that. I appreciate that I have to de-bug sketches, and make sure I connect hardware on my breadborad correctly, but the 'platform' should work as advertised.

4. Having used the 2009 for a while, I am aware that you need to select the correct Com port ;-)

5. Tried the troubleshooting guide. Ticked all the boxes, no help.

6. Google, normally your friend, turned up lots of stuff, but nothing of much help.

Problem arose when using Arduino + Processing to graph output from an accelerometer streaming data to PC(XP) over USB using Serial.print + Serial.println.

I don't recall exactly what I did when the problem occured, but I probably had Processing 'up' but probably not running the graphic Sketch. I was also using 012 at the time.

When plugged in, the L(pin13) LED on the Due blinked quickly, ie slow enough to see it blinking, but fast enough not to see individual on-off-on-off

When trying to download a sketch, the L(pin13) LED would continue to blink as above, but after some seconds (10 or so?) the Rx led would blink almost unpercievably three times over a period of about a second. The L(13) LED continuing uninterupted. Some 15 seconds(ish) later, I'd get the error given above.

I tried following the Troubleshooting guide's suggestions; pressing reset etc.

I tried installing 013 and downloading a sketch using that.

I tried updating the FTDI drivers that came with the 013 software. XP didn't like the idea as they were the same as those installed (I forget the exact error message.)

I tried removing the FTDI drivers via the Control Panel and re-installing. Same problem; which kinda hints at them not being removed even if you do so via Control Panel/System Properties/Hardware/Device Manager/Ports (My PC is in Swedish, so I'm having to translate.)

I tried removing the Atmega completely and downloading a sketch; hey, why not! Same error! Kind of implies that the problem lies with the FTDI Serial/USB chip???

Finally tried starting download of a sketch without the Due plugged in, then after 'a few seconds' plugging it in. RESULT! Blink downloaded and worked. Subsequent downloads without unplugging the Due, without hitting reset etc. worked OK

Quite what this means, whether it is a repeatable solution, and why the problem occurs in the first place are unanswered.

Like I said earlier, it is VERY FRUSTRATING when a great product like Arduino behaves like this. I've had six weeks or so problem free use, then this which has taken, I'd guess, 6-8 hours of googling, reading, installing and uninstalling drivers, pressing re-set etc. I was close to assuming my Due was buggered and would have to order a new one. Clearly not. (Touch wood.)

This topic seems to turn up often, so I am definately not alone, quite how widespread it is, and under what gereal circumstances it occurs (eg when using Processing, when burning bootloaders or whatever) would, I am sure, be of interest to those who know and understand the inner workings of the Arduino. A 'designed in' solution (2010), or at least a solution that is known to work that does not rely upon random pressing of buttons, the phase of the moon or voodoo dolls would be most welcome.



I don't think that everyone is having the same problem, even though they are having the same symptom.

Finally tried starting download of a sketch without the Due plugged in, then after 'a few seconds' plugging it in. RESULT! Blink downloaded and worked. Subsequent downloads without unplugging the Due, without hitting reset etc. worked OK
This REALLY sounds like some other process on your computer was doing something with the same USB serial port that the Aruduino IDE was trying to use.  When you unplugged the Arduino, it gave up and went away, so that when you plugged the ardunio back in, the IDE had exclusive access again...


I agree about the fact that probably there are a number of different things going on. Hence my posting the error AND the physical symptoms; L(Pin13) LED + three short blinks of the Rx LED.

Not sure about your suggeston that the USB port was being used by another process. The same physical port had been used with a web cam, but that was 24 hours earlier, PC had not been re-booted since, and the Arduino plugged in out countless times. Why would this other process suddenly decide to give up blocking the USB port? Is it possible to see which processes are using which USB ports?

When I look at the ports/usb drivers via the Control Panel (This is with the Arduino workin as it should, running Blink), with the Arduino plugged into the USB I see a USB Serial Converter under the 'USB Controllers' ?? (Sorry translating from Swedish) and a USB Serial Port (COM5) under 'Ports.' Unplug the USB, and these dissapear. So surely nothing can be using a port that the OS does not see?

And why did the fault appear in the first place. Like I said, I've been using the Arduino for 6 weeks. Then when I start using Processing and serial comms the problem appears... Is this a common denominator for others experiencing the same problem?



Hi David,

I'm quite new to Arduino, but I learned quite much about it in the last few weeks while debugging why my Duemilanove wasn't working. This is what I found out about the symptoms you describe (please correct me if i write anything wrong, everyone ;) ): the L LED will blink once when the board is reset, this is just before the Arduino software tries to download the sketch (I'm not sure about the subsequent blinks after the first one). The Rx LED will blink when data is transfered from your computer to the board. Three blinks = three tries to download your sketch to the atmega. If the Tx LED is NOT blinking during that time, this means that the board  is not responding to the commands that were sent.

This can be due to a big bunch of reasons: another process on your computer is sending data over the arduino com port at the same time you are downloading your sketch (so the board doesn't understand the resulting 'chatter'), the board runs on another frequency than the Arduino IDE is assuming (this was the problem for me), the bootloader is damaged (some users wrote that the bootloader was damaged when they downloaded too large sketches), your atmega is dead, there's a broken connection or component somewhere on the board, etc.

This means the symptoms you wrote can also be due to a whole series of problems that can't be diagnosed too easily.

However, hope you won't have too many problems with your Arduino in future :)


Has anyone made any progress on this?  I have a (homemade) board based on the Dorkboard, with an atmega168 on it.  The Arduino IDE is successful downloading to it about 10% of the time, the rest of the tries generate the dreaded "out of sync" error.  I set up Eclipse for my IDE, and it will download successfully almost exactly every other attempt. It's almost like there's a bit flipping somewhere, it's very predictable.
I removed the '168 and plugged in an atmega328, and it gives this error every time.  I've tried more than one chip, so I feel confident that it's not a bad chip.  What else could it be?


If you get this message after you complie your Program than you do not have the right version of avrdude for your  atmega 168, or 328 after you down load The (IDE) from ww. ;)arduino.cc/en/Main/Software.site then look in the tools menu for the type of atmega you have. you will have to lower your fire wall when you download the small program  avrdude:stk500_getsync( ):not insync:resp=0*00 ;)

Go Up