Attempting to modify efuse with avrdude and Atmega32m1 seems to be unsupported by standard means?

[Hannes Wallnöfer]

Dear AVR-libc Devs

I send a similar mail to the avr-chat@nongnu.org but we where not able 
to resolve the issue. I thought I should give it a try here as well 
since the problem still occurs and it may be a bug somewhere. Apologies 
if this is not the right place, maybe someone could give a pointer in 
that case.

When trying to write to efuse on a Atmege32M1 (Marking on chip: 
MEGA32M1-AU). Avrdude seems to write and verify 0 bytes. No errors, 
efuse seems to remain unchanged:
-_________________________________________________________________________________________________________ 


# avrdude -c usbasp -p m32m1 -U efuse:w:0xfe:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9584 (probably m32m1)
avrdude: reading input file "0xfe"
avrdude: writing efuse (0 bytes):

Writing | ################################################## | 100% 0.00s

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

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 0 bytes of efuse verified

avrdude: safemode: Fuses OK (E:FF, H:D9, L:FF)

avrdude done.  Thank you.
_________________________________________________________________________________________________________-


Writing to lfuse and hfuse is effective, as i am relying on switching 
the clock source to use an external Chrystal to get a 16MHz IO clock. 
Here is how writing to lfuse looks like:
-_________________________________________________________________________________________________________ 


# avrdude -c usbasp -p m32m1 -U lfuse:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9584 (probably m32m1)
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: safemode: Fuses OK (E:FF, H:D9, L:FF)

avrdude done.  Thank you.
_________________________________________________________________________________________________________-


During research of the problem, found that avrdude offers a terminal 
mode. In oder to gain more of an understanding of the issue, i tried to 
dump the efuse memory location manually, which failed, followed by using 
the same command on lfuse and hfuse, which printed the expected fuse 
values:
-_________________________________________________________________________________________________________ 


# avrdude -c usbasp -p m32m1 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9584 (probably m32m1)
avrdude> dump efuse 0 1
>>> dump efuse 0 1
avrdude (dump): address 0x00000 is out of range for efuse memory
avrdude> dump lfuse 0 1
>>> dump lfuse 0 1
0000  ff |.               |

avrdude> dump hfuse 0 1
>>> dump hfuse 0 1
0000  d9 |.               |

avrdude>
_________________________________________________________________________________________________________- 



My goal is to enable the 4.5V brown out functionality by writing 0xfe to 
efuse.
Learning about the send command form avrdudes man page and combining 
this with the information about programming the efuse in the Atmega32M1 
Data sheet, i attempted to change efuse manually, first reading it, then 
writing the new value and finally reading it back and it seemed to work, 
but i got a warning when leaving the terminal mode and avrdudes safemode 
claimed the efuse was FF:
-_________________________________________________________________________________________________________ 

avrdude -c usbasp -p m32m1 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9584 (probably m32m1)
avrdude> send 0x50 0x08 0x00 0x00
>>> send 0x50 0x08 0x00 0x00
results: 00 50 08 ff

avrdude> send 0xAC 0xA4 0x00 0xFE
>>> send 0xAC 0xA4 0x00 0xFE
results: 00 ac a4 00

avrdude> send 0x50 0x08 0x00 0x00
>>> send 0x50 0x08 0x00 0x00
results: fe 50 08 fe

avrdude> quit
>>> quit

avrdude: safemode: efuse changed! Was ff, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:FF, H:D9, L:FF)
_________________________________________________________________________________________________________-


Using the terminal mode again, running the send command for reading 
efuse revealed that it still was set to the desired vallue: fe. Exiting 
the terminal mode now for the second time did not bring up any warning 
and indicated that the desired value now is present in efuse: "avrdude: 
safemode: Fuses OK (E:FE, H:D9, L:FF)".

This method seemed to have worked on around 6 of my baord now.

I did a bit of research and by randomly clicking on seemingly 
irrelevant, but related links, I ran into this post: 
https://lists.gnu.org/archive/html/avrdude-dev/2020-04/msg00000.html

Checking my /etc/avrdude.conf, searching for "m32m1", i indeed found 
this section, missing a size parameter altogether (Line 8687 (At the 
time when i checked a few months ago)):
-_________________________________________________________________________________________________________ 


#------------------------------------------------------------
# ATmega32m1
#------------------------------------------------------------

part parent "m328"
    id              = "m32m1";
    desc            = "ATmega32M1";
    # stk500_devcode    = 0x;
    # avr910_devcode    = 0x;
    signature       = 0x1e 0x95 0x84;
    bs2             = 0xe2;

    memory "efuse"
        read            = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
                          "x x x x x x x x o o o o o o o o";
        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";
    ;
;
_________________________________________________________________________________________________________- 


The parent Atmega328 does too have an efuse section with specifications 
for min and max write delay as well as a size declaration (size = 1). 
Maybe the lack of this information in the Atmega32m1 section is an issue?

--
Med venlig hilsen / Best regards
Hannes Wallnöfer