Mother of all strategies to deal with the dreaded "not in sync" error

Development Tools IDE 1.x
1

For the past two and a half days and until 2 or 3 am in the morning I've been obsessively attempting to resolve the latest incantation of the dreaded

avrdude: stk500_getsync(): not in sync: resp=0x00

error that you can experience when attempting to upload a sketch to your board via a serial interface. I've Googled, I've searched, I've tried all manner of remedies, all to no avail. Because the aforementioned remedies were rather widespread in the Internet, I thought I'd start "the ultimate" thread that addresses the issue. It's kinda dangerous to make such a statement, I realize. I don't claim to be an expert, just someone who is trying to get something working but this is standing in my way. Perhaps others can contribute their experiences and solutions to the thread, in the hope that it would help others in the future.

So a bit of background. From my research, this error essentially means that whatever you are using to upload sketches to your board cannot communicate with the uC on that board. IOW your board isn't responding to your attempts to upload a sketch.

Specifically in my case, I have a custom-designed PCB that uses a 1284p (Bobuino variant via CrossRoads); I have a serial header on my PCB that should enable me to upload sketches serially and also to see serial data from the board for the purposes of debugging. In my case I am communicating with my PCB using the Arduino IDE on my laptop computer. I use one of the USB ports to run a USB cable to an FTDI breakout. Then I use simple female-to-female electronics-project style (0.1") wiring to connect the standard 6-line serial output from that breakout to the serial header on my PCB. Cross looked at a couple of my boards last weekend and told me that he was able to upload the Blink sketch via the serial header on my board. Therefore that tells me that the board is working ok and further that there is something wrong in my configuration. Somewhere. But I'll be @#&*#@$^ if I can find it thus far. The pin connections from the breakout to the serial header are:

BREAKOUT SERIAL HEADER ON PCB
Vcc +5V
CTS CTS (this is a rarely used pin)
GND GND
Rx Tx
Tx Rx
DTR DTR (this pin is connected to the RESET trace via a 0.1uF cap)

Often the cause of this no-response scenario is rather simple, but I have also read stories of folk encountering a much more difficult time in finding resolution. And those folk, like me, were at their wits-end and were willing to try most anything to "fix it." With that in mind, here is a compilation of the possible solutions that I have attempted thus far. Try these as a first-stab:

  1. Check your physical connections. Ensure that your pinout is correct from the breakout to your board.
  2. If using the Arduino IDE, ensure that the correct COM port is selected in the Tools menu (should have a check mark next to it)
  3. Ensure that you have first installed the correct bootloader for your chip; you won't be able to do this serial I/O stuff without the correct boatloader being successfully installed. This must happen PRIOR to you attempting any serial I/O.
  4. Press the RESET button prior to your sketch being uploaded. Sometimes the DTR function on your header isn't working properly and so your uC RESET line isn't being brought low prior to the upload. If this corrects the problem, then you need to re-check how you have your DTR implemented on your board.
  5. Disconnect all wires that run to your Rx pin 0. Then try to upload again.
  6. Check your driver. Perhaps consider using a different driver version or different driver altogether. Uninstall and re-install your driver.
  7. Another of the common causes is a comm speed differential between the device you are attempting to upload sketches with and your board. Ensure that these match.
    8 ) Try a new serial cable.
  8. Try a different device to upload your sketch with.

And the list goes on if you Google enough. There are cases of the Uno not responding, so a reflashing of the hex file that handles serial communication is needed. But that doesn't apply to my implementation since I'm not using an Uno. And so I moved on.

I haven't tried numbers 8 or 9 yet, as those aren't readily available to me. I might have another USB cable that I could try, but I don't have another FTDI breakout to try with. The next step is to order one I suppose.

2

  1. How are you cheking connections? With continuity tester?

  2. I had that error when there was heavy load connected to ARduino, I recommend disconnecting all devices first, then upload.

  3. Did you try reburning the bootloader?

3

Hi mart256-

Thanks for the feedback and contribution. You have the right idea regarding checking connections. More specifically, what I meant by that step was two-fold:

1a) Ensure that you have the wiring done correctly. One cause that I saw when Googling the error was a guy who had Rx connected to Rx and Tx to Tx. Obviously that's a problem.
1b) Perform a continuity test on your wiring from the breakout to the serial header on your board (via DVMM, continuity tester, etc.)

