avrdude: not in sync again

Hi there from a very newb on arduino or microcontrollers in general :slight_smile:

Today I got my first Arduino, a Duemilanove, and tried it directly when I came back from work. I used the exact procedure as written in the "Getting started with Arduino" book by Massimo Banzi:

  1. downloaded "arduino-0012-win.zip" from arduino.cc
  2. extracted it
  3. plugged the Arduino with to my laptop by USB
  4. installed the drivers from "drivers\FTDI USB Drivers" directory (both low level driver and serial to USB converter)
  5. put a LED into GND + PIN13 with short lead to GND
  6. started Arduino IDE and tried to upload the blink sketch

Now here is where the problem is: The sketch is compiled but Arduino returns with Error:

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

By googling I found that this probably means the connection between my PC and Arduino is not working properly.

What the Arduino does:

  • Power LED is burning bright green :slight_smile:
  • The L LED and LED on PIN13 blink with a period of about 2.5 seconds (apparently this means the bootloader is on the chip)
  • When pressing the reset button, the L and 13LED are only dark as long as the button is pressed but instantly go on blinking with first flash exactly when I release the button (shouldn't there be a delay of 2 seconds first?)
  • If I unplug the USB cable (no power) and plug it in again, TX and RX LEDs do blink some times rapidly, then the L and 13 LEDs blink rapidly and finally go back to blinking once in 2.5 seconds
  • If i try to upload a sketch, the L+13 LEDs do blink some times (2 or 3), then the RX LED does also blink about 3 times and then L+13 LEDs go on blinking as before (2.5 secs period)

So now I'd like to know if this is all normal for the Arduino (except the errors showing from avrdude) i.e. if I should search the error in my own PC/connection cable or if there's something wrong with the Arduino or the bootloader.

My system:

  • I got a Lenovo X60 Tablet PC
  • Windows XP with all current updates
  • One real serial port (COM1) and two bluetooth stacks installed (COM4+COM5), USB Serial Port is on COM6 and selected in Arduino IDE
  • Arduino Diecimila selected as Board in the IDE
  • Arduino 0012 Alpha running

Hope there's any help possible. I'd not like to send it back and wait for another week or two until I can try it :stuck_out_tongue: :smiley:

Thanks in advance for any suggestions,
Kc

There's really nobody who can say anything to this? o_O

Posted by: KidCrazy Posted on: Today at 18:04:51
There's really nobody who can say anything to this? o_O

The Kid seems to be right about this.
Having had the same problem, I looked through the internet for a solution, and really didn't find one.

I found that there were, and are, several people with same problem, and nobody on the boards I looked through could do much to help. They all give out the same suggestions, all of which you have probably already done. Arduino troubleshooting page isn't much help.

You could try googleing: **avrdude: stk500_getsync(): not in sync: resp=0x00 **or
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

I sidestepped the problem by programming the atmega chip with a parallel programmer, as I explained in this post:

ptool64ar
YaBB Newbies

Reply #14 - 26.01.2009 at 05:43:12 | Remove

I got it working by using parallel programming. At least I'll be able to use Arduino that way, which ain't so bad.
I used the "Parallel Port Programmer" described by Arduino; here: http://www.arduino.cc/en/Hacking/ParallelProgrammer
AND, Burning sketches to the Arduino board with an external programmer, FIND THAT HERE: http://arduino.cc/en/Hacking/Programmer
This is done without a bootloader, so it says in that information page.

I'm sitting here looking at that blinking light, finally
I even modified, slightly, the blink program from a one second blink to a two second blink. But , since the LED in the sketch uses the same port as the SCK port on the ATMEGA168, (one of the ports used by the parallel programmer) you will need to remove that LED before programming. You can put it back in after the program is uploaded, and it blinks .

You will need to make a couple of mods in Preferences.txt file in C:\Documents and Settings\Owner\Application Data\Arduino , which is the (per-user local version of the pref. file) as the instructions state.(where it says: upload.using=bootloader, replace the word bootloader with the word parallel)

Here's something else, if you should use that homemade arduino programmer, - that pref. file doesn't include this statement: set the parallel port defaults (used if upload.programmer=dapa). That statement is in one of the main pref., default , files. I copied it from the main pref. file, found in The "arduino-0012/lib", then inserted it in the smaller (per-user local version of the pref. file) I inserted that statement without the # in front of it.

Arduino doesn't say much about those preference files, and its difficult to find the (per-user local version of the pref. file), which should be found as "preferences.txt" in C:\Documents and Settings\Owner\Application Data\Arduino I have to use my PC's "Search" procedure to find that file, and had to tell it to search in "hidden files" on top of it all.

That's the best I could do. However you might find a mistake in your settup. One that I can think of is the pin-13 enigma. There are two pin-13's on arduino. One is the actual pin-13 of the Atmega168 chip, the other is the "arduino pin 13", which is one of the header pins on the arduino board and is actually connected to pin-19 of the Atmega168, just to add a little confusion to an already confusing situation. (the arduino pins are NOT numbered the same as the microcontroller pins)

potool64ar

Did you check out http://arduino.cc/en/Guide/Troubleshooting ?
With two bluetooth serial ports, I'm sort of suspecting that you have some sort of background "thing" that is interfering with the Arduino IDE access to the USB serial port, but since I don't have a PC with bluetooth, I'm not sure exactly what would be suspect...

thanks for your posts :slight_smile:

@ptool64ar:
that's a good idea. i think i'll be going to build a parallel programmer in the next days and first try to rewrite the bootloader so i can see if that's where the problem is. if it is not, at least using the programmer to write new sketches onto the chip would be more satisfying than not being able to persuade the board to do anything other than blink a led :stuck_out_tongue:

@westf:
yes, i read the troubleshooting guide several times, but there seems no help from this. interference between the bluetooth ports may be possible but i already tried deactivating both and it shows no difference. what i find strange is, that there obviously IS some data going through to the arduino. the board reacts with flickering the L and RX leds but then goes back to normal blinking before the upload seems to be done.
but it also does this when i just send some arbitrary data over the port through the serial monitor. so it seems to me like the transfered data just isn't in a valid format or as if the arduino just doesn't respond to any command sent there. unfortunately, i got no idea how to check what really is going through the cable so i could do some more investigation on this. how do you actually debug such things?

It wouldn't be the bluetooth ports themselves that would cause interference; it'd be whatever app is monitoring those ports for whatever device is expected to show up, like a palmtop hotsync thing.

If your harware-aware, you can try removing the AVR from the socket, putting a jumper in between digital pin 0 and 1 (rx/tx) on the digital headers, and talking to the board with the "serial monitor" function of the arduino IDE. This creates what is know in the comm industry as a "digital loopback" scenario; anything you type in the serial monitor should echo back, with associated blinking of the rx/tx LEDs. If you see no or partial echoing of your typeing even though both LEDs are blinking, then something is eating characters that should be going to the arduino...

Hi again,

there's news from the frontier :slight_smile:

Today, first thing i tried was your suggestion, westfw. I removed the atmega from its socket, shorted digital pins 0 and 1 and sent something through the serial monitor. came back exact like i sent it so i think the data transfer from my pc should be allright, correct?

I also sat down and built a parallel programmer cable. I measured the electrical resistance of each line and double checked the wiring so it should be ok I think. I installed giveio (i had some problems with the installation at first, but it is shown in "device manager" -> "non-pnp devices" now) and applied the registry patch.

However, when I go into Arduino IDE and choose "Tools" -> "Burn bootloader" -> "w/ Parallel Programmer" I get this error:

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: AVR device not responding
***failed;
avrdude: verification error, first mismatch at byte 0x0000
0x3f != 0x00
avrdude: verification error; content mismatch

:stuck_out_tongue:

I dunno. That's one of the problems with homebrew hardware; there are SO many things that might be wrong. Even if your parallel programmer build is perfect, and windows isn't doing anything strange to it, you could STILL have a DoA ATmega chip that is causing you all your grief...

hmmm... is there any way i can check if the atmega is working at all?

"hmmm... is there any way i can check if the atmega is working at all? "

Yes, substitute it with a new one. They are cheap and it's not like a spare atmega isn't a useful thing to have around.

Lefty

Are you having any luck with your arduino?

I don't think there is any help for this problem. Nobody seems to know what causes it, nor does anybody know what those error codes mean.

If you look through the internet by googleing :avrdude: stk500_get sync(): not in sync: resp+0x00 and/or avrdude: stk500_disable():protocol error, expect=0x14, resp=0x51 you will find that many people had or have this problem and they have posted them on several forums. They all get the same replies that don't help. The questions and answers just go round and round.

It seems to be a problem that is common to arduino. And by reading the internet posts, it can be seen that it has been a problem for two or three years. Yet no solution, and nobody seems to know what to do or what its all about. Its not even mentioned in the arduino troubleshooting page. Some people have gotten lucky and stumbled on a fix, but can't explain what they did.

So far I've programmed a Parallax Basic Stamp very easily with Pbasic on a PIC microC. An Atmega32 using Bascom-AVR, which goes quite smoothly and Atmega168/8 using WinAVR, which was somewhat difficult at first. They all have their problems, but none of them presented an almost unfixable problem as this one that arduino poses.

I thought that I had it made when I was able to program my arduino by using parallel programming. It worked on one or two simple sketches, but then gave me lots of problems on a more complicated sketch, which was one that I really wanted to use. The problems grew worse and worse so I replaced the atmega168 with a new one and was able to burn a new bootloader on it.

Great, I thought to myself, now things will work. So time to upload good old Blink and :avrdude: stk500_get sync(): not in sync: resp+0x00 . Yup, I says to myself, time to give up on this.

Its probably my computer, but I didn't get into this to become a computer expert. I just wanted to get microcontrollers working so that I could use them for small projects. Looks like I'll have to work with Bascom or WinAVR. (The full Bascom-AVR program = $100, I use the free (quite)limited version. WinAVR is quite complicated and has few examples)

Sorry for the long story :cry:
Patrick

Sorry to hear you are giving up Patrick. This particular error is often mentioned and often solved when the user realizes they have to select the correct com port. I know that you've said this is not the problem in your case. I don't think it's fair to be upset with the Arduino folks when you yourself even admit that it is most likely a problem with your hardware. It's very hard to diagnose problems of this nature over the internet as you may not tell us something you don't think is important but in reality is the cause of your problems. I mean, it could be something as silly as a bad cable or a null modem cable. Or it could be other software on your computer interfering with the comport. It could also be a simple wiring mistake or power supply issue.

Good luck.

okay, i wanted to give it another try and went for a new atmega168. unfortunately i could only get my hands on an atmega8-16. i read they are pin-compatible. does that mean i can just exchange the current chip by the new one on the board and "should" be able to programm it?

I've had the same problem. I managed to fix it by re-installing the driver. I noticed in the device manager (I'm running Windows Vista) that although the device was listed under USB Controllers, it was also listed under "Unknown Devices" as not installed correctly. I uninstalled this and the one under USB Controllers and re-installed it (just unplugged the device and plugged it in again). When the drivers were installed correctly, there was an entry under USB Controllers as before and another catagory, Ports (COM & LPT), with an entry USB Serial Post (COM8). Then using COM8 in the IDE, the sketch uploaded okay.

