Burn bootloader does not work in 2.3.2 and later with serialupdi programmer selected.

[SpenceKonde]

Uhhhh guys.... is NOBODY initializing fuses now that I made it unnecessary to do so unless you want to disable UPDI, save EEPROM across chip erase, or

And is NOBODY using Optiboot?

This bloody simple functionality has been broken since the boards.txt refresh in 2.3.2 - platform.txt got switched to the new name, boards.txt didn't.

Y'all gotta up your game - I should not get away with releasing a version with such a highly visible bug.

[grandaspanna]

I'm running 2.3.2 and routinely "tools->burn bootloader". No errors have popped up - I don't use Optiboot - I don't really see the point for what I do. Is it not doing something?

[SpenceKonde]

@grandaspanna And you're using SerialUPDI as the programmer?

You should be getting a python error from prog.py because the IDE is passing an invalid command ( "{bootloader.serialupdistring}" instead of "-aerase", because platform.txt was changed to refer to that, but boards.txt still named it bootloader.pymcuprogstring)

[mechatroniks-git]

Never tried the bootloader (one wire is nice, not sure what the advantage would be for Optiboot).

[grandaspanna]

@grandaspanna And you're using SerialUPDI as the programmer?

You should be getting a python error from prog.py because the IDE is passing an invalid command ( "{bootloader.serialupdistring}" instead of "-aerase", because platform.txt was changed to refer to that, but boards.txt still named it bootloader.pymcuprogstring)

Yes, been using SerialUPDI. This is the command "burn bootloader" generates:
C:\Users\...\megaTinyCore\tools\python3\3.7.2-post1/python3 -u C:\...\packages\megaTinyCore\hardware\megaavr\2.3.2/tools/prog.py -t uart -u COM5 -b 230400 -d attiny412 --fuses 0:0x00 1:0b00000101 2:0x01 4:0x00 5:0b11000101 6:0x07 7:0x00 8:0x00 -aerase