Go Down

Topic: Atmega (any chip) Device Signature issues and stk500_getsync()(resolutions) (Read 41683 times) previous topic - next topic


Hello all! This is my first topic created here, but anywho: I wanted to give some folks a heads up on what I have found a resolution for a common issue pertaining to using the Arduino board with the ArduinoISP sketch. This does not have anything to do with the sketch itself mind you, but after banging my head on using avrdude and Arduino as avrisp to program an Atmega32L chip on a breadboard for oh... 6 days straight, I finally figured out the problem, and wanted to outline resolutions to this issue.

Here is the issue:

C:\WinAVR-20100110\bin>avrdude -p Atmega32 -c avrisp -P com4 -b 19200

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.14s

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

Also this can happen randomly:
C:\WinAVR-20100110\bin>avrdude -p Atmega32 -c avrisp -P com4 -b 19200
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.

I have done sooooo much just to find out what the problem is that everyone is having.

1. CHECK YOUR WIRES! This can be common but most people that will see this thread will have probably already done so and found that the wires/configuration on the board is NOT at fault

2. Use a crystal (2, 4, or 8mhz preferrably). It's possible you changed the fuses in the chip and changed the configuration from the internal resonator inside the chip, to using xtal1 and xtal2 (on chip not on arduino board). Also use 2x 22pF capacitors tied to ground.

3. Ensure you are using the right com, serial, or USB selection when using avrdude.

4. DO NOT USE -F in avrdude!!! Evidently there is an error somewhere and (even though I believed otherwise before finding out the next bit of info) even if you CAN read the fuses of the chip or flash to it doesn't really mean that everything is set up right and that it will work properly. If you get the dreaded: Device signature = 0x000000, or Device signature = 0xFFFFFF, OR another thing I was getting was random jibberish: Device signature = 0xfF14f3; Device signature = 0x077ffA; etc. then that means that something is wrong and it will bite you later if you ignore it.

5. Here is another MAJOR step. This shouldn't really be a problem with a low power chip such as the AtTiny or anything with a power requirement below 2 to 3 volts, HOWEVER what I have found that people are doing (including me. I am not out of this loop) is that they are trying to feed the power off of the 5v of the Arduino board to power the chip that they are programming. THIS WILL NOT WORK! I don't know how much power it is actually feeding to the chip from that 5v output, but it can't be enough for a chip (like the Atmega32) that requires at least 4.5v *which funny enough, I am using the Atmega32L which only requires 2.7v* because what fixed all the problems I had with the device signature being wrong and random signatures, is to just go out, buy the 5v regulator and two 10uF capacitors to use it with, and make a power pack out of 4x AA batteries or a 9v and snap. After that it showed up fine without ANY issues whatsoever. It wont add much to your project (batteries are more expensive than anything. I bought the 5v regulator and the two capacitors yesterday from Radio Shack for > $4.00. You will need it anyway for your project so just go get it. I can't stress this one enough because this was my problem all along and I am a newb. Heck even some advanced strict avr (non arduino) folks have struggled with this.

6. One other issue is a possibility that there is not enough power going to the Arduino board. I actually have to feed, not just the power through usb to the Arduino board but also connect +5 and GND from my power rails on my breadboard to the Arduino for it to function properly. Maybe that is just an issue for my one board as far as not receiving enough power through usb, but that is what I have traced to the avrdude: stk500_getsync(): not in sync: resp=0x00 issue that I have had randomly as well.

7. Strangely enough sometimes you just happen to get a chip that is stubborn when you do not erase the flash on the chip first. It's easy. Just make sure to put -e (for erase) before either unlocking fuses or flashing bootloaders, or code. However, if you JUST FLASHED a bootloader and are trying to lock the bootloader fuse, DO NOT erase chip because..... You'll just erase your bootloader and THEN it will lock it... Very un-productive :P
I hope that this helps everyone still out there getting these errors. I will be posting pics soon of my configuration.


hexskrew, Thanks! for taking the time to document this... Maybe we can end up with a short document with all your steps. TOO many people are asking for help and fighting the same stuff....


My name is Yoshua Nava. I am from Caracas, Venezuela. I am part of a group of 4 people from Andres Bello Catholic University who are working on the designing and construction of a line follower robot based on the Sanguino plataform for CCSBots2013 robotics competition.
Today I only registered to say thank you, man. We were really confused because the ATmega644 chip wasn't being programmed by our Arduino, and as soon as we read your post, all our problems dissapeared. Awesome work.

I would like to explain how we programmed the ATmega644 with our Arduino UNO R3, so we can help any other person that has doubts on it. This are the steps we followed:

1) Burn the ArduinoISP example that comes integrated with the Arduino IDE on your Arduino UNO R3.

2) Wire the Arduino UNO to the ATmega644 as it is exposed in this page: http://reprap.org/wiki/Burning_the_Sanguino_Bootloader_using_Arduino_as_ISP

3) Install the Arduino IDE v1.0.4.

4) Download the official Sanguino package Sanguino-0101r1.zip from https://code.google.com/p/sanguino/downloads/list , unzip its content (sanguino folder) and copy it in the <<hardware>> folder inside Arduino 1.0.4 main folder.

5) Create an empty file called "ATmegaBOOT_168_atmega644.hex" in Arduino 1.0.4/hardware/sanguino/bootloader/atmega. Copy the content of this GitHub file https://github.com/Lauszus/Sanguino/blob/master/bootloaders/atmega/ATmegaBOOT_168_atmega644.hex into the new file we created.

6) Open the file boards.txt inside Arduino 1.0.4/hardware/sanguino, and add the following lines:


atmega644.name=Sanguino W/ ATmega644




7) Open the file programmers.txt inside Arduino 1.0.4/hardware/sanguino, erase all the lines starting with "arduinoisp", and add the following lines instead:

arduinoisp.name=Arduino as ISP / Sanguino

8)  Open the file Arduino.h inside Arduino 1.0.4/hardware/sanguino/cores/arduino, and replace line 49 with the following:

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644__)

9) Start the Arduino IDE (restart it, if you had it already open), select Tools->Boards->Sanguino W/ ATmega644. Then, select Tools->Programmer-> Arduino as ISP / Sanguino. Finally, select Burn Bootloader, and wait untill the process finishes (Do not disconnect a single thing)

(We hope this may be useful. If anyone has any doubts, we would be glad to help. We don't know much, but we would try to make an effort to help. Contact us by a private message.)

Go Up