I have the same issue while uploading program to my arduino uno board.I tried almost every suggestions available but none of them worked.I am only able to upload the blink program n make changes to it.
Please help me.It's a request.
RyugaRedoc:
I have the same issue while uploading program to my arduino uno board.I tried almost every suggestions available but none of them worked.I am only able to upload the blink program n make changes to it.Please help me.It's a request.
Which operation system (and version)?
Which version of the IDE?
Was it working before?
Is the board recognised in Windows device manager (or Linux/Mac equivalents)?
Correct board selected in IDE?
Correct port selected in IDE?
Hi I have a duinotech Nano Atmga328P
and get this message when i try to upload it
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
help needed
what do i do
I using a mac and running Chrome
Hi folks,
I also have the same problems with
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xb7
with a breadboard ATMEGA328P-PU.
Peculiarely this only happens only from on the second flash of an application.
i.e.,
- I flashed the bootloader to the breadboard, using another Arduino via ISP-connections: Worked fine
- I flashed the Blink example initially to the breadboard via PL2303 USB/TTL-UART converter: Worked fine
- I tried flashing another sketch to the breadboard, to replace Blink: failure as above
Then I flashed the bootloader again and things repeat as above.
Flashing sketches per SPI works fine too, every time. But via TX/RX works only once after a freshly flashed bootloader.
Flashing bootloaders works very reliable every time. So my hardwareconstruction seems to be in good condition (Short wires, good Gnd, blocking caps, Reset-Pullup,...). I tried 2 different bootloaders. The one with 8MHz-internal oszillator and the Arduino-IDE-supplied one for the Pro Mini, 8MHz external/3.3V. Driving things with 5V though.
It seems for me, right after bootloaderflashing, the ATMEGA is and stays in waitingcondition for beeing flashed by RX/TX. My LED on PB5 (The LedPin 13, Arduino uses for onboard LED) indicates this state, by flashing.
When the IDE starts flashing the first application (Blink, ...) it says "upload" and the RX/TX Leds on the USB/TTL-UART converter flash continously. Then, on the second flash of a sketch, there is no USB/TTL-UART Led-flashing. No wonder, timeout errormessage "...not responding" occurs.
I'm using Win10, Arduino IDE 1.8.15.0, an UNO-Clone with SMD-ATMEGA328p-PU as ISP-flasher.
I'm gonna get 2 UNOs with DIP-Pin ATMEGAS this afternoon for testing.
Oh and... I flashed another sketch with 115200Bd serial communication in both directions. The communication did well. So the quirk should be no matter of TX/TX-timing. And I tried grounding Reset, with releasing when the IDE says "uploading" -Didn't help :((
My questions are:
- How can I shut off this "unwanted feature" and flash sketches as often as I want?
- How can I shut on this feature again?
- And finally how, when and why does the ATMEGA-Bootloader know, a sketch is knocking on RX/TX's doors for flashing?
I googled mostly successless all night for answers.
Thanks for reading all this and thinking,... And maybe answering
Hi there,
I'm here again, after testing with UNO Clones, which have DIP ATMEGA328.
So, using one Uno as programmer, programming the other, worked as intended and flashing several sketches on the target ATMEGA afterwards also.
However both UNOs have 16MHz crystals, but in my problem as above, 8MHz were used. So there's no one-by-one compare possible here.
Since these UNO's crystals have the size of a flea, they are actually not interchangable with my big ones, I use with the breadboard. As a "half workaround", I flashed ones bootloader with the two 16MHz UNOs, using "8MHz external crystal" settings and put the so flashed ATMEGA on the breadboard with the 8MHz crystal.
Then again, I was at the same place as before, since...
Flashing the first sketch was OK.
Flashing the second ended up with the "...not responding" error message, as before.
Therefore, as last hope I looked at a Pro-Minis pins, with a FTDI232 Board plugged in on its short side. The Pro Minis six pins: Gnd, Gnd,Vcc, Rx, Tx, Rst. Looking at the FTDIs pins, I saw the DTR connected to the Pro-Minis Reset. Connecting the same at my Breadboard-FTDI connection didn't help though. :(((
Well, then I got all my different USB/UART-TTL-converter and gave them a try. As there were a PL2303, a CH340G and a CP2102. Finally the PL2303 worked!!!!
After hitting upload at the Arduino IDE, I grounded the ATMEGAs reset and released it as the IDE started uploading to the ATMEGA. This procedure worked every time I tried.
I'm not very happy with this, but it works.
I think I will try some Resistors between the RX/TX inbetween the Pro Mini an the USB/UART-TTL Converter. I saw this at other places, like at NodeMCU. Maybe this helps.
So far for now.
Does anbody have more and better ideas?
This out of sync business is driving me nuts. Recently on both Mac and Pi3, I upgraded to IDE 1.8.7. None of ny Uno nor Nano can upload my sketches except for Mega. I havn't figured out why yet but I suspect it is 1.8.7 bug or some thing. Do you use 1.8.7?
af1812:
This out of sync business is driving me nuts. Recently on both Mac and Pi3, I upgraded to IDE 1.8.7. None of ny Uno nor Nano can upload my sketches except for Mega. I havn't figured out why yet but I suspect it is 1.8.7 bug or some thing. Do you use 1.8.7?
For the Nano, try selecting Tools > Processor > ATmega328P (Old bootloader).
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 
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?