optiboot_x fails for >48k of flash (ie xTiny, AVRDx64, AVRDx128)

[WestfW]

The current optiboot_x was written for ATmega4809, and assumes that all of flash memory is mapped into the RAM address space. Also, it doesn't handle any of the hacks for an extended address byte.

So optiboot_x will fail to work for more than the amount of flash that is directly mapped into the RAM address space by default. That's only 32k on the 64k and 128k devices.

avrdudes/avrdude#1120

@SpenceKonde @MCUdude @avrdudes

I guess this was already reported as a feature request under #294

[SpenceKonde]

Uh. the version that comes with DxCore most certainly works. Significant changes were required, resulting in the creatively name optiboot_dx. (the main changes were adapting to the different write method, realising that no bootloader that does not clear reset cause flags is fit for production, and did the write to flash from app TOTALLY differently.

I'm concerned by the way thing are getting changed with avrdude in ways that break optiboot.

My plan is to continue using avrdude 6.3 in my releases until the commortion dies down.

[mcuee]

I believe optiboot_dx works here with avrdude 7.0 release, even though there is a strange verification error prompt (false alarm). Tested with an AVR128DB48 Curiosity Nano with optiboot_dx from DxCore.

BTW, the 8s delay in optiboot_dx does work -- I need to be fast since Windows will pop up with the mass storage thingy.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq 
-U .\hex2\optiboot_dx_avr128db48_uart3_8s.hex && echo OK
                 Vtarget                      : 3.31 V
                 PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM6 -b 115200 -p avr128db48 
-qq -D -U .\hex2\hexaa64KB_with_blink.hex && echo OK
avrdude7.exe: verification error, first mismatch at byte 0x0200
              0xff != 0x79
avrdude7.exe: verification error; content mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq -D
 -U flash:v:.\hex2\hexaa64KB_with_blink.hex:i && echo OK
                 Vtarget                      : 3.31 V
                 PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM6 -b 115200 
-p avr128db48 -qq -D -U flash:v:.\hex2\hexaa64KB_with_blink.hex:i && echo OK
OK

Same result for the avrdude 6.3 version bundled with DxCore.

PS C:\work\avr\avrdude_test\avrdude_bin\bin_misc\6.3.0-arduino17or18\bin> .\avrdude -C ..\etc\avrdude.conf 
-c arduino -P COM6 -b 115200 -p avr128db48 -qq -D -U hexaa64KB_with_blink.hex && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0200
             0xff != 0x79
avrdude.exe: verification error; content mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq -D 
-U flash:v:.\hex2\hexaa64KB_with_blink.hex:i && echo OK
                 Vtarget                      : 3.31 V
                 PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK

[mcuee]

The following avrdude PR should fix the issues with optiboot_x and optiboot_dx for avrdude git main.

• Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino avrdudes/avrdude#1140

[WestfW]

So ... it turns out that the mega0 and xTiny chips supported by Optiboot_x are substantially different than the new AVR-Dx, and it seems that "fixing" Optiboot_x (or Optiboot) is not a good strategy.

@SpenceKonde has implemented a new bootloader "Optiboot_dx", based on optiboot, that does support them as part of https://github.com/SpenceKonde/DxCore, and I suspect that will be the final state of things.

[SpenceKonde]

Yeah - while Optiboot-dx was derived from Optiboot-x, the different method of writing the flash makes the whole thing a very different animal, and I don't think it makes sense to try to combine them - would just be ifdef hell.

There are still a few unknowns about the future Ex-series, which seems mostly very similar to the tinyAVR/mega0. The main mystery is how they'll do the flash addressing, since it can have up to 64k of flash, and only memory maps half of it. That might be viable to add onto Optiboot-x, rather than having to make an Optiboot-ex.