Support AVR-D series.

[WestfW]

Microchip has new AVRs with up to 128k of flash. "AVR DA Series": AVR128DAxx "AVR DB Series": AVR128DBxx There are also AVR EA and AVR DD series with up to 64k of flash.

Because of the need to address more flash than can be mapped into the nominal 64k address space, flash programming works differently than on the mega-0 series, so optiboot_x would need significant changes. Because they're "new" xmega-style chips, flash programming works differently than the old AVRs, and regular optiboot would also need significant changes.

Also, there's at least one errata WRT flash mapping that may need a workaround.

[MCUdude]

I believe @SpenceKonde got optiboot_x working on the AVR DA chips:

https://github.com/SpenceKonde/DxCore/tree/master/megaavr/bootloaders/optiboot_dx

[SpenceKonde]

The AVR EA-series looks like it will have different programming parameters - notice how they mention RWW sections of the flash...

[SpenceKonde]

The DD-series, on the other hand, looks likely to be binary-compatible with the DA and DB-series (which are binary-compatible with eachother).

Hoping to look at this later tonight, but no promises on that. Finally out from under the worst of my overdue stuff.

To clarify - 128k parts are compatible with other 128k parts. 64k parts with other 64k parts. Currently 32k-and-less parts are compatible with eachother, but not other parts (because it's all memory mapped there)

On parts that aren't fully memorymapped, though, I just have the bootloader use SPM and write words. And there's no reason we can't do same for them. My plan it to make it all work in 512b (yes, I figured out about the whole size of the app part).

The do_spm() (could) be more interesting here.... you don't have to program a whole page at once. You could erase it, say, only if it starts at a page boundary? Even better would be a way to say "just erase it please".... And so, people could then write one word at a time if they wanted to....

[SpenceKonde]

Oh - DD might not be perfectly binary compatibility - though if they did it right they can be (just that some of their binaries wouldn't work on DA/DB because the DD parts offer additional USART mux options

[WestfW]

The do_nvmctrl() code in optiboot_x will let you write one word (byte!?) at a time:

Cmd: dump 0xb000
FFFFB000:  00 01 02 03 04 05 06 07 08 09 0A 0B 0C FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FFFFB020:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FFFFB040:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Cmd: dospm 99 0xB020 0x20 0x21 0x22    ;; have bootloader copy to the flash alias space.
NVMCTRL.STATUS = 0

Cmd: dospm 1 0 0             ;; "write page" (without erase)
NVMCTRL.STATUS = 0

Cmd: dump 0xb000
FFFFB000:  00 01 02 03 04 05 06 07 08 09 0A 0B 0C FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FFFFB020:  20 21 22 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FFFFB040:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

[SpenceKonde]

@WestfW - so, it fits in 512b now, even on the 128k parts! How do you want me to get this back to you? I suspect you will want to make some stylistic changes to it as well as, likely, various technical improvements...

With all that flash, it would be awesome if we could get the writing to flash from app, so I left tons of space for you to work your magic with that...... You can fit that in 12 instruction words right? >.>

Seems to work. Scrounging for every instruction word you can get is fun, isn't it?

https://github.com/SpenceKonde/DxCore/tree/master/megaavr/bootloaders/optiboot_dx

[mcuee]

optiboot_dx seems to work fine with avrdude 7.0 release or the Arduino bundled avrdude 6.3 version.

[mcuee]

This PR is supposed to fix the issues for optiboot_x and optiboot_dx. Hopefully those who have the relevant HW can try to carry out the test.

• https://github.com/avrdudes/avrdude/pull/1140

Edit to update: Done.

[mcuee]

• https://github.com/Optiboot/optiboot/issues/353#issuecomment-1312347766

@WestfW mentioned below.

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.