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=0x00avrdude done. Thank you.
I have done sooooo much just to find out what the problem is that everyone is having.
-
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
-
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.
-
Ensure you are using the right com, serial, or USB selection when using avrdude.
-
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.
-
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.
-
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.
-
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
I hope that this helps everyone still out there getting these errors. I will be posting pics soon of my configuration.