My plight with my year old Arduino Uno started after an
international trip where my Arduino was accompanying me, for project completion
purposes.
After returning, I noticed that something was wrong. No
matter 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 searched
and searched and searched on the internet for possible solutions. At first I
felt 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 your
Arduino.
2.
Open the Arduino software and see that the
proper com port is selected under Tools>Serial Port (you can look for the
correct serial port in Device Manager on a Windows Machine by right clicking
This PC>Properties>Device Manager. Your Arduino should be visible under
‘Ports (COM & LPT)’. Open the list under this category and there you will
find Arduino xxxx (COMX), where xxxx is your Arduino version, ex Mega, Uno,
etc. and X will be your COM Port Number)
3.
Open the Serial Monitor in Arduino
4.
Input a string of characters and you should
receive exactly the same string. For ex, if I input 12355, I should receive
12355 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 problem with
a.
The USB cable
b.
The Atmega16U2’s Firmware
c.
The circuit traces between the Atmega16U2 and
the 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 my
stupidity, I still went on and flashed my Atmega16U2 with a DFU Programmer to
rule out any errors over there.
But again, after flashing the Atmega16U2, I experienced the
same behavior from the board, performing the loopback test again and trying to
upload the code after the firmware flash. Characters were received in the Serial Monitor but the Upload
still complained “not in sync 0x00”.
Turing On Verbose for Upload (For in depth analysis):
Things were starting to get serious now, so I started
searching even harder. The problem with this error is that it can occur for a
number of reasons. Also, it was necessary to get the exact errors that occurred
during 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
The reasons for the errors can be as follows:
a.
No communication between the computer and the
board (Covers 90 percent of the cases)
b.
Wrong COM port selected
c.
Wrong board selected (It is advised to check a
few 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 a
Timeout)
The reason why it was affecting my particular board was not
to 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 reason
was learned the hard way.
In between the bouts of readings, I typically would stumble
upon information that is very necessary to judge the current state of my
Arduino. 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 Reset
button, the LED labelled L on the Arduino (the one connected internally to the
13th pin through a resistor) should blink. That means a bootloader
is 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.
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 reset button while the board is powered through USB or the Power Jack, and see if the LED ‘L’ blinks. If it doesn't, the problem might be
So, to cross out any such problem, you need to push the reset button while the board is powered through USB or the Power Jack, and see if the LED ‘L’ blinks. If it doesn't, the problem might be
a. A Corrupt Bootloader
b. The chip not responding (damaged chip, blown
circuit 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 went on and started looking for resources to burn my bootloader again. I had a spare Mega 2560 I had lying around which I could use to program the board, so I was in luck of being fully equipped, already.
Kicked in the butt by failure
4-5 hours later, after trying a few different burning trials, I was devastated in the face of failure. I was still thinking that it is 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 actually ended up trashing the bootloader on my Mega 2560, and it also started giving the “not in sync 0x00” error. Frustrated, I left the problem, and ordered a USBASP v2.0 LC Technology programmer and 2 bootloaded Atmega 328P-PU MCUs.
4-5 hours later, after trying a few different burning trials, I was devastated in the face of failure. I was still thinking that it is 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 actually ended up trashing the bootloader on my Mega 2560, and it also started giving the “not in sync 0x00” error. Frustrated, I left the problem, and ordered a USBASP v2.0 LC Technology programmer and 2 bootloaded Atmega 328P-PU MCUs.
A packet of Rays of Hope Arrive (Programmer and bootloaded chips)
Fast forward a few days, my programmer and the 2 Atmega328P-PU chips arrived. The Programmer was fine but the packaging in which my Atmegas arrived made me wary of whether the chips were bootloaded at all to even start with. It looked to me like factory packaging, having experience with factory packaging after ordering components from Element14. The first thing I did after that was to pop in the new Atmega328P-PU chip and try to program the board hoping (even though I had never abused the board) that it might be a blown 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 chip
does not work the way it is supposed to. If you can figure out the chip being
bad or good, the weight of the problem then falls on the most critical
components, external, on which the chip’s functioning depends. One such
component is the Crystal, another is the circuit traces. After a lot of playing
around with this board, the initial feeling of the fact that the Crystal might
have 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 just brought. Multiple Arduino versions ranging from 022 to even the 1.5.7 one were used, in case there was something about the Windows 8.1 compatibility. Even tried the different driver versions. The 1.5.7 version I had was one which came bundled with signed drivers for windows 8.1. I even uninstalled all drivers I had and tried all versions of drivers available easily. The latest version, the last version, and another driver not even for the Arduino, but one that people used when the driver signing was not letting people use their Arduino boards on their Windows 8.1 machines. Nothing worked here too.
Breadboard Time
The only option left was for me was to breadboard the Arduino circuit and try and program an Atmega328P-PU from there. Who knows, it might work, was my thinking. So I gathered the components (16MHz Crystal, 2 capacitors, Jumper wire), assembled the circuit on a breadboard and used my programmer to flash the bootloader on. But no, how in the world can it be that 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 of hardware just lying there because of my incompetence in repairing it was something 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 this thing work, my mind almost forgetting the failure I had endured the last two times. 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 always said “Auto set sck time”. And all these timing troubles, well most of them, come from incomplete/incorrect circuits. The programmer I had was the USBASP LC technology v2.0, so I took out a multi-meter to check for grounding. This particular version is 10Pin version.
The pinout is as shown below:
Fig x. ICSP 10-Pin (Left) vs 6-pin (Right)
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 Arduino
has 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 the ground pins were actually grounded. So, if a normal person, like me, would randomly choose from Pin 4,6,8,10 to put the ground pin on the Arduino (ICSP Pin 6), you might not have grounded the Arduino pin at all. That is bad. So many variables to go wrong at, and this programmer can cause this one.
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?
Curious and with a multimeter, in my programmer, I found that not all the ground pins were actually grounded. So, if a normal person, like me, would randomly choose from Pin 4,6,8,10 to put the ground pin on the Arduino (ICSP Pin 6), you might not have grounded the Arduino pin at all. That is bad. So many variables to go wrong at, and this programmer can cause this one.
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 create
a ground.
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. I plugged in the USBASP programmer, put the female header onto the Mega, and
Fig x My Solution to the Ground problem
Modified Cable with Headers labled
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. I plugged in the USBASP programmer, put the female header onto the Mega, and
a.
Tools>Board>Mega 2560 (board to be
programmed)
b.
Tools>Programmer>USBasp
c.
Tools>Burn Bootloader
The Arduino software said Burning Bootloader, this might take a minute. The L LED flashed on the Mega 2560, and no errors, no verbose text was reported in Arduino. So I left it on for 5 minutes or so, then, believing that the process still did not work and from 1 bad Arduino I was officially onto 2 bad ones, 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 my astonishment, the bootloader had been written, and clicking the reset button, blinked the L LED. Meant that the bootloader was now present on the Mega 2560. I checked with Arduino, trying to upload 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 set time” with the Uno, but worked with the Mega. So now I was all set to upgrade the firmware for the USBasp using my newly revived Mega 2560. A few posts and a few errors later, I managed to update the firmware of the USBasp, and now thinking that I had rectified the major problems I was working with last time, I went on to flash 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.
Fig X Wouldnt Fit Arggh
Fig X Shite.
Next, I noticed that the USBasp had reported “Auto sck set time” with the Uno, but worked with the Mega. So now I was all set to upgrade the firmware for the USBasp using my newly revived Mega 2560. A few posts and a few errors later, I managed to update the firmware of the USBasp, and now thinking 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 header
into the UNO, but my design had gone horribly wrong. Improvistion it is, and I
used a few jumper cables to put the header onto the Uno. My heart skipped a
beat when I tried to flash the bootloader the same way I had for the Uno, as it
showed this error
“ avrdude: auto set sck period (because given equals null)
avrdude: error:
program enable: target doesn't answer. 1
avrdude:
initialization failed, rc=-1
Double check
connections and try again, or use -F to override
this check. ”
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 same
error flashed to my face.
What was it? What was the problem? Why my Uno? Why me? Then
I once again looked at the board, closely, focusing on the Resonator. It is
when you have lost everything that you look to follow your instincts. And then
I saw the Resonator on the Mega. Both looked different. And then it occurred to
me. My Uno had no working Resonator. It’s cap had blown off. And only the base
remained, 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 programmed
the 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.
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 Crystal removing the remnants of the Resonator. And voila! I have a working UNO now.
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
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 Crystal removing 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
Everything Hot Glued Together
I hope I have helped maybe 2% of people with the not in sync
0x00 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 it
is, but wasting my time wondering what had gone wrong with the board.
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!
