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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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 [hidden email] 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


Reply | Threaded
Open this post in threaded view
|

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

Joerg Wunsch
As Hannes Wallnöfer wrote:

> I send a similar mail to the [hidden email] 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.

The correct place would be [hidden email].

AVRDUDE also has a bug tracker at:

https://savannah.nongnu.org/bugs/?func=additem&group=avrdude

> 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

This is very likely also the reason on the ATmega32M1.

I just fixed it.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)