Go Down

Topic: Bootloader burning, bad signature,  -F (Read 14790 times) previous topic - next topic


Jul 18, 2008, 06:57 pm Last Edit: Jul 18, 2008, 06:59 pm by paulb Reason: 1
I'm trying to burn bootloaders with Arduino 11 and getting wrong signature errors.

Where do insert -F to turn off signature checking?

I tried the makefile in the hardware/bootloaders/Atmega168 folder


Code: [Select]
ISPFUSES    = avrdude -F -c $(ISPTOOL) -p m168 -P $(ISPPORT) $(ISPSPEED) -e -u -U lock:w:0x3f:m -U efuse:w:0x00:m -U hfuse:w:0xdd:m -U lfuse:w:0xff:m
ISPFLASH    = avrdude -F -c  $(ISPTOOL)  -p m168 -P $(ISPPORT) $(ISPSPEED) -U flash:w:$(PROGRAM)_$(TARGET).hex -U lock:w:0x0f:m


Code: [Select]
ISPFUSES    = avrdude -c $(ISPTOOL) -F -p m168 -P $(ISPPORT) $(ISPSPEED) -e -u -U lock:w:0x3f:m -U efuse:w:0x00:m -U hfuse:w:0xdd:m -U lfuse:w:0xff:m
ISPFLASH    = avrdude -c  $(ISPTOOL)  -F  -p m168 -P $(ISPPORT) $(ISPSPEED) -U flash:w:$(PROGRAM)_$(TARGET).hex -U lock:w:0x0f:m

worked. I imagine that some other scheme is going on though to parse out programmers.txt and boards.txt

I'll be happy to write up some docs on this if I get it solved.



Yeah, the page on burning the bootloader is badly dated at this point, so updates to it would be great.  

To enable the -F option, you set the .force parameter on the programmer you're using in the programmers.txt file.  For example, the parallel port programmer has it enabled by default:


What setup are you using, though?  It's weird to get signature errors when burning the bootloader.


Jul 18, 2008, 10:42 pm Last Edit: Jul 18, 2008, 10:44 pm by paulb Reason: 1
Thanks for the reply David,

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

after modifying programmers.txt,

avrispmkii.name=AVRISP mkII

I get

avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: verification error, first mismatch at byte 0x0000
        0x3f != 0x01
avrdude: verification error; content mismatch

So I get out a Diecimila and burn it with the chip included and it burns fine.
Try a new chip and

avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: verification error, first mismatch at byte 0x0000
        0x3f != 0x01
avrdude: verification error; content mismatch

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




If you want one of these chips to test with - I'll be happy to send a couple by. Just send me your address again.

Maybe this is some new condition AVRdude hasn't seen before or maybe the "force" isn't working the way you think it is, and because the sig always lines up, it goes through fine anyway.

How do you turn on verbose mode?



The plot thickens: AVR studio reads the sig on the chips as 1E 94 06

Waz up w dat!


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 never got to the bottom of this issue.

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.

I couldn't seem to get signature checking turned off in Arduino.

You need a PC though, for AVRstudio.

paul badger


Interesting, it sure sounds like an issue with the bundled avrdude



Nov 03, 2008, 12:43 am Last Edit: Nov 03, 2008, 07:21 am by lotharsmash Reason: 1
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-Connect
2.  Select your programmer and hit connect
3.  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=$1C00
BOOTRST- check
RSTDISBL- unckeck
DWEN - uncheck
SPIEN - (this is checked with a question mark, I can't check or uncheck this, just leave it as is)
WDTON - uncheck
EESAVE - uncheck
BODLEVEL - Brown-out detection at VCC=2.7V
CKDIV - uncheck
CKOUT - uncheck
SUT_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)

Low - 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!



Btw, you shouldn't need to enable the forcing options either since it should now read the correct device signature.


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.


Hi Lothar and Paul,

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.
Bala 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 8) 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.


Go Up