facchinm
commented
2 years ago I completely agree that changing FUSE5 (SYSCFG0) in the core is the right solution. Would you mind creating the PR too? Thanks!
Open per1234 opened 2 years ago
facchinm
commented
2 years ago I completely agree that changing FUSE5 (SYSCFG0) in the core is the right solution. Would you mind creating the PR too? Thanks!
per1234
commented
2 years ago @facchinm I'm really struggling to understand this. AVRDUDE's recommended SYSCFG0 fuse value only changes reserved bit 2 from 0 to 1, but leaves the other reserved fuse bits 1, 4, 5 set to 0.
My understanding is that all the reserved fuse bits are intended to be changed to 1, which would mean the SYSCFG0 value should instead be 0xFF. It would also mean that OSCCFG (the current value of which AVRDUDE doesn't complain about) should be 0x7D. AVRDUDE verification passes with those new values.
I am also having a lot of confusion from the datasheets. Microchip has been flipflopping on this subject from one revision to another:
From section 5.8:
Note: When writing the fuses write all reserved bits to ‘1’.
From section 5.8:
Note: When writing the fuses, all reserved bits must be written to ‘0’.
From section 31.1 (revision history)
Clarifying that reserved bits within a fuse byte must be written to ‘0’
From section 5.8:
Note: When writing the fuses, all reserved bits must be written to ‘0’.
From section 7.8:
Note: When writing the fuses, all reserved bits must be written to ‘0’.
From section 7.8:
Note: When writing the fuses, all reserved bits must be written to ‘0’.
From section section 7.8:
Note: All reserved bits must be written to ‘1’ when writing the fuses.
There is no mention of the change back to requiring 1 in the revision history. So I don't know whether it was intentional or only a regression of the erroneous information from DS40002015A.
facchinm
commented
2 years ago @per1234 what a mess :slightly_smiling_face: The most sensible thing that comes to my mind is using a recent (7.0 mainline) version of avrdude to dump the fuses from an unprogrammed 4809, see if they are being read as 0 or 1, write some in both ways, read them back and see which method is "correct" (even if I think both will work)
per1234
commented
2 years ago Unfortunately I don't have any ATmega4809 other than on my Uno WiFi Rev2 and Nano Every boards and none of the component suppliers I checked have stock. Do you happen to have access to one @facchinm?
facchinm
commented
2 years ago Sure, I'll try to get some of them
mcuee
commented
2 years ago avrdude git main should have fixed the issue with pull request #1053 merged.
umbynos
commented
2 years ago @mcuee I just tried with an Arduino WiFi rev2 and #1053 does not seem to fix this problem.
The problem seems to be related to the usage of avrdude -V flag (Do not verify). When using it, the upload is successful and the sketch is working fine. But without it, I get the same error reported by @per1234.
The -V flag is added to the command line when:
- Check the box next to "☐ Verify code after upload".
I guess we have to wait to have some Nano Every "virgin edition" or am I missing something?
mcuee
commented
2 years ago @mcuee I just tried with an Arduino WiFi rev2 and #1053 does not seem to fix this problem. The problem seems to be related to the usage of avrdude
-Vflag (Do not verify). When using it, the upload is successful and the sketch is working fine. But without it, I get the same error reported by @per1234. The-Vflag is added to the command line when:
- Check the box next to "☐ Verify code after upload".
I guess we have to wait to have some Nano Every "virgin edition" or am I missing something?
Interesting that you still have issues. I am not so sure what you mean by Nano Every "virgin edition". I have the official Arduino Nano Every and I do not have issues with avrdude 7.0.
Ref: please refer to my run log. So maybe "Arduino WiFi rev2" may have some different FW version.
Edit: I see that you mean by unprogrammed blank ATmega4809, sorry I do not have that.
mcuee
commented
2 years ago @umbynos
In this case, maybe you want to create a new issue in avrdude. Thanks.
umbynos
commented
2 years ago I run some tests with the Uno WiFi Rev2 Nano Every:
With the avrdude that includes fixes from avrdudes/avrdude#1053:
While this is with the old avrdude 6.3.0-arduino17, the version we are currently using in the latest version of the avr core.
With avrdude 7.0-arduino.3:
At this point I think the problem is specific to the Uno WiFi Rev2. Yes, it has the same atmega 4809 but uses a different programmer (xplainedmini_udpi, versus the nano every one: jtag2updi).
mcuee
commented
2 years ago I run some tests with the Uno WiFi Rev2
I think you mean to say "Arduino Nano Every".
At this point I think the problem is specific to the Uno WiFi Rev2. Yes, it has the same atmega 4809 but uses a different programmer (xplainedmini_udpi, versus the nano every one: jtag2updi).
Good to narrow down to Uno WiFi Rev2 using xplainedmini_udpi. In that case, maybe you can raise an issue with avrdude.
Unfortunately other than Uno WiFi Rev 2, I am not so sure if there are any other boards using xplainedmini_udpi with ATmega4809 or similar chips for others to reproduce the issue. There are two boards from Microchip using ATmega4809, the ATmega4809 Curiosity Nano and ATmega4809 Xplained Pro. But they are using adifferent programmers.
MCUdude
commented
1 year ago This issue has been fixed in the latest Avrdude 7.2 release. @umbynos has yet to release a statically built version at arduino/avrdude-packaging.
$ 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.That is amazing news! I will try to release 7.2 static as fast as possible
MCUdude
commented
1 year ago That is amazing news! I will try to release 7.2 static as fast as possible
Excellent! The reason for all this is that the on-board mEDBG programmer on the UNO Wifi Rev2 has "fuse protection", enabled through the SUFFER register, which prevents the user from "bricking" their board when playing around with the fuse bit settings (probably intended for Xplained Nano/Mini users).
Previously you'd need a special Python tool to read and change the current value, but Avrdude 7.1 and 7.2 support reading and writing to this register (it was a fun evening project 😄). Use -c xplainedmini_updi -x suffer to read the current value, and -c xplainedmini_updi -x suffer=[value] to write to it.
I believe the UNO Wifi Rev2 SUFFER register value is 0x7F, but I've changed mine to 0x7E to play with the fuses without any constraints.
Here's what the bits represent (from Avrdude's jtag3.c file):
// 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 0From the Xplained Mini ATtiny817 manual:
umbynos
commented
12 months ago Released 7.2! https://github.com/arduino/avrdude-packing/issues/28
Describe the problem
The handling of unused configuration fuse bits changed in version 6.2 of the AVRDUDE tool used for uploading to the boards of this platform:
http://savannah.nongnu.org/bugs/?46759
This change caused verification of fuses to fail when using AVRDUDE commands and configurations that were valid for previous versions of the tool:
As a workaround, a patch was made to Arduino's build of AVRDUDE which produced a warning instead of an error under these conditions:
https://github.com/arduino/avrdude-build-script/blob/master/avrdude-6.3-patches/80-Avoid-failing-fuse-check-if-different-bits-are-reserved.patch
When uploading to the Uno WiFi Rev2, the patch resulted in this warning:
The patch was also submitted upstream:
https://savannah.nongnu.org/patch/index.php?9110
That patch was accepted and is now part of the AVRDUDE 7.0 release. For this reason, Arduino's patch was removed from the Arduino build of AVRDUDE 7.0:
https://github.com/arduino/avrdude-packing/tree/7.0-arduino.3/patches
🐛 The upload fails during the
fuse5verification when uploading to the Uno WiFi Rev2 using AVRDUDE 7.0-arduino.3.To reproduce
Equipment
Steps
~/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude%LOCALAPPDATA%\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17\bin/avrdude.exe~/Library/Arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude🐛 The upload fails:
Expected behavior
Upload is successful.
Additional context
This could of course be worked around by modifying Arduino's build of AVRDUDE as before, but the current goal is to maintain the fewest possible number of patches necessary for AVRDUDE to meet Arduino's requirements. So I think the best place to start the investigation is by considering whether the issue can be solved by adjusting the fuse values specified in the boards definitions of this platform:
This would have the additional benefit of removing the warning which frequently causes concern or acts as a "red herring" for new users of the Uno WiFi Rev2 (e.g., https://github.com/arduino/ArduinoCore-megaavr/issues/71, https://github.com/arduino/ArduinoCore-megaavr/issues/121, https://github.com/arduino/Arduino/issues/9443, forum#954001)