I've done both multiple times and everything checks out thus far. Excellent point about re-burning the bootloader. I've also done that multiple times. I've also tried using a different copy of the same bootloader, just in the (highly) unlikely event that my bootloader copy had become corrupted somehow. Cross sent me the bootloader he uses for his 1284p projects and I tried burning that. Although the burning of the "new" bootloader was successful there was no diff WRT the serial stuff, I got the same result.

Thanks again

4

Hmm, once I was stuck a lot of time. The problem was the crystal, which didn't start up the uC. I had 2 22pf caps, but oscilator needed 18pf, then it worked fine. Are you using external or internal osc? Resonator or crystal?

5

Ok I tried number 8 tonight when I got home. Let me clarify that by saying that I tried using a new USB cable, not serial cable, that was a bit of a typo. I had another USB cable that would fit into the USB port on my FTDI breakout, so I unplugged the one had been using, set it aside and tried the new one. No joy, same result. Just as a quick note, I am using Arduino IDE 1.0.5 on a Win7 laptop.

Other things I've tried during the past few days:

  1. In the Arduino IDE (1.0.5), under File->Preferences, I clicked on the check-box to enable verbose output during hex file upload. That generated the following output from avrdude:
Binary sketch size: 3,208 bytes (of a 130,048 byte maximum)
C:\Program Files (x86)\Arduino\hardware/tools/avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega1284p -carduino -P\\.\COM2 -b115200 -D -Uflash:w:C:\Users\Jerry\AppData\Local\Temp\build4496533372884728245.tmp\Blink.cpp.hex:i 

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM2
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [00] 
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.

The only thing I noted about this was that in the past when using avrdude directly, I had used m1284p instead of atmega1284p for the part option. So I tried running avrdude directly from a command prompt and changed the part option shown in the above code block to m1284p. No diff. And from what I have been able to determine, m1284p and atmega1284p identify the same part.

So then I tried running other avrdude commands in an attempt to do anything via serial. No success. I could post the output from that, but it seems kinda redundant, so I have omitted it for the time being.

So now I'm off to order another FTDI breakout and see what that does. It won't be here for a couple of days of course. That said, I don't anticipate it making any difference, but you never know and having a backup isn't a bad thing.

Later tonight I will try using this same configuration to upload a sketch on one of my old devel boards. The boards I am attempting to get working now are the first round of the prod boards. There is no fundamental difference between the two designs, though I switched to an external ADC and per Cross's recommendation the level shifter component was switched out for two individual level shifters. And I made the switch to JST connectors. So there's no significant difference; this stuff should work. I know that the devel boards were working in this same configuration. I also know that I encountered this problem in the past. Switching to a slightly newer version of the FTDI driver seemed to cure the problem then, but it hasn't made a difference now. Cross told me that he's using an even older version of the FTDI driver, so I may download that, install it and see if it makes a diff.

Will keep up the fight and post the results to this thread. Any ideas are appreciated. Thanks

6

mart256:
Hmm, once I was stuck a lot of time. The problem was the crystal, which didn't start up the uC. I had 2 22pf caps, but oscilator needed 18pf, then it worked fine. Are you using external or internal osc? Resonator or crystal?

Hi-

Interesting. Thanks for the continued feedback. I hadn't thought of the crystal being a problem. Hmmmm....it doesn't seem like the crystal is the problem in my case however. I say that only because I can upload the blink sketch successfully via the mkII programmer and the ICSP header on my board. And Cross was able to upload the Blink sketch via the serial header via his setup. It is an external SMT crystal that I am using, specifically this one:

http://www.mouser.in/Search/ProductDetail.aspx?R=ABLS-16.000MHZ-B2-Tvirtualkey52750000virtualkey815-ABLS-16-B2

I am using 22pF caps for this crystal. It seems to work just fine, if the ability to load and run the blink sketch is any indication.

7

av8or1:
I can upload the blink sketch successfully via the mkII programmer and the ICSP header on my board.

That's great info. It means the problem is not the crystal and your setup works OK. I'd say the FTDI breakout is the bad guy.

8

Well that's entirely possible. Tonight I worked on the problem further. I tried to upload the Blink sketch to the devel board via the Arduino IDE. I was able to do this in the past, I distinctly remember that. However it didn't work.

