fuse hex file

[coburnw]

Hi
I use arduino-cli, and have not been able to find the output containing the selected fuses after compilation, nor are the switches set after upload. Currently i hand compile them and upload with prog.py --fuses.

Here is a stripped version of the command i am using in an attempt to set the resetupdi pin fuses:
arduino-cli compile --fqbn DxCore:megaavr:avrdd:chip=avr64dd32,resetupdipins=resetupdi ./blink.ino

If i change the switches, recompile, then do a diff of blink.hex and blink.eep, no difference is found. Perhaps arduino-cli compile isnt the app that compiles the switches?

Loosely related, anyone have any python code for parsing boards.txt that they would be willing to share? Or recognize the format enough to name it? Im sure that i can find a parsing library if it follows a standard.

Regards,
coburn

[coburnw]

Ok. So im seeing the problem now. the majority of the switches, and specifically resetupdipins, need to be burned by a bootloader.

[coburnw]

Well actually not.
How the core uses updi can be found near the bottom of platform.txt. It programs the fuses as needed on a register basis using prog.py There is no hex file for fuses.

[SpenceKonde]

The library does not follow a standard. We tried making one a while back; The format is ugly because
board.menu.whatever.option1 = Option 1 is giving the value of {whatever.option1} but that same node will also have leaves coming off it, like board.menu.whatever.option1.bootloader.WDTCFG = 0x20.

If I were to parse into python (I'd love to do this but no time - I'm better i avr asm than python). I'd probably use nested dictionaries as the structure, and have a "special" property to hold the "name", so the above (located under boards["boardname"]["menus"] (eg option1:{"__name":"Option 1", "bootloader":{"WDTCFG":"0x20"} I would probably keep numbers as strings.

Preserving the whole structure is key if you want to reconstitute the recipes for a given set of options, which I assume is the point.

I would be very interested in this.

Regarding which fuses are and are not set by burning bootloader only, two fuses can "brick" a DB or tiny, and 1 can brick a DA/DB or Mega 0, these are the BOD fuse, which could be set to something higher than other parts on the board you soldered it to can handle, and SYSCFG0, which is where innocuous things like EEPROM retain sit right next to the bits that disable reset.
We don't have a facility to read a fuse, and leave certain bits unchanged while altering others, and we never want to change a setting that could brick the board unless the user bootloads it. Every other fuse which we provide a menu for is set on every upload (on the logic that those ones we don't provide a menu for, if the user changed them, we should not undo his hard work on upload. Burn bootloader though restores them to default values, on the logic that that should restore them to a well defined state.

Obviously for optiboot, everything that changes fuses requires burning bootloader because fuses cannot be self-programmed.