Closed mikrocoder closed 1 month ago
A quick fix would be to edit the boards.txt file and use 0xcd instead of 0xc9. However, in the latest Avrdude 7.2 version that MegaCoreX will use in the next release, this issue has been resolved:
$ avrdude -cxplainedmini_updi -patmega4809 -Usyscfg0:w:0xc9:m
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9651 (probably m4809)
avrdude: processing -U syscfg0:w:0xc9:m
avrdude: reading input file 0xc9 for fuse5/syscfg0
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse5/syscfg0 ...
avrdude: 1 byte of fuse5/syscfg0 written
avrdude: verifying fuse5/syscfg0 memory against 0xc9
avrdude warning: ignoring mismatch in unused bits of syscfg0
(device 0xcd != input 0xc9); to prevent this warning fix
the part or programmer definition in the config file
avrdude: 1 byte of fuse5/syscfg0 verified
avrdude done. Thank you.
What's really happening is that the on-board programmer has a built-in "safe-mask" that prevents the user from writing incorrect fuse values.
This is enabled by default on the Uno Wifi Rev2, but can very easily be turned off using Avrdude directly.
From the Avrdude source code:
// SUFFER bits
// Bit 7 ARDUINO: Adds control of extra LEDs when set to 0
// Bit 6..3: Reserved (must be set to 1)
// Bit 2 EOF: Agressive power-down, sleep after 5 seconds if no USB enumeration when set to 0
// Bit 1 LOWP: forces running at 1 MHz when bit set to 0
// Bit 0 FUSE: Fuses are safe-masked when bit sent to 1 Fuses are unprotected when set to 0
The default SUFFER register value on the Uno Wifi Rev2 is 0x7F, but needs to be changed to 0x7E. This is how you'd do it:
/path/to/avrdude.exe -C /path/to/avrdude.conf -c xplainedmini_updi -p atmega4809 -x suffer=0x7e
The new SUFFER register value will be permanently stored.
Hi,
Do I understand this correctly. It is changed avrdude for the Uno WiFi Rev2 to ignore the wrong fuse? Why Arduino does not change the fuses in their boards?
Thanks for the information.
I think the root of this problem is that the conventions for specifying the unused bits of a fuse have changed repeatedly, and even Microchip doesn't seem to have known what they wanted, as their initial datasheets specified unused bits incorrectly.
However, they also put that safemask feature into mEDBG that blocks certain pins.
Also, WTF @ the SUFFER register. How do they manage that? Like, it's specified as an offset as though it's an SFR in the extended I/O space. How can that influence mEDBG? Unless they have done some real dark magic, they must have mEDBG intercept a write to that address when it's used as part of UPDI programming? Wacky. Also, WTF @ "SUFFER" getting past management and marketing.
Thanks.
Hello,
I would like to ask something for someone. It is about an ARDUINO UNO WiFi REV2. When he wants to flash a program with your MegaCoreX package it does not work. The flashing aborts because of wrong fuse. IDE is an unchanged v1.8.19.
Without MegaCoreX package there is only a warning because of wrong fuse.
I had then read that the fuse problem is known. https://github.com/arduino/ArduinoCore-megaavr/issues/119 Did Arduino flash the first boards wrong? Or where did the wrong fuse come from? I have only the Nano Every. There are no problems with it. Is there a solution for the wrong fuse on the UNO WiFi REV2 when using your MegaCoreX?