So I decided to explore further. I have an old XP machine sitting in a back room; I haven't powered it up since the spring; it was my old, quite old desktop. But it still works. I installed Arduino IDE 1.0.5, the Bobuino variant files and the FTDI driver. I tried uploading the Blink sketch to both the devel and prod boards. Neither worked, same error.

So it doesn't appear to be the USB cable, the 6 wires coming from the FTDI breakout, the laptop, the driver nor the boards themselves. That leaves the FTDI breakout...there isn't a way to check the breakout that I'm aware of, so I'll just have to wait until the new one arrives. Cross did mention that he was able to upload via the serial header, so really it should work.

To that end I ordered a new breakout tonight. Well two actually - hah! The first comes from China (so it won't arrive until mid-October!), but I didn't notice until after I bought it (duh-oh!). So I bought another. The second should be here Tuesday. Therefore I'll suspend working on this problem until then. Crossing fingers that this is indeed the cause!

9

UPDATE:

After much effort, it's finally working. I can upload sketches serially now. But it wasn't easy. Quick review:

Uploading via Win7 laptop
Arduino 1.0.5 IDE (occasionally using avrdude directly)
FTDI driver version 2.08.30.0
FTDI breakout (USB to serial/RS232) to serial header on my PCB
Custom PCB with Bobuino 1284p variant as uC

Here is a laundry list of things that I did or tried along the way in addition to those mentioned previously.

  1. Updated the FTDI driver from 2.08.30.0 to 2.10.0.0 (current version) -> no diff
  2. Cross sent me an older version of the FTDI driver, 2.08.02 IIRC, don't remember now -> no diff (but Cross is a good guy, thanks for the effort Cross!)
  3. Received the new FTDI breakout, connected it, tried to upload the Blink sketch -> no diff -> WTH?!?!?!?!?!
  4. Uninstalled the driver, reinstalled the driver -> no diff

At that point I was thoroughly confused and frustrated. I was thinking that the breakout might not be the problem after all. However it was the only item remaining after the elimination process, so I decided to play around even further. I decided to get crafty. So I went to Device Manager -> COM ports and double clicked on the COM port that was assigned to my board. That brought up a properties dialog. I clicked on the Port Settings tab, then on the Advanced button. That brought up a new dialog. In that dialog, you can reassign the COM port number. I changed it from 3 to 2. I didn't restart the Arduino IDE, but instead I proceeded to immediately upload the Blink sketch. When it went to do the upload after the compile, I got a different dialog that stated something to this effect:

COM3 port not found.
Do you want to attempt the upload using a different port?

And there was a drop down menu, in which I selected COM2. Then I clicked OK. The upload resumed and BOOM! For whatever reason the moons aligned and the upload succeeded. WTH?!?! I tried it again to verify. Succeeded again. I disconnected everything, reconnected everything and tried again. Succeeded a third time. Wha-?

So I repeated the entire procedure on the second board. Yup, I couldn't upload serially on the initial attempt. But the little trick with selecting a different COM port (this time from 2 back to 3) worked on the second board. Wha-?

Applied the same procedure on the third board. Nothing worked. So I reburned the bootloader for about the 5th time. Then reapplied the entire procedure as described above. BOOM! It now works. What in the HECK is going on?!?!?! Dunno....

So I decided to apply this procedure but using the old FTDI breakout. No change. No matter what I did I could not upload serially with the old breakout. "not in sync resp=0x00" was always the result. This is a dual voltage board, where the selection mechanism is a solder joint. The joint appeared to have been broken, so I resoldered it. No diff. Therefore in the end, the old FTDI breakout appears to have been the culprit, but WHY? That I can't answer. I don't see a reason why the breakout would stop working correctly, but it did. The new breakout by contrast has a jumper to select between 3.3V and 5V, which I must admit to liking better than the solder joint approach. But I cannot say that this was the problem with the old breakout.

And there you have it. It's a frustrating, annoying problem that someone should find a remedy for. XD But I am back up and running, so that's something.

Anyway, hope this thread helps someone in the future.

10

Glad you got it working finally. I don't recall having to do that much fooling around to get an FTDI chip working under Win Vista, maybe I did but it was 4 years ago, and now they just show up with a COM port # in the IDE.