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

Arduino: 1.8.7 (Windows 10), Board: "Arduino Nano, ATmega328P"

Sketch uses 14496 bytes (47%) of program storage space. Maximum is 30720 bytes.
Global variables use 912 bytes (44%) of dynamic memory, leaving 1136 bytes for local variables. Maximum is 2048 bytes.
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM6 -b115200 -D -Uflash:w:C:\Users\Manni\AppData\Local\Temp\arduino_build_750153/BADDY_EMBEDDED_CODE_ARDUINO_V01.ino.hex:i

avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

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

Using Port : COM6
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done. Thank you.

An error occurred while uploading the sketch

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

williams303:
...
...

Did you read reply #26? Did it solve the problem?

I had the same problem and fixed it by downgrading to AVR Boards 1.6.20. Before I did this I tried selecting ATmega328P (Old Bootloader), but this gave a compile error. This is a cheap Chinese nano with the CH340 driver.

The selected boot loader should not have an influence on the compiler.

Please provide exact error message if you encounter the problem again.

I was fixed the problem by changing usb cable.

Hello all,

I recently upgraded to IDE 1.8.7. I use mostly Arducam Nanos with the legal FTDI232 chips in all of my projects for the last two years. When I tried to download a sketch, I got the same error messages that everyone has been talking about. I investigated the problem by checking for up to date drivers, changing cables, trying downloading on several other PC platforms. What I finally found was that downloading worked fine on Mega2560 and other UNO boards. The only one that didn't work was my Nanos! I remedied the problem by re-installing IDE 1.8.5. Works fine. So I reloaded IDE1.8.7 back on another platform and noticed the old bootloader selection that wasn't in the 1.8.5 list. As suggested by someone in an earlier post, it worked. Something has changed in the new IDE load that has caused a problem. This has go to be why the Old Bootloader is now a selection. How about letting the rest of us know about it. It certainly would save some sleepless nights and panic attacks trying to re-establish communication with my Nano boards.

Reg Mason

There are hundreds of threads here about the problem. You just found the wrong one :wink:

To sort it in the IDE 1.8.5, upgrade the board manager to version 1.6.21.

IDE 1.8.7 uses a higher version than 1.6.21 and that version has a bug in the tool chain that you might or might not encounter one day. You can downgrade the board manager to version 1.6.21

It's also in the official documentation for the Nano:
https://www.arduino.cc/en/Guide/ArduinoNano#toc4

NOTE: We have updated the NANO board with a fresh bootloader. Boards sold from us from January 2018 have this new bootloader, while boards manufactured before that date have the old bootloader. First, make sure you have the Arduino AVR Core 1.16.21 or later looking at the Board Manager. Then, to program the NEW Arduino NANO boards you need to chose Processor > "ATmega328P". To program old boards you need to choose Processor > "ATmega328P (Old Bootloader)". If you get an error while uploading or you are not sure which bootloader you have, try each type of processor 328P until your board gets properly programmed.

And if all the other suggestions don't work then its avrdude trying to connect to your arduino board at the wrong speed.
I upgraded Ubuntu and had to reinstall the IDE. Ended up with IDE version 1.8.7 and found I had this problem except responce was generally not 0x00. Obviously my boards were OK because I could programme then on another computer. Finally figured it out as being a speed issue. I guess someone decided to change the default avrdude speed to 115200. File ->preferences and tick the box for show verbose output during upload to see the speed used.
To change the speed for programming (on Ubuntu 18.04 at least) edit /home//arduino-1.8.7/hardware/arduino/avr/boards.txt
then change nano.menu.cpu.atmega328.upload.speed=115200
to nano.menu.cpu.atmega328.upload.speed=57600
of coarse you will need to search for your device rather than the atmega328 used on my Nano's.

I hope this saves someone hours of searching and pointless downgrades, re-installs or changing boards.

I guess you didn't read what I wrote in my last reply. You don't need to edit boards.txt. You only needed to select Tools > Processor > ATmega328P (Old Bootloader).

The old bootloader communicates at 57600. The new bootloader communicates at 115200.

Thank you pert for the solution.

I upgraded from IDE 1.8.5 to 1.8.7 a few days ago, but it was only today when I wanted to amend an old Nano program that I fell down this pothole. Fortunately after a very frustrating hour or two I ended up here.

