[bug #47616] Extended fuse verification error atmega128rfa1

[avrs-admin]

Armin <None> Mon 04 Apr 2016 12:09:57 PM UTC

I use a raspberry pi with avrdude (avrdude version 6.3-20160220 (compiled) and 6.1 (from package) tested) to program a atmega128rfa1. I am currently using a AVRISP mkii but because it is unavailable I am looking into using the Atmel-ICE programmer.

I have some funny behavior with the Atmel-ICE programmer (avrdude 6.1 and 6.3). When I try to burn the fuses I get a verification error of the efuse (I want it to be 0xfe and 0xf6 is written). When I use the AVRISP mkii I can burn the fuses with avrdude 6.1 but not with 6.3 (verification error).

I think it is a simple bit masking error. The extended fuse only has bit 0,1,2 user configurable bit 3 has a description “Do not modify” with the default value of 1.

Command (avrdude 6.1): avrdude -p m128rfa1 -c atmelice_isp -P usb -B 32 -U lfuse:w:0xf7:m -U hfuse:w:0xd1:m -U efuse:w:0xfe:m

Output (only the error part): avrdude: verification error, first mismatch at byte 0x0000 0xf6 != 0xfe avrdude: verification error; content mismatch

When I use the old and trusted AVRISP mkii  with avrdude 6.1 everything works Command (avrdude 6.1 only, 6.3 give the error above): avrdude -p m128rfa1 -c stk500v2 -P usb -B 32 -U lfuse:w:0xf7:m -U hfuse:w:0xd1:m -U efuse:w:0xfe:m

Output: avrdude: 1 bytes of efuse verified

This issue was migrated from https://savannah.nongnu.org/bugs/?47616

[mcuee]

So there seems to be two issues here. One is regression from 6.1 to 6.3 for AVRISPmkii. The other is problem with Atmel ICE (both 6.1 and 6.3).

Not so sure if these two issues are still valid or not.

[mcuee]

It may be related to user signature row feature (for some AVR chips) missing in avrdude. https://github.com/avrdudes/avrdude/issues/379

Edit: probably not.

[mcuee]

@jkent

Sorry to ping you here, Since you have the ATmega128RFA1, just wondering if you have the issue with efuse verification error or not. Thanks.

[mcuee]

Help wanted from the community to check whether the issue still exists. PR is welcome.

[mcuee]

@stefanrueger

Just FYI here. -c dryrun does not help here as it seems to be specific to the programmers.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -p m128rfa1 -c dryrun -U lfuse:w:0xf7:m -U hfuse:w:0xd1:m -U efuse:w:0xfe:m
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1ea701 (probably m128rfa1)

avrdude: processing -U lfuse:w:0xf7:m
avrdude: reading input file 0xf7 for lfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xf7
avrdude: 1 byte of lfuse verified

avrdude: processing -U hfuse:w:0xd1:m
avrdude: reading input file 0xd1 for hfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xd1
avrdude: 1 byte of hfuse verified

avrdude: processing -U efuse:w:0xfe:m
avrdude: reading input file 0xfe for efuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte efuse ...
avrdude: 1 byte of efuse written
avrdude: verifying efuse memory against 0xfe
avrdude: 1 byte of efuse verified

avrdude done.  Thank you.

[stefanrueger]

I would wager that this is no longer an issue. This part's efuse now defines initval = 0xff (factory setting) and bitmask = 0x07. I am pretty sure AVRDUDE treats this part like any other part, eg, the m328p (where this is not an issue with usbtiny):

$ avrdude -p ATmega128RFA1/St | grep efuse.initval
.ptmm	ATmega128RFA1	efuse	initval	0xff

$ avrdude -p ATmega128RFA1/St | grep efuse.bitmask
.ptmm	ATmega128RFA1	efuse	bitmask	0x07

Should the observed behaviour still be the case then it would be that the (physical) programmer masks the bits in a different way (and AVRDUDE would not be ble to do anything about that).

I suggest closing this issue.

[mcuee]

Okay, I will close this issue now.

We can always re-open if necessary in the future.