Just to back up what every one else is saying. Every time I have had this problem on Windows it is because I have been trying to use the wrong com port.

While programming, the Arduino leds flash and everything appears to be working ok but the error appears afterwards.

I seem to remember a similar dos problem years ago with com1 & com3 having a lot in common as well as com2 & com4

I only skimmed through this thread because I'm looking for something else entirely...

When I first got my Duemilanove it worked flawlessly for about 3 hours of messing around writing and loading sketches to get a feel for it. As soon as I started messing with Serial.print() it stopped accepting sketches with the sync error.

I found that when I load a sketch now I have to watch the Arduino. As soon as the TX/RX leds blink when the sketch is trying to transfer I have to hit the reset button. It then takes the sketch every time.

Hope this helps, or is at least on topic...

:Patrick
http://RedBinary.com
http://Odometron.com

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

FWIW, I did some experiments. This is exactly the error I get if I set my arduino environment to use a serial port exists, but that echos output to input rather than being an actual arduino. (For my tests, I used the ftdi cable and put a jumper between the rx and tx pins.)

If you set upload.verbose=true (the default is false), you'll get very detailed debugging in the console window. (but alas, not very UNDERSTANDABLE info. Sigh.) Here's the output from the loopedback serial port:

hardware/tools/avr/bin/avrdude -Chardware/tools/avr/etc/avrdude.conf -v -v -v -v -pm168
       -cstk500v1 -P/dev/tty.usbserial-FTD61T6Q -b19200 -D
       -Uflash:w:/Users/billw/Documents/Arduino/demo16x24/applet/demo16x24.hex:i 


