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

[Hannes Wallnöfer]

Hello

Appologies if this is the wrong mailing list, it seemed the right one to 
start with.

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, i found the send 
command, combining this with the information about programming of efuse 
in the 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)". Before sending the E-Mail, i 
have tried this method on only one chip and will see if this had side 
effects.

Then, as composing this E-mail, i found that this E-mail list may not be 
the right one (only non-technichal discussion) i did a bit of search and 
by randomly clicking 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):

>_________________________________________________________________________________________________________

#------------------------------------------------------------
# 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?

The previous, direct attempts failed on 3 of my development boards, 
which otherwise work as expected (Firmware that runs CANbus 
communication and a small text based user interface via UART). I am 
using a "Fischl" original programmer and tried with both the slow and 
fast jumper setting. Before and after my attempts to write to efuse, i 
was successfully able to write around 16kB of firmware. I run arch linux 
with "avrdude: Version 6.3, compiled on May  8 2019 at 19:46:05".

Any direct help and thoughts or pointers to where i could go with this 
issue are appreciated.

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