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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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