Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support AVR-D series. #294

Open
WestfW opened this issue Sep 26, 2020 · 9 comments
Open

Support AVR-D series. #294

WestfW opened this issue Sep 26, 2020 · 9 comments
Assignees
Labels
Type-Enhancement Type-newChip Mostly involves adding a new target microcontroller.

Comments

@WestfW
Copy link
Member

WestfW commented Sep 26, 2020

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.

@WestfW WestfW added Type-Enhancement Type-newChip Mostly involves adding a new target microcontroller. labels Sep 26, 2020
@WestfW WestfW self-assigned this Sep 26, 2020
@MCUdude
Copy link

MCUdude commented Sep 28, 2020

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

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

@SpenceKonde
Copy link
Contributor

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

@SpenceKonde
Copy link
Contributor

SpenceKonde commented Sep 30, 2020

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
Copy link
Contributor

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
Copy link
Member Author

WestfW commented Sep 30, 2020

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
Copy link
Contributor

@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
Copy link

mcuee commented Oct 15, 2022

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

@mcuee
Copy link

mcuee commented Oct 22, 2022

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.

Edit to update: Done.

@mcuee
Copy link

mcuee commented Dec 21, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type-Enhancement Type-newChip Mostly involves adding a new target microcontroller.
Projects
None yet
Development

No branches or pull requests

4 participants