Go Down

Topic: avrdude error (Read 92194 times) previous topic - next topic


The L LED doesn't blink at all. Does this mean I need to load the bootloader on again?

How could it have lost it? Did I do something wrong while using it? I only got it this week, still learning about it and things.


Well. Personally I haven't managed to accidentally destroy or 'lose' a bootloader, but there have been posts complaining about just that.

A much more common cause of sudden failure is a fried chip


aha! yes, i have the 328 chip. setting that fixed it.

(after a minor gronk where my COM4 disappeared, crashng the usb host controller. odd, but power off reboot cleared that.)

thanks, i uploaded a sketch, and am running it now.


Seems my atemega was fried. New one just arrived and it all work perfectly now.


I ran into this same issue today with a Seeeduino V1.12 ATmega168 board with the 'blink' sketch.

IT seems when I copied the code from the tutorials an extra line was copied after the last curly brace.

I'm assuming a line break was inserted. I cleaned up that and the Seeeduino is happily blinking away.

Just thought I'd toss this out as a potential solution that got me working.


I'm having the same error...

Code: [Select]

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

I've tried:
New PC (two) This one has no av of any sort nor has it
Reinstalled the driver.
Checked the Serial Speed
Changed the COM port
Changed & Matched the Serial Speed in the COM & boot.txt files
Swapped the AM328 chip with one from a new kit
Tried to Jump GND with Reset
Tried all the Hold Reset & Upload tricks
I read this thread page by page and tried everything i saw.

This is a Freeduino board v 1.22

The only thing to note is the reset button doesn't do anything at all. Nothing blinks or changes when i press it. (Same with grounding Reset & GND)


I built another one of these boards, same problem. The first one worked for about 10 uploads. This one wont do a darn thing. Same exact error.


Same problem with a Seeeduino v328 via the onboard FTDI USB. My Seeeduino stalker board programs just fine.

Can anyone tell me what the upload speed is for this board, perhaps I have it wrong...

In my case I have the board set to auto-reset wehn programming. When I click upload The L led flashes, then RX flashes three times, then after a while TX comes on for about 5 seconds. Serial port monitor shows that the TX bit is just a few characters repeating over and over...


I just built my severino board and everything seems to be working great, EXCEPT I get the same error mentioned below, but ONLY when powered from the DC power jack.

Strangely, if I power the board from my tinyISP USB programmer, I'm able to upload sketches flawlessly, every time.  Move back to the DC jack, it times out again.

What's different about the power from the 6-pin ICSP header?  Is it something to do with the reset pin?  I'm really stumped on this one.

(I should mention, once I've loaded a sketch, e.g. HelloWorld powered from the ICSP, then I reset and power from the DC jack, the serial circuitry seems to work properly: TX/RX LEDs, HelloWorld repeating on the serial monitor, etc.  It's ONLY when I try to upload a sketch that I get the communications problem.)

Any help would be greatly appreciated.  Here's the error I get:

verbose reads:

       Using Port            : COM1
       Using Programmer      : stk500v1
       Overriding Baud Rate  : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: Send: Q [51]   [20]
avrdude: Recv:
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done.  Thank you.


DA_Hero method solves problems like :
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
device signature =0xffffff

I enjoyed above errors from a infinite loop/ faulty sketch.

Atmeg works perfect now 8-)


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

I had this error today and the cause was wrong fuse setting when burning the bootloader. My CPU ended with internal clock and this messed the communication.

Altough I had set the fuses correctly, my programmer ( I used an AVR Dragon ) requires to program the fuses after burn the code. I think that it is because I did not use the "auto" feature of the programmer.

Correct fuse settings are: 0xF8, 0xDF and 0xFF
Lock bits is 0xCF

As indicated in the Arduino site.

This is one cause for this type of error but there may be others, as avrdude will show error messages if it is unable to communicate with the board.


Oct 17, 2010, 07:52 am Last Edit: Oct 17, 2010, 07:53 am by jinn Reason: 1
Came across the same problem and found the solution finally..
Just check if you have updated your arduino driver before everything  ;)


i got this notorious avrdude: stk500_getsync(): not in sync: resp=0xe0 errör trying uploads on a arduino pro mini 328 - i don't have the reset buttoni connected so i found out it's a bit byte of timing - you've to find the rhythm between upload and pressing the reset button & as i've kind of longer piece of code Da_Heros solution worked for me:
# click on UPLOAD in arduino ide.
# while the sketch compiles power up the board with still pressed the  reset button.
# -->RIGHT in the moment where Arduino IDE says "sketch size xxxx..." release the reset button so the board boots up....  


What worked for me (Win XP, Duemilanove, ATMEGA328).

open /path/to/arduinodir/hardware/arduino/boards.txt

Make sure it contains the following:


Open the arduino COM port in Windows Device Manager.
Set the port speed to 57600 bps
8 data bits,
parity None
Stop bits 1
Flow Control None.


OK....just moved over to my Vista box and had the same problem. Tried the original solution (modify COM settings to match baud rate stated in C:\path\to\arduino\hardware\arduino\boards.txt) but it did not work.

I tried modifying boards.txt but was prevented by Vista file permissions, so set those to full read/write access and saved the file without changing it. Tried uploading to the arduino again and it worked...

That is pretty weird, my only suggestion is that boards.txt has linux style line endings, and this confuses the Arduino development environment under Windows, but that is a wild stab-in-the-dark.

Go Up