Friday 21 November 2014

My Fight with "avrdude stk500_getsync(): not in sync resp=0x00" on the Arduino

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. 

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

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.


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.

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.
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.

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.

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.

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!

Sunday 16 November 2014

First things, first



I have been thinking of creating my blog for a long time now.

Finally, with a repair, I got together the thoughts, the electric and magnetic forces, the billions and billions of atoms and molecules inside my head to present to the world, my Art.

I intend to share things that I find fascinating, from electronics to music and everything in between.

Giving my two cents to the world of information, with the motto of helping and sharing and who knows, you might just like what I am all about...