Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uno WiFi Rev2 - Fuse5 Verify #183

Open
mikrocoder opened this issue Aug 15, 2023 · 5 comments
Open

Uno WiFi Rev2 - Fuse5 Verify #183

mikrocoder opened this issue Aug 15, 2023 · 5 comments

Comments

@mikrocoder
Copy link

mikrocoder commented Aug 15, 2023

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.

avrdude avr_verify() warning: verification mismatch
        device 0xcd != input 0xc9 at addr 0x0005 (error)
avrdude do_op() error: verification mismatch

avrdude done.  Thank you.

Without MegaCoreX package there is only a warning because of wrong fuse.

avrdude: verifying ...
avrdude: WARNING: invalid value for unused bits in fuse "fuse5", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xcd instead of 0xc9 (double check with your datasheet first).
avrdude: 1 bytes of fuse5 verified

I had then read that the fuse problem is known.
arduino/ArduinoCore-megaavr#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?

@MCUdude
Copy link
Owner

MCUdude commented Aug 15, 2023

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.

@MCUdude
Copy link
Owner

MCUdude commented Aug 15, 2023

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.

image

@mikrocoder
Copy link
Author

mikrocoder commented Aug 16, 2023

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.

@SpenceKonde
Copy link
Contributor

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.

@mikrocoder
Copy link
Author

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants