Avrdude: Stk500_getsync Attempt 1 Of 10: Not In Sync: Resp=0x00

10.08.2019
Joined: Tue. Dec 31, 2013

Avrdude: stk500getsync: not in sync: resp=0x00. Int y =1; void setup for(int i=0;i10 (COM4), and works correctly.

Total votes: 0

Hi, I always used my arduino as isp without any problems, however, last night when i was testing something i got a little bit of dirt on my board, it works fine, the blinky blinks! but when i use it as a programmer , this is what happens with nothing but arduino connected to my PC. The same happens when i connect my attiny:

# sudo avrdude -p t13 -P /dev/ttyACM0 -c avrisp

avrdude: AVR device initialized and ready to accept instructions

Reading ################################################## 100% 0.01s

avrdude: Device signature = 0x000000 (retrying)

Reading ################################################## 100% 0.01s

avrdude: Device signature = 0x000000 (retrying)

Avrdude Error

Reading ################################################## 100% 0.01s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

$ sudo avrdude -p t13 -P /dev/ttyACM0 -c avrisp
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done. Thank you.

the arduino's RX and TX blink. is my arduino damaged :( I paid so much for it!

I know there are other's out there but mine was working before and my board got wet so this is a special case!!

My plight with my year old Arduino Uno started after aninternational trip where my Arduino was accompanying me, for project completionpurposes.

After returning, I noticed that something was wrong. Nomatter what code I would try to upload, it would give the “avrdude stk500_getsync(): not in sync 0x00”error. The RX LED would blink 3 times before this message appearing. The TX LED did not blink at all.
So it meant that an initiate recieve request was being sent from the laptop, but the board did nothing in response.
I searchedand searched and searched on the internet for possible solutions. At first Ifelt that the serial interface, the Atmega16U2/USB Cable must be at fault. To check that,the steps were easy. I just had to perform the Loop Back Test:

1.Connect a jumper between pin 1 and pin 2 of yourArduino.
2.Open the Arduino software and see that theproper com port is selected under Tools>Serial Port (you can look for thecorrect serial port in Device Manager on a Windows Machine by right clickingThis PC>Properties>Device Manager. Your Arduino should be visible under‘Ports (COM & LPT)’. Open the list under this category and there you willfind Arduino xxxx (COMX), where xxxx is your Arduino version, ex Mega, Uno,etc. and X will be your COM Port Number)
4.Input a string of characters and you shouldreceive exactly the same string. For ex, if I input 12355, I should receive12355 in the serial monitor window.
The loop-back test jumper (jumped from 1 to 0 or 0 to 1)




If however, you do not receive the same, there is a problemwith
b.The Atmega16U2’s Firmware
c.The circuit traces between the Atmega16U2 andthe rest of the board.
d.Could also be that the TX LED was bad (needs reconsideration)
For me, I did receive the characters back, but call it mystupidity, I still went on and flashed my Atmega16U2 with a DFU Programmer torule out any errors over there.
But again, after flashing the Atmega16U2, I experienced thesame behavior from the board, performing the loopback test again and trying toupload the code after the firmware flash. Characters were received in the Serial Monitor but the Uploadstill complained “not in sync 0x00”.

Turing On Verbose for Upload (For in depth analysis):
Things were starting to get serious now, so I startedsearching even harder. The problem with this error is that it can occur for anumber of reasons. Also, it was necessary to get the exact errors that occurredduring the upload, so I went on and turned on the Show Verbose output during:Upload option from File>Preferences in Arduino software
Fig X. This Figure has the 'Show Verbose Output During: Upload', ticked/Enabled.
Simply go to File>Preferences to open the above window
a.No communication between the computer and theboard (Covers 90 percent of the cases)
c.Wrong board selected (It is advised to check afew different boards from the Tools>Board Menu)
d.Timing Errors (Still falls under communications,for if the Atmega being programmed does not respond in time, it will be aTimeout)
The reason why it was affecting my particular board was notto be found anywhere on the forums. The theoretical reason was found early on,that my Atmega328p-PU was not responding in time/at all. The practical reasonwas learned the hard way.
In between the bouts of readings, I typically would stumbleupon information that is very necessary to judge the current state of myArduino. For example, on a healthy board, when any code whatsoever is loaded(in the presence of a bootloader), every time the user would press the Resetbutton, the LED labelled L on the Arduino (the one connected internally to the13th pin through a resistor) should blink. That means a bootloaderis present.
I would get the response as:
avrdude stk500_getsync(): not in sync 0x00
avrdude stk500_getsync(): protocol error, expect=0x14, resp=0x51
.
.
.
And 3 requests being send to the board and none received. Sorry that i cannot produce the exact error code right now, i did not have the making of this blog on mind when i was solving the problem.
The Simple LED Blink Test
So, to cross out any such problem, you need to push the resetbutton while the board is powered through USB or the Power Jack, and see if theLED ‘L’ blinks. If it doesn't, the problem might be
b.The chip not responding (damaged chip, blowncircuit traces, any reason why the chip might not respond)

The alleged 'L' LED, marked with the RED Circle

My LED 'L' was not blinking. This lead was something, as small as it was. So I wenton and started looking for resources to burn my bootloader again. I had a spareMega 2560 I had lying around which I could use to program the board, so I wasin luck of being fully equipped, already.
Kicked in the butt by failure
4-5 hours later, after trying a few different burningtrials, I was devastated in the face of failure. I was still thinking that itis only a circuit trace gone bad in which case I might not be able to help it,but still I needed to know the problem. Tried a few more times, and I actuallyended up trashing the bootloader on my Mega 2560, and it also started givingthe “not in sync 0x00” error. Frustrated, I left the problem, and ordered aUSBASP v2.0 LC Technology programmer and 2 bootloaded Atmega 328P-PU MCUs.
Avrdude: Stk500_getsync Attempt 1 Of 10: Not In Sync: Resp=0x00

A packet of Rays of Hope Arrive (Programmer and bootloaded chips)
Fast forward a few days, my programmer and the 2Atmega328P-PU chips arrived. The Programmer was fine but the packaging in whichmy Atmegas arrived made me wary of whether the chips were bootloaded at all toeven start with. It looked to me like factory packaging, having experience withfactory packaging after ordering components from Element14. The first thing Idid after that was to pop in the new Atmega328P-PU chip and try to program theboard hoping (even though I had never abused the board) that it might be ablown chip that was giving me all the trouble. But to no avail. The new chips,both of them, refused to take code and gave slightly different errors, but on the same lines as the original one. F**K Me.
There are going to be a few reasons always, as to why a chipdoes not work the way it is supposed to. If you can figure out the chip beingbad or good, the weight of the problem then falls on the most criticalcomponents, external, on which the chip’s functioning depends. One suchcomponent is the Crystal, another is the circuit traces. After a lot of playingaround with this board, the initial feeling of the fact that the Crystal mighthave bitten the bullet, appealed the most to me.

Multiple Arduino Versions, Drivers, Cables
Still, I tried to program the chip via the programmer I had justbrought. Multiple Arduino versions ranging from 022 to even the 1.5.7 one wereused, in case there was something about the Windows 8.1 compatibility. Eventried the different driver versions. The 1.5.7 version I had was one which camebundled with signed drivers for windows 8.1. I even uninstalled all drivers Ihad and tried all versions of drivers available easily. The latest version, thelast version, and another driver not even for the Arduino, but one that people usedwhen the driver signing was not letting people use their Arduino boards ontheir Windows 8.1 machines. Nothing worked here too.

Breadboard Time
The only option left was for me was to breadboard theArduino circuit and try and program an Atmega328P-PU from there. Who knows, itmight work, was my thinking. So I gathered the components (16MHz Crystal, 2capacitors, Jumper wire), assembled the circuit on a breadboard and used myprogrammer to flash the bootloader on. But no, how in the world can it bethat easy?

The Arduino Software threw out errors of the sorts:

'Auto set sck (because the default is null)
Please upgrade the firmware.
initialization failed rc=-1
Run with –F to ignore these'.
So as it suggested, I ran it with –F (AVRDude was used, not Arduino). Again the verbose output would be
Auto set sck (because the default is null)
Please upgrade the firmware.
initialization failed rc=-1
invalid device signature 0x00000
expected device signature is 1e 95 0F
please recheck connections and try again.
Damn. I was pretty close to ordering a new Arduino Uno. But the pain ofhardware just lying there because of my incompetence in repairing it wassomething I would not take. So I searched some more.
Re-Introduction with the Devil
Fast forward a few more days. I sat down again, feeling determined to make thisthing work, my mind almost forgetting the failure I had endured the last twotimes. But the best thing was, I was taking up the problem with a well settled,untroubled mind, so I could take on to the problem with a new perspective.
The first thought that occurred to me was to try and reflash firmware again,because it might have been problems with wiring the last time. The error alwayssaid “Auto set sck time”. And all thesetiming troubles, well most of them, come from incomplete/incorrect circuits. Theprogrammer I had was the USBASP LC technology v2.0, so I took out a multi-meterto check for grounding. This particular version is 10Pin version.

PS. Real engineers don't use rulers.

On the wire, it goes like Pin 1 then VCC, Pin 3 then Ground (Pin 4), Pin 5 then Ground (Pin 6) and so on. The last Pin is Ground (pin 10). On the other hand, the Arduinohas a 6pin ICSP Header, so a quickfix was needed to convert 10pin ICSP header to 6pin ICSP header.
Curious and with a multimeter, in my programmer, I found that not all theground pins were actually grounded. So, if a normal person, like me, wouldrandomly choose from Pin 4,6,8,10 to put the ground pin on the Arduino (ICSP Pin6), you might not have grounded the Arduino pin at all. That is bad. So manyvariables to go wrong at, and this programmer can cause this one.
Stk500_getsync()
Fig x. Shorting the leads in Continuity Mode reads 002

Fig x Pin 10 ICSP to Pin 3 Atmega8 (GND) [Shows Continuity]

Fig x Pin 8 ICSP to Pin 3 Atmega8 (Shows Continuity)

Fig x Pin 4 ICSP to Atmega8 Pin 3 [No Continuity]

To be precise, Pin 8 and Pin 10 are grounded, directly shorted to the Pin 3 on the Atmega8. Pin 4 and Pin 6 on the other hand, were not shorted to each other and to the Gnd pin of the MCU. WTF? So I chose to short all the ground wires, to actually createa ground.
Fig x My Solution to the Ground problem


Note: The reason for the arrangement of wires in the 10pin ICSP header is that this configuration maximizes stability of signals, shielding from noise in places where a long cable is employed.
Resurrection of the Mega
After this, I tried setting my Mega 2560 back to working condition. Iplugged in the USBASP programmer, put the female header onto the Mega, and
b.Tools>Programmer>USBasp

The Arduino software said Burning Bootloader, this might takea minute. The L LED flashed on the Mega 2560, and no errors, no verbose text was reportedin Arduino. So I left it on for 5 minutes or so, then, believing that theprocess still did not work and from 1 bad Arduino I was officially onto 2 badones, I unplugged it and put it on USB to check for the Bootloader Blink (Bad idea, because unplugging the chip while bootloader is being flashed is a bad idea, NOT RECOMMENDED). To myastonishment, the bootloader had been written, and clicking the reset button,blinked the L LED. Meant that the bootloader was now present on the Mega2560. I checked with Arduino, trying toupload the blink program and it worked flawless, to my relief. So I had passed the Blink Test on one Board atleaset
Nice, now please do it for the Uno

The first problem i faced here was that the way i had configured my header, it would not fit into the ICSP header of the Uno. So, More jumper cable was the solution, not pictured.


Next, I noticed that the USBasp had reported “Auto sck settime” with the Uno, but worked with the Mega. So now I was all set to upgradethe firmware for the USBasp using my newly revived Mega 2560. A few posts and afew errors later, I managed to update the firmware of the USBasp, and nowthinking that I had rectified the major problems I was working with last time,I went on to flash the Uno.

Comes the moment of truth. I tried to plug in the headerinto the UNO, but my design had gone horribly wrong. Improvistion it is, and Iused a few jumper cables to put the header onto the Uno. My heart skipped abeat when I tried to flash the bootloader the same way I had for the Uno, as itshowed this error

“ avrdude: auto set sck period (because given equals null)
avrdude: error:program enable: target doesn't answer. 1
Double checkconnections and try again, or use -F to override

What the Hell? Is it that I am supposed to select SLOW SCK?(Jumper JP3 on my board) I put a jumper on JP3, tried flashing again, and sameerror flashed to my face.
What was it? What was the problem? Why my Uno? Why me? ThenI once again looked at the board, closely, focusing on the Resonator. It iswhen you have lost everything that you look to follow your instincts. And thenI saw the Resonator on the Mega. Both looked different. And then it occurred tome. My Uno had no working Resonator. It’s cap had blown off. And only the baseremained, as you can see in the pictures. And that was my problem.
Fig x Missing Resonator

Fig x The return of the Infamous red Circle

Fig x What the Actual Resonator should look like (Picture from my Mega2560)

So I got the parts with which I had successfully programmedthe Atmega on the breadboard.
Had to remove the remnants of the resonator that remained, and the resistor that was connected in parallel to it, so as to be able to solder the bigger Crystal Oscillator.
Fig X This is How the board was. Base of Resonator exists and resistor also soldered

Fig X This is how all things looked with de-soldered components

Fig X This is the circuit that should be at last, soldered onto the board

Note: I could have used a more 'Low Profile' Oscillator, like the one used for the Atmega16U2 on the board, but i did not have that on hand. And i wanted the board working at any cost, so i went with the bigger one only.
Note 2: The resistor connected in parallel to the Resonator is there for stability reasons. It is not needed for the Crystal Oscillator. So removing it is recommended. You can see this resistor in the Fig X of Mega 2560 on the right side of the Resonator. Desolder it.
And I came up with a scheme to solder the Crystalremoving the remnants of the Resonator. And voila! I have a working UNO now.
Removed the (dead) resonator and the resistor connected and in place of that, soldered a Crystal Oscillator with 2 22pF Caps




I hope I have helped maybe 2% of people with the not in sync0x00 error. It took me days of thinking and searching to come to this point,and these were the days I was not tinkering or using the Arduino for what itis, but wasting my time wondering what had gone wrong with the board.
PS: Please dont mind the Pictures, I really did not have this blog in mind when i started the Fixing of the Uno
PPS: Links
USBasp Firmware Upgrade: http://www.nexuscyber.com/boards/topic/1/how-to-use-arduino-uno-upgrade-usbasp-firmware
Arduino Mega and Uno Programming: http://www.gammon.com.au/forum/?id=11637
http://www.gammon.com.au/forum/?id=11635
Minimal Arduino Circuit for Breadboard: http://www.gammon.com.au/forum/?id=11109
Info: https://learn.adafruit.com/arduino-tips-tricks-and-techniques/arduino-uno-faq
Info2: http://jorisvr.nl/arduino_frequency.html
Same Mod: http://forum.arduino.cc/index.php?topic=54621.0
A little Different: http://parkyjimbo.blogspot.in/2014/05/arduino-uno-ceramic-resonator.html
The above link, parkyjimbo's link, was very tempting, as i could have solved the problem with only a single wire. But afraid of stability issues I *might* have faced (USB Timing, very crucial, not to be played with) I went with the addition of Crystal method.
PLUS: My Uno's timings are more accurate now! YAY!
I also found
People in problem, search search and search and you WILL find the solution is what i have learned from this experience.

Happy Coding people!
Comments are closed.