ATMEGA32U4: Extended fuse (E-fuse) weirdness with default values

Using Arduino Microcontrollers
1

Ladies and Gentlemen, today I was turning off the BOD on an ATMEGA32U4. This is not a picoPower device, so this has to be done via the E-fuse settings.

I used the Engbedded Atmel AVR® Fuse Calculator.

The calculator says E-fuse should be oxFF. And the datasheet for the ATMEGA32U4 concurs. Page 354, Table 28-3. Extended Fuse Byte.

Bit 4 - 7 of the register are all 1 by default. So 0xF#.
And if BOD and hardware boot are off, bit 0 - 3 are all 1. So 0x#F.

This yields 0xFF.

Yet during the burning process, AVR dude gives me the following warning:

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.02s

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

avrdude: safemode: efuse changed! Was ff, and is now cf
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

So the 0xFF has become 0xCF.

I noticed this problem before. When I tried to burn my previous settings (0xFE) I also got the same feedback. But it became 0xCE.

Now my device works with the 0xC# settings, so there is no issue. Except that some default values are not what they should be according to the manual. Any ideas why this is the case?

2

Feeling not to smart, as I missed this text on the Engbedded page:

* Note that some numerical values refer to fuses containing undefined bits (set to '1' here). Depending on the target device these fuse bits will be read either as '0' or '1'. Verification errors will occur if the values are read back with undefined bits set to '0'. Everything is fine if the values read from the device are either the same as programmed, or the following values (undefined set to '0'): Extended: 0x0f.

Still would like to know what these bits do. But it is not weird, since it is expected behavior ...

3

I met similar problem, and found solution for my case.

In avrdude.conf file, there are this like
** **write** **
pattern for
** **memory "efuse"** **
in ATMega32U4 part.

    memory "efuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 1 0 0",
                          "x x x x  x x x x  x x x x  i i i i";

Last two
** **x x** **
causes this. I modified it to
** **i i** **
, then I can write 1 for bit4 and bit5 of efuse. As result it became like this.

    memory "efuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 1 0 0",
                          "x x x x  x x x x  x x i i  i i i i";

It might be better use
** **1 1** **
instead of
** **i i** **
.

This is my guess:
** **avrdude** **
send
** **0** **
for
** **x** **
,
and ATMega32U4 chip accepts those it as is, for efuse's bit5 and bit4.

4

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.