Go Down

Topic: avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00 (Read 78200 times) previous topic - next topic

Martyair

Code cannot be loaded to the Arduino
"avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00"

Arduino Nano
ATmega328P
COM 6

The Arduino Nano worked before.
I tried another Arduino Nano --> no upload possible.
The Code shows no failure.
Serial Monitor / Plotter shows return Data from the Arduino from previous version of the Programm.
The "Blink" Sketch kannot be uploaded as well.

So... the programms are good, the Arduino is connected (shows serial return data), the Arduino hardware is good (tried another one).

What ellse could be the reason for the failed code upload?

Thanks Martin!

DrAzzy

Sounds like either wrong board is selected, or it's not resetting for some reason.

When you open serial monitor, does it reset the board? ie, do you see the bootloader blinking the light?

Is anything connected to reset pin?
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

callmebob

I tried getting started with attiny85 and followed the current instructions at these sites http://highlowtech.org/    http://hlt.media.mit.edu/?p=1695     https://github.com/damellis/attiny

It broke my Arduino installation on three different computers and I got similar errors on Nanos that worked previously. Silly me tried to install the attiny85 software on three different computers thinking it must have been bad hardware. Yes I'm a fool. It was the software and it took me a day or two to figure out what was going on.

I uninstalled, restarted, re-installed the Arduino IDE thinking that was sufficient, but noooooo.  I had to track down three or four different folders manually that were affected by the installation and delete any trace of attiny and I got the uploads and my Nanos to work again -- yes, on all three computers (a desktop Win10, a laptop Win10 and a desktop Win7).

CrossRoads

Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

callmebob

Thanks I'll give that one a try next time I need some punishment :)

Passo

I had the same failure on my elegoo uno R3, after changed fuses and burned bootloader.
I checked com ports, board "uno", and programmer "avrisp mk2". But i cant upload the data anymore. I tried with another real "arduino uno" board with my atmega328p. the Failure was the same. But with another atmega328p with arduino bootloader was working on the both boards. Also i decided to throw away the defectivly atmega328p and bought an atmega328p without arduino bootloader.
The new Ic didnt work, too. An bootloader upload on the new ic wasnt possible.
 Also i decided to check the fuses with atmel studio and STK500 board instead with command avrdude and uno r3 board.
I programmed the original fuses and upload the bootloader with atmel studio. now it works fine.
I never trust the bootloader upload of arduino ide. because it doesnt work fine.
I thought i could help you.
Another way is to check the fuses(if changed) and set to original settings with command avrdude. and burn a new bootloader with another uno board (inlcuding functional atmega328p with arduino bootloader).


If you decided to buy a new board, then buy a board from atmel for example stk 500 or stk600. its very easy to programm fuses and burn bootlader. I will never miss the stk500.

When you use C-code then its a good investment in a good compiler.
Arduino compiler dont understand the c code cleary, but atmel studio compiler do it.


GabNet

I had this problem yesterday with my nanos... I solve it to downgrading to AVR Boards 1.6.20. A temporal solution... I guess.

callmebob

I'm back to having that problem after finally getting it solved (I thought).

I will continue to troubleshoot it, but I'm wondering if there is a way to reduce the number of tries of:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3c

10 attempts seem like overkill and a big waste of time. It seems that a couple of tries are sufficient. After two attempts it looks like we can pretty much predict the outcome.

NealB

I have also experienced the same problem.
The problem started when I received a notification of a board updates whilst in the Arduino IDE. The update was for Uno's, Nano's etc. I tried various things including drivers, re-installing the IDE etc.

The solution is to fully remove the IDE and removing the Arduino folder from the app data folder, then re-installing the Arduino IDE.

To prove the solution I have tried updating the boards again and the problem re appeared, and after apply the fix again - all is fixed again. I have since tried it on another PC and again the fault appeared and was fixed with my solution.

Hope this helps someone else.

pert

The problem as it occurs with uploading to Nano with Arduino AVR Boards 1.6.21 can be solved by simply selecting Tools > Board > ATmega328P (Old Bootloader). There's no need to uninstall or downgrade anything.

The problem as it occurs for other boards will have a different cause and a different solution.

callmebob

I solved my problem by messing around with choosing different boards from the menu choices (Tools > Board > ATmega328P  -- and Tools > Board > ATmega328P (Old Bootloader), and a few other menu options, and opening and closing different sketches and magically it started working again with ATmega328 menu choice.

I think my problem re-occurred because I used a different Nano that must not need the Old Bootloader where the previous Nano I had plugged in did need it. With Nano #2 the IDE finally started working with the ATmega328P choice... not the 'Old Bootloader' choice. But it took a bunch of poking around.

pert

If you have an official Arduino Nano that was recently purchased then ATmega328P is the correct selection.

If you have an official Arduino Nano that was purchased some time ago then ATmega328P (Old Bootloader) is the correct selection.

If you have a clone or counterfeit Nano then almost certainly ATmega328P (Old Bootloader) is the correct selection but they might start shipping some of those with the new bootloader eventually.

If you have successfully done a Tools > Burn Bootloader on your Nano then you need to select whatever you had selected when you burned the bootloader.

The best (though more complex) solution is to Burn Bootloader with Arduino/Genuino Uno selected and then use the Nano as an Uno from then on. This will install the same bootloader as the new Nanos, end the confusion as to which Nano option to select, and free up 1.5 kB of program memory. There are tons of tutorials available on how to do the Burn Bootloader process. You need an ISP programmer or an extra Arduino board to use as an "Arduino as ISP".

Lars81

I have a similar problem.

I've tried programming an Atmega328p at both 16MHz (external) and 8MHz internal ("Atmega328 on a breadboard"). Using the ISP I'm able to burn the bootloader on both setups, and install a simple sketch for blinking a led and writing data to the serial port. When I connect an FTDI-device to the chip I'm able to receive the serial data on both setups (suggesting that the ftdi-device works, as well as that the frequency is correct). However when I try to install a sketch over serial (DTR connected to RST via 0.1uF as well as a 10k pullup on RST) I get this error message: "avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00".

Any suggestions? I could probe the RST pin on an oscilloscope, but what should I look for?

For comparison I hooked up a working Arduino UNO (original) and probed the RST pin there, and the signal was identical to the one I got on the "barebone arduino", suggesting that the reset signal is working fine as well.

JaeKar99

After about a hour of beating on this Nano 3.0 I realized it has a   M168PA chip..  I will not be buying from this seller again...

pert

After about a hour of beating on this Nano 3.0 I realized it has a   M168PA chip..  I will not be buying from this seller again...
That is strange. If it was an ATmega168 you could use it by simply selecting Tools > Processor > ATmega168 but the ATmega168PA has a different signature than ATmega168 so you can't do that with your Nano. Luckily the excellent MiniCore supports ATmega168PA so you can still easily use your Nano:
https://github.com/MCUdude/MiniCore
Actually I believe the ATmega168PA has some superior specs compared to the ATmega168. Of course it's also inferior to the ATmega328P used on most Nanos due to having 1/2 the flash and SRAM.

Go Up