avrdude: Version 5.4-arduino, compiled on Oct  9 2007 at 11:20:31
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/billw/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port            : /dev/tty.usbserial-FTD61T6Q
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: 0 [30] 
avrdude: stk500_getsync(): not in sync: resp=0x30
avrdude: Send: Q [51]   [20] 
avrdude: Recv: Q [51] 
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done.  Thank you.

And here's the beginning of a successful download:

hardware/tools/avr/bin/avrdude -Chardware/tools/avr/etc/avrdude.conf -v -v -v -v
      -pm168 -cstk500v1 -P/dev/tty.usbserial-FTD61T6Q -b19200 -D
      -Uflash:w:/Users/billw/Documents/Arduino/demo16x24/applet/demo16x24.hex:i 


avrdude: Version 5.4-arduino, compiled on Oct  9 2007 at 11:20:31
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/billw/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port            : /dev/tty.usbserial-FTD61T6Q
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
         AVR Part              : ATMEGA168
         Chip Erase delay      : 9000 us
         PAGEL                 : PD7
         BS2                   : PC2
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no        512    4      0  3600  3600 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6   128    0 yes     16384  128    128  4500  4500 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [02] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [01] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [98]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [03] 
avrdude: Recv: . [10] 
         Hardware Version: 2
         Firmware Version: 1.16
