avrdude failing to verify fuses

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am running avrdude from a batch file with the following command.

avrdude -p ATMEGA328P -c avrispmkII -P usb -V -U flash:w:"AVRXXX.hex":i -U flash:v:"AVRXXX.hex":i -u -U efuse:w:"0xfd":m -u -U hfuse:w:"0xd9":m -u -U lfuse:w:"0xff":m -u -U efuse:v:"0xfd":m -u -U hfuse:v:"0xd9":m -u -U lfuse:v:"0xff":m

I have 2 targets that I an using, an ATTiny 84 and an ATMega328p. obviosly the part, fuse settings and hex file are changed for each target. Everyting works fine with the Tiny84 but the when i run it on the Mega328p it fails when it tries to verify the fuses. Is there something special about that part or am I just missing something?

Last Edited: Mon. Mar 18, 2013 - 06:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are the two chips clocked in exactly the same way?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes they both have an external 16.384M crystal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your attempt to enable DWEN did actually succeed.
So that has ruined any chance of using ISP.
You can't communicate properly with debugWIRE because you have a capacitor on the RESET line.

Remove it, and life will be wonderful !

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Your attempt to enable DWEN did actually succeed.

-U hfuse:w:"0xd9":m

For mXX8 this leaves DWEN unprogrammed.
Perhaps you should test it one by one to know which verification failed.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,
I think your reply must have been meant for my other thread about the problems I was having with the debugwire interface. No capacitor on the reset line. I am working with a finished product with a hole drilled in the case for the wires from the board to an external isp header and one of the wires broke off internally. I since learned from the Atmel FAE that is is possible to disable the debugwire fuse with the JTAG by starting a debug session and selecting "Disable debugWIRE and Close" from the Debug menu. of course you have to be able to start a debug session.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I since learned from the Atmel FAE that is is possible to disable the debugwire fuse with the JTAG

You didn't. It is not possible to disable DWEN with JTAG.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think by "the JTAG" he means "the OCD interface" not actual use of JTAG signalling/protocols.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I am debugging with a JtagICE MKII in Atmel Studio 6 using the 6 pin isp adapter and debugwire. That issue is from another thread and has been resolved. Here I am concerned with programming using an AVRISP MKII and avrdude. I am using the batch file listed in my first post for 2 different targets.(Of course the processor, file name, and fuse settings are different.) On a Tiny84 all works fine but when I run it on a Mega328p the fuse writing fails on the first fuse. Here is the result(I left out the flash programming since that works fine.)

Reading | ################################################## | 100% 1.70s

avrdude: verifying ...
avrdude: 8166 bytes of flash verified
avrdude: reading input file "0xfd"
avrdude: writing efuse (1 bytes):

Writing |                                                    | 0% 0.00s ***faile
d;
Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xfd:
avrdude: load data efuse data from input file 0xfd:
avrdude: input file 0xfd contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xfd != 0x05
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Press any key to continue . . .

an here is the result from the Tiny84

avrdude: verifying ...
avrdude: 346 bytes of flash verified
avrdude: reading input file "0xff"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xff:
avrdude: load data efuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xdd"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdd:
avrdude: load data hfuse data from input file 0xdd:
avrdude: input file 0xdd contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: verifying efuse memory against 0xff:
avrdude: load data efuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: verifying hfuse memory against 0xdd:
avrdude: load data hfuse data from input file 0xdd:
avrdude: input file 0xdd contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude done.  Thank you.

Press any key to continue . . . 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I actually meant to post this to the GCC forum since it is more of an avrdude issue than an AVR one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
avrdude: verification error, first mismatch at byte 0x0000
         0xfd != 0x05 

As you might have noticed, the efuse only uses the lowest 3 bits. e.g. 0x05 is the same as 0xFD.

Depending on who wrote the avrdude.conf entry, it either expects to read all 8 bits or just the 3 relevant bits.

The easiest fix is simpy to use:

-U efuse:w:0x05:m

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hadn't even thought of that. So the Tiny84 entry handles it differently than the Mega328p entry. I tried 0x05 and it worked, thanks. The avrdude.conf file is from the latest version of the winavr instalation WinAVR-20100110

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It also appears that avrdude verifies the fuses automatically so I don't need to explicitly verify them after programming. Is that correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. Unless you use the -V switch.

The configuration behaviour is fairly easy to understand. Just look at a typical entry.

You can either read and write the 'unused' fuse bits or you specify that they should be ignored. Or you specify that they are always read/written as 1.

Of course the AVR does not mind. After all, those are 'unused' bits. However the punter has to use the same approach as the 'conf' author.

David.