Funny really. A few days ago I posted a topic The need for speedy access to known solutions and a plea for full revision histories of software libraries. pert was one of the few people who could see what I was getting at.

Of course the answer to this Nano problem is hidden away in 12,500 words of Arduino Software Release Notes. But who would think of looking there?

This is one of the annoying aspects of the Arduino. Although it is great fun, it is so 1960's - when weekly updates used to arrive highlighting the effect of changes that had been made weeks or months before.

Somewhere someone must have known that this update was going to affect people with Nanos, but without speedy access to known solutions a whole crowd of people (looks like more than 26,000!!!) have been floundering around. I rest my case.

I'm glad if I was able to be of assistance.

I think this issue provides a much better argument for what you proposed. This is a problem that has appeared so many times over the last year that I have a canned reply saved in a file so I don't need to type it out every time. There are quite a few other potential causes of this error message so you might not get very good search results just by typing it into Google, especially earlier in the year before we had managed to saturate the Internet with answers for people having this problem. That leads to a vicious cycle where searching for existing answers is difficult so people just make a new post on the forum and we repeat the same thing over and over again.

Some time ago, I created a Troubleshooting page on the Arduino forum that was intended to be a collection of answers to the most common problems:
https://playground.arduino.cc/Main/Troubleshooting
There is an official Troubleshooting page, which the IDE even recommends reading in some cases when an upload fails, but it's really low quality and outdated. I have a pretty good "to do" list of things I was planning to add to the Playground page but now that they're planning to ruin the Playground by making it read-only, I don't know if I'll bother. I did go ahead and add the Nano issue mentioned here since I was thinking about it.

freddie43:
Of course the answer to this Nano problem is hidden away in 12,500 words of Arduino Software Release Notes. But who would think of looking there?

This is one of the annoying aspects of the Arduino. Although it is great fun, it is so 1960's - when weekly updates used to arrive highlighting the effect of changes that had been made weeks or months before.

Somewhere someone must have known that this update was going to affect people with Nanos, but without speedy access to known solutions a whole crowd of people (looks like more than 26,000!!!) have been floundering around. I rest my case.

I must point out that this is also documented in the "Getting Started" page for the Nano:
https://www.arduino.cc/en/Guide/ArduinoNano#toc4
I think it's reasonable for someone who just bought a Nano to look for help. However, it might be so obvious for someone who's Nano was working fine until they updated to a new version of Arduino AVR Boards.

pert Thanks for that very interesting reply, although I think there is a 'not' missing from your final sentence ;-). Also, wasn't it a new IDE that caught people out?

Thanks also for the link to the Getting Started pages. How come in 3 years on Arduinos I never looked there? I guess it is because none of the books I have got out of the library or pdfs I downloaded ever mentioned it. I can see I also need to explore the Playground area!

Your Troubleshooting page is certainly a good idea and I would like to contribute to it and see it transferred to this forum. It could include a link to the Getting Started pages.

Maybe our last few posts deserve a new topic to attract a wider audience?

freddie43:
I think there is a 'not' missing from your final sentence :wink:

Oops, you're correct.

freddie43:
wasn't it a new IDE that caught people out?

No, the change was made in Arduino AVR Boards:

The same problem will occur with any IDE version if they install Arduino AVR Boards 1.6.21 or newer. You might think it's related to an Arduino IDE version because the IDE comes with the latest version of Arduino AVR Boards at the time. So if you install Arduino IDE 1.8.6 or newer, you get the Arduino AVR Boards with the new Nano bootloader. But ever since the introduction of Boards Manager, it doesn't really make sense to associate a specific Arduino AVR Boards version to an IDE version since any Arduino AVR Boards version can now be used with any IDE version.

freddie43:
Your Troubleshooting page is certainly a good idea and I would like to contribute to it

There will probably only be one more month left to do that before they make it read-only.

freddie43:
see it transferred to this forum.

I don't think the forum is an appropriate platform for this content. If I was to continue with the project, I would probably use a GitHub wiki, though it's not the greatest. I'll eventually try to do a big rewrite of the official Troubleshooting page and incorporate some of the more general content from the Playground page.

freddie43:
Maybe our last few posts deserve a new topic to attract a wider audience?

I think your other thread is fine for that. No need to create a new one.

Whatever they did with the boards it was the (consequential) change to the IDE that caught me out. I thought that was true for most other people too.

