stk500_getsync() not in sync resp=0x00 arduino uno

hi everyone, it might be very old problem may be some of you have solution for this problem.... i got my arduino R1 one month and burnt some programs and it worked fine after about a week all of sudden it started giving error"stk500_getsync() not in sync resp=0x00 arduino uno" .I tried every thing told in forums and troubleshooting so i thought i damaged my Atmega (loopback test turned out fine). so i ordered new bootloaded IC. i got my Atmega 2 days before and successfully burnt ledblinking program on first go, but as soon as i tried to burn other program again started getting same error. Previous program is still running on Atmega(Led is blinking). Now when i press reset button as long as i hold that led stops blinking and after leaving button it starts blinking as it was previously in the interval of 1 sec.Now i don't know what to do.I browsed through internet for long period tried everything told in various forums, nothing worked out for me. Now i am handicapped on this issue. =( =( =(

i have seen that so many guys have same problem, still there is no solid solution for this problem!!!!!!!!!! I don't know whether to continue or give up..... coz in case if i buy one more IC stil may end up with same problem????? :sweat_smile: :cold_sweat:

I would ask what your sketch size is?

i burnt led blinking example given in examples..... I don't think there is any problem in far as sketch size is concerned its size was 1108 bytes

You get this error also in the case when the programmer connection is barred somehow to the avrdude

I have the same error after building my own Arduino Uno . After some analysis I've discovered some irregularities in the TX from the ATMega8u2 to the ATMega328. What I see on the logic analyzer is a baud rate very different (around 14k baud or so), which doesn't make sense and likely causes the ATMega328 to not receive the proper bytes (hence out of sync).

I've loaded the ATMega8u2 successfully using DFU with the USB to Serial image available here:

called "Arduino-usbserial-uno.hex"

My only guess is that this image is somehow wrong or damaged because it's receiving bytes but sending them to the ATMega328 incorrectly. I'm going to look at some older versions if available and if not look at the code. By the way, I read that this is a possible windows issue, but I used Ubuntu in a VM and this didn't help either, so I'm down to a baud rate/communications issue. My board works fine with ICSP and the TX and RX LEDs light up with communication (the ATMega328 receives the bytes since I see it respond back at the proper baudrate of the sketch I load).

Hopefully this helps someone. I'll post if I get anywhere.

Using the November 29 file gives the error:

However, I found another post discussing the issue:

I checked my settings in boards.txt: Uno uno.upload.protocol=arduino uno.upload.maximum_size=32256 uno.upload.speed=115200 uno.bootloader.low_fuses=0xff uno.bootloader.high_fuses=0xde uno.bootloader.extended_fuses=0x05 uno.bootloader.path=optiboot uno.bootloader.file=optiboot_atmega328.hex uno.bootloader.unlock_bits=0x3F uno.bootloader.lock_bits=0x0F

I have performed the UART loopback test as specified in this forum and captured it. The loopback itself goes OK since I see what I send. However, it seems the baudrate is not 9600. As you can see from the logic analyzer, it estimates it at 14000 or so. Either the software is bad or my crystal isn’t correct. This would be strange since I would assume that if the 16MHz crystal was bad (if it is in fact the UART clock source) that it would result in errors on USB (since it’s likely used for the 48MHz PLL or whatever the ATMega8 uses).

One thing I've failed to note. When I use a programmer to download a sketch to the ATMega328, I get told that the signature isn't correct, to I changed:

0x1e 0x95 0x0F;


0x1e 0x95 0x14;

in the configuration for avr-dude. The part in the board is ATMEGA328-MU.

After a lot of searching and trying I resolved it. Basically if the RX LED blinks 3 times it means that the ATMega8u2 on the board is sending the data. However, when I looked in the logic analyzer at it, the baudrate was incorrect. The loopback test was running fine but the baudrate was still correct. Further, when I downloaded a sketch using a programmer that used the serial, I could see that the ATMega328 was sending data properly. Therefore the issue is the serial software in the ATMega8u2. Note that this is a brand new device. It did enter to DFU mode but the serial part is damaged. To resolve this, you must :

Use a programmer such as AVRISP mkii to download the combined dfu and serial firmare called UNO-dfu_and_usbserial_combined.hex

C:\Arduino\hardware\tools\avr\bin>avrdude -p atmega8u2 -F -P usb -c avrispmkii -U flash:w:UNO-dfu_and_usbserial_combined.hex -U lfuse:w :0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m -C "C:\avrdude.conf"

Note that it will work inf the hex file is in the folder of the avrdude.exe (the bin folder). Point to the right place for your avrdude.conf file. If all is OK it will download successfully. And will show up as AT90USB82. Then remove the ICSP cable and let it boot up as the application (serial converter). If it needs drivers, use those in the Arduino folder. In my case, the device showed up as Communications Port COM5.

Because my chip is the ATMega328P with a different signature, I had to change the signature of the ATMEGA328P from 0x1e 0x95 0x14; to 0x1e 0x95 0x0F;

This is in the ATmega328P section.

Then download the sketch as you would always do (select the Arduino UNO, then the right COM port).

Use a programmer such as AVRISP mkii to download the combined dfu and serial firmare called UNO-dfu_and_usbserial_combined.hex

I told him the same sometime back that he needs to reload the programme in 8u2 ,meaning DFU'ing it.


DFU'ing won't work since you cannot download the combined version with DFU. When I tried to do so, it told me that the size was incorrect. It can only DFU the serial version that is alone.