Normally I use a PC and AVR studio for burning bootloaders, because it's way faster and has a host of information and useful options, but I have a hosed PC right now. I have encountered this signature error off and on with AVR dude (another reason to use the PC) but ususally it was only a chip or two that would balk (and they would always program OK with AVR studio which also checks sigs, so something is slightly fishy with AVRdude in this department I think.

The batch of chips I have now refuses to program at all, so something has changed.My setup is Mac OS 10.4.11, Arduino11 AVRmkII,

burning on a BBB with a resonator, and zif socket. The green light is on on the mkIIwonder if heat is an issue? no AC in my office

Without modifying the programmer file, I get

avrdude: Expected signature for ATMEGA168 is 1E 94 06 Double check chip, or use -F to override this check.

Put in the old chip, and it burns fine. Try the new chip again - NADA.

Swap setups and try old chip in my zif setup - burns fine.

So it kind of looks like the chip is the smoking gun at this point.Chip is marked ATMEGA168-20PU just like the old one, although Atmel seems to have gone to some kind of different marking system that is lot harder for geezers to read. They came from Digikey so I'm puzzled at that - Maybe Atmel added a new sig for ROHS or something?

But that still doesn't expain what AVR dude is up to on the new chip - unless I somehow got a bad batch of chips, which I consider unlikely.

This together with teenager-download-infected-generic-PC-with-no-support-at-90 degrees is causing me to have a fun day

Any resolution on this? I'm seeing the exact same behavior on my macbook pro running 0012 alpha and using the AVR ISP mkII... Both chips show ATMEGA168-20PU on top, but the one that programs says 0701, while the ones that will not program show 0744.

I tend to program a lot of chips at one time so I just use AVR studio which is much faster and more convenient. The curious thing about this is that chips on which Arduino gags program fine with AVR studio and I have signature checking turned on in that software. Some kind of AVRdude issue probably.

Hey Paul,I've finally got a solution to my problem (which I'm hoping is the solution to your problem as well If you've already tried the following, I apologize, but this is what worked for me...When I ordered the chips from Digikey, they came with the fuses set in the atmel default configuration which is DIFFERENT than what is set on the Arduinos (by default they are set to use the internal osc. instead of the external crystal on the arduino, they don't have the bootrst set, no brownout, etc).So, when avrdude tries to read the device signature, the default 500kHz bitrate is too high, so you get back a garbage signature (sometimes it gets lucky and it read correctly, but mostly it was just garbage)You have to lower the mkII's ISP freq to a speed supported by the default chips, fix the fuse settings, and then crank the speed back up on the mkII. Once you do that the chips work fine with the Arduino environment. I've been programming them all afternoon without hitch.Here's the steps:(FYI, I'm using AVR studio on Windows XP with a AVRISP mkII and an Arduino Diecimila powered via a wall wart)1. Open AVR studio and go to Tools->Program AVR-Connect2. Select your programmer and hit connect3. Under the "Main" tab, click the Settings box (under Programming Mode and Target Settings)4. Change the ISP Freq: to the lowest possible (51.1 Hz). Click Write to write the new ISP freq setting to the mkII, and then Read to double check that it wrote correctly. Then click close.5. Click the "Fuses" tab and make sure that they are exactly like below (I got these from reading the fuse settings on a working arduino):BOOTSZ - Boot Flash size=1024 words start address=$1C00BOOTRST- checkRSTDISBL- unckeckDWEN - uncheckSPIEN - (this is checked with a question mark, I can't check or uncheck this, just leave it as is)WDTON - uncheckEESAVE - uncheckBODLEVEL - Brown-out detection at VCC=2.7VCKDIV - uncheckCKOUT - uncheckSUT_CKSEL - Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65ms (this was at the very bottom of the list)

EXTENDED - 0xF8HIGH - 0xDDLow - 0xFF

6. Click Program to write the fuse settings. You should see the status box say OK! after writing and verifying the fuse settings.7. Go back to the main tab and change the ISP freq back up to 500kHz. 8. Go to program, choose your bootloader, and it should program just fine!9. Open the Arduino environment and test it out to make sure it works. You're done!

If somebody can verify that these are valid instructions, a link should probably get posted on the bootloader page (http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader). I spent a couple hours on google trying to fix this after reading that page, and it would have been nice to know about this earlier instead of wondering why the stupid thing wouldn't program

One final thing. The fuse settings are dependent upon the Arduino hardware you're running. For example, on the Diecimila, the SUT_CKSEL is "Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65ms", while on the Pro I got from Sparkfun.com it is set to "Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms."Also, on the Pro, the LOW is set to 0xC6 instead of 0xFF. I haven't had a chance to read the datasheet yet to figure out what all this means, just wanted to point out that the settings I posted earlier are for the Diecimilia.

Instead of starting a new thread I thought I'd add my problem here as it is similar. I'm suing an ATMEGA 8 on Diecimla. I do not have any AVR programmer for bootloading. Hence I wired up the parallel port adapter found on the arduino bootloader page and installed giveio. The printer port is recognised. The green and yellow lights on the diecimla board are ON. But after Choosing the Diecimla option in the Arduino software, when I try to burn the bootloader using the parallel programmer option I get the same error as Paul: Invalid signature. Expected signature for ATMEGA168 is 1E 94 06.If instead I choose the ArduinoNG or older with ATMEGA8 option in the Tools section and try to burn, I get the same erro message but with Expected signature for ATMEGA8 is 1E 83 07.The preferences.txt file has no upload.using statement, hence I added this. But I don't know the exact syntax to put in for the parallel programmer name, id, etc., as you have indicated by Paul for the AVRispmkII. I'm using a 16MHZ crystal. I have also added the registry fix for 'DisableWarmPoll' as suggested on the arduino site.

I desperately need to burn the bootloader to my ATMEGA8. Help will be very much appreciated. Sorry about any typos.regdsBala C

I've never had much of an issue with programming chips with AVR studio but I am aware of the speed settings. I just use 125k which doesn't ever seem to generate errors. As far as I can see, that setting only affects the MKII, but I could be wrong about that.

After I've got them programmed on AVR studio, I really don't have any reason for using the MKII in the Arduino environment, but maybe having the MKII set slower would cure the problem there.

As to the bootloader settings, it would be nice to see some discussion and docs of various choices. What I've discovered is that some of the stuff is really important (divide clock by and some of it just doesn't matter much (oscillator settings) except in fairly obscure circumstances.

The original Arduino bootloader for example used brownout detection off, but I think they changed it when they had issues with NG's that wouldn't start sketches. This is a setting that does have a ramification because it controls how easily the chip resets. Higher settings might prevent flash from getting corrupted but also make the uC more sensitive to power line glitches from heavy current draw, DC motors and the like.