avrdude: Send: A [41] . [84]   [20] 
avrdude: Recv: . [14]

@Red Binary:
I tried your suggestion but get the same error anyway. However, I did find that only the RX led is blinking when the sketch should be uploaded. Is this the same for you or should both be lighted? I get the feeling there's no response from the chip back at all as if there just isn't any bootloader on it, only the default sketch (that's blinking the L led).

I also found this thread in the forums:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1183647052/0

May it be the ones who produced my board made the same fault and just didn't lock the bootloader before uploading the test sketch? I don't know where they're produced, but it came in a green sealed antistatic plastic bag.

I decided to order an STK500 to have more flexibility in future but it will need some days until i get it :stuck_out_tongue:

There's also a tutorial how to burn a bootloader onto the Atmega168 with a selfmade parallel programmer but I didn't have the time to try it yet, so propably that's my next station.

I tried just now to make sure by trying to upload the blink example sketch.

The sketch that was on it during the first try was streaming serial data, so the TX LED was flickering for that and got:

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

So, again I uploaded blink (so that there would be no serial comms in the sketch itsself) by waiting for the RX LED to indicate that the comms are being attempted and immediately pressing reset.

Then I try to upload again without pressing reset. The RX LED blinks 3 times - 3 retries, I assume. A 10 sec or so delay, then a single blink. Another long delay and the IDE gives the fault:

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

When a successful transfer occurs both RX & TX go nuts... Not sure that our issues are identical. I am working on the assumption that my issue is that somehow the bootloader is not going into reset when the comms occur. Since I have the work-around band-aid I haven't pursued it any further.

Do you want me to try in verbose mode and post the successful & failed results?

Did you get the successful transfer results that you posted on a different Arduino?

:Patrick
http://RedBinary.com
http://Odometron.com

ok, I just tested with verbose on and get:

for the loopback:

Binary sketch size: 1116 bytes (of a 14336 byte maximum)

D:\arduino-0012\hardware/tools/avr/bin/avrdude -CD:\arduino-0012\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pm168 -cstk500v1 -P\\.\COM6 -b19200 -D -Uflash:w:C:\Dokumente und Einstellungen\Kc.Work\Eigene Dateien\Arduino\sketch_090127a\applet\sketch_090127a.hex:i 



avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "D:\arduino-0012\hardware/tools/avr/etc/avrdude.conf"

         Using Port            : \\.\COM6
         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=0x30
avrdude: Send: Q [51]   [20] 
avrdude: Recv: 
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done.  Thank you.

for the board with atmega168 on it:

Binary sketch size: 1116 bytes (of a 14336 byte maximum)

D:\arduino-0012\hardware/tools/avr/bin/avrdude -CD:\arduino-0012\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pm168 -cstk500v1 -P\\.\COM6 -b19200 -D -Uflash:w:C:\Dokumente und Einstellungen\Kc.Work\Eigene Dateien\Arduino\sketch_090127a\applet\sketch_090127a.hex:i 



avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "D:\arduino-0012\hardware/tools/avr/etc/avrdude.conf"

         Using Port            : \\.\COM6
         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.

if i take the atmega of the board and don't do a loopback, the output is the same as with atmega.

the only difference between the output for the loopback/chip seems to be the error code of the first avrdude error: resp=0x00 for the atmega, resp=0x30 for the chip.

@Red Binary:
i got no successful transfer yet. this also is my first arduino :stuck_out_tongue:

[update]
I managed to write a new bootloader and some sketches onto the chip using this tutorial:
http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html

however, i tried three different bootloaders:

and none of them could solve the problem, same avrdude: not in sync error. anyway, i'm glad i can try some sketches now :smiley: any suggestions how to go on debugging the problem further?