avrdude fuse verification bug?

Other Hardware 3rd Party Boards
1

avrdude 6.0.1/Linux + ArduinoISP + ATmega328p

When I read controller state output is

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 5

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:DF, L:FF)

Values in last line seems swapped relative to previous output.

And it is valid that five high bits of efuse are not shown? In datasheet this bits are shown as 1.

2

avhohlov:
avrdude 6.0.1/Linux + ArduinoISP + ATmega328p

When I read controller state output is

avrdude: Device signature = 0x1e950f

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 5

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:DF, L:FF)




Values in last line seems swapped relative to previous output.

And it is valid that five high bits of efuse are not shown? In datasheet this bits are shown as 1.

The swapped fuse bytes looks like a bug in avrdude (just a display bug).

You can make the unused bits come out as zero or one depending on the avrdude.conf entry.

And people don't agree on which way to do it, btw- some avrdude.conf entries floating around the internet return ones for unused fuse bytes. Verification fails if you assume one way in your boards.txt entry, but do it the other way in avrdude.conf, too. Discovered while working with my tiny cores)

3

those are just a couple of the "features" that imo make avrdude one of the most dangerous of popular utilities. there are versions out there that do not suffer from the reversed fuse issue but none afaik to deal with that 1=0 thing. some experts seem to agree with creator/maintainer that there are no real problems but ive personally seen noobs kill chips as a result.

it might be worth it to dig in and fix if source and build were not such a complicated mess and most likely ignored by the community anyway. personally i use other methods when possible and when not i ignore whatever dude has to say on the subject of fuse values. i also take special care to hit ctl-c whenever asked anything about "restore previous value".

4

in avrdude main.c i found this code

    if (quell_progress < 2) {
      fprintf(stderr, "%s: safemode: ", progname);
      if (failures == 0) {
        fprintf(stderr, "Fuses OK (H:%02X, E:%02X, L:%02X)\n",
                safemode_efuse, safemode_hfuse, safemode_lfuse);
      }
      else {
        fprintf(stderr, "Fuses not recovered, sorry\n");
      }
    }

It is seems that format string must be

"Fuses OK (E:%02X, H:%02X, L:%02X)\n"

And in avrdude 6.1 it is changed:

    if (quell_progress < 2) {
      fprintf(stderr, "%s: safemode: ", progname);
      if (failures == 0) {
        fprintf(stderr, "Fuses OK (E:%02X, H:%02X, L:%02X)\n",
                safemode_efuse, safemode_hfuse, safemode_lfuse);
      }
      else {
        fprintf(stderr, "Fuses not recovered, sorry\n");
      }
    }
5

I agree that it appears to be some sort of a bug. It is probably worth filing a bug for this.

You can file a bug report here:
http://savannah.nongnu.org/bugs/?group=avrdude&func=additem

--- bill

6

From avhohlov's post, it sounds like it is fixed in latest avrdude already...

7

DrAzzy:
From avhohlov's post, it sounds like it is fixed in latest avrdude already...

I had a hard time telling telling which version had the problem, Old vs new from what was posted in post #3 since it didn't specify which version the first code block was from.

It does look like it was fixed in 6.1