There was no change to the IDE. The commit I linked in my last reply is the only change that was made.

It was the Arduino AVR Boards 1.6.21 release that caused the problem for most people because that was done 6 months before the first release of an IDE version that contained an Arduino AVR Boards version with the new Nano bootloader. By default, the Arduino IDE notifies you when a new Arduino AVR Boards version is available and prompts you to update. It continues doing this forever until you either update or disable the checks in preferences. So a lot of people just clicked the update and then found they could no longer upload to their Nano. Other people bought the new official Nano boards and found they could not upload to them because they were still using the old version of Arduino AVR Boards.

It was those first couple months when the problem was popping up so frequently. By the time Arduino IDE 1.8.6 was released, the word had mostly gotten out that you needed to select the correct Tools > Processor item for the Nano.

Sorry. We seem to be talking at cross purposes here. I thought we were agreed with the release notes for 1.8.6

core]

  • AVR: Set Optiboot as default bootloader for Nano. This is the bootloader installed on new
    Arduino Nano boards. If you have a Nano with the old bootloader you must select
    Tools > Processor > ATmega328P (Old Bootloader) to upload.

It was when I upgraded that I hit this problem on an old Nano

No. I understand exactly what you're saying. You're just not understanding what I'm saying. I'm quite aware of that part of the release notes because I wrote it. I think if you go back and carefully read my previous replies it should be clear to you.

The release notes system goes back to the days before Boards Manager, when the Arduino AVR Boards version was directly tied to the IDE version since they were always released together as a single package. That is no longer the case. They should have separate release notes for each of the official hardware packages (Arduino AVR Boards, Arduino SAMD Boards, etc.) but they don't. The closest thing to that is the commit history on their GitHub repositories.

pert. I am away from home at the moment so I do not have access to a Nano or an IDE.

I do hear what you say and I accept it. But what I am saying is that however it got there, the first time I hit the problem was when I updated the IDE from 1.8.5 to 1.8.7. That is my experience and you cannot deny that is why I see things the way I do (and probably why others do too). If I had not updated I would not have known of the problem or be in this thread. But thank you for the explanation of how and when it got there. I am grateful for your clarification of how it got there, but can we leave it at that?

By comparison David Prentice has managed to identify the wide range of controller chips that are put on seemingly identical mcufriend TFT LCD shields and has worked hard to provide software to drive them all.

Sadly, unlike my genuine Arduinos, all my clone Nano, Uno and Mega boards seem to have the same onboard refs, so there is no s/w way to identify them and treat them correctly and change the way the IDE handles them.

But the real problem is as Robin2 says in my other thread: Arduino developers seem to have very little interest in backwards compatibility.

freddie43:
Sadly, unlike my genuine Arduinos, all my clone Nano, Uno and Mega boards seem to have the same onboard refs, so there is no s/w way to identify them and treat them correctly and change the way the IDE handles them.

The solution is to just burn whichever bootloader you want to them. Then there is no need to do any identification. I prefer to use the Uno's configuration, since this frees up 1.5 kB of flash memory:

  • Connect an ISP programmer to the nano. If you don't own an ISP programmer, you can use an Arduino board as an "Arduino as ISP".
  • Tools > Board > Arduino/Genuino Uno
  • Tools > Programmer > select the appropriate programmer
  • Tools > Burn Bootloader

After doing this, you should use your Nano as an Uno.

freddie43:
But the real problem is as Robin2 says in my other thread: Arduino developers seem to have very little interest in backwards compatibility.

It is true they could have changed the bootloader and fixed the watchdog bug of the old one without breaking compatibility. The only downside compared to what they did do is needing to stay with the slower upload speed of the old bootloader. Or they could have broken compatibility, but changed the boot section to 0.5 kB instead of the unnecessary 2 kB they are using now. So we ended up with the worst of each option: Breakage, without reaping the most important potential benefit of the change. It would be interesting to know the story of how that came about. I suspect this one was not a decision made by the developers, but someone in management or manufacturing. I pointed out the issue immediately after the change was made to Arduino AVR Boards but by that time they had already made a bunch of Nanos with the new configuration so fixing it would have required either doing the right thing and recalling all the misconfigured Nanos from their distributors or else doing the hacky thing and adding yet another Nano configuration option. Instead, they decided to stick with the mistake and continue to produce Nanos with the suboptimal new configuration.