search

SpenceKonde / megaTinyCore

Arduino core for the tinyAVR 0/1/2-series - Ones's digit 2,4,5,7 (pincount, 8,14,20,24), tens digit 0, 1, or 2 (featureset), preceded by flash in kb. Library maintainers: porting help available!
Other
551 stars 143 forks source link

Getting Optiboot to set APPEND #207

Closed trusleymike closed 4 years ago

trusleymike commented 4 years ago

Not an issue, more a request.

With only 256 bytes of EEPROM (plus User Row) many people will need to write to the APPDATA area for internal storage on the "0" and "1" series processors.

After installing Optiboot on an ATmega4809:

FUSE.BOOTEND returns 2 FUSE.APPEND returns 0.

Since Optiboot knows its own length, and the length of the code it is installing, could it update the APPEND fuse?

SpenceKonde commented 4 years ago

Nope. All the knowledge of it's size doesn't help Optiboot out in this case - fuses can never be self programmed.

SpenceKonde commented 4 years ago

HOWEVER - there is good news though! Optiboot has a magic function that the app can call to make that magic write to NVMCTRL.CTRLA that erases flash and/or writes to the page buffer.

But there's also bad news. It has never been tested on the tinyAVR 0/1-series or the megaAVR 0-series. How do I know that? Because there's a typo in the Optiboot code, and instead of writing the command to NVMCTRL.CTRLA, it writes it to WDT.CTRLA...

trusleymike commented 4 years ago

I understand that, like other fuses, values have to be known BEFORE they are set by AVRDUDE? (Or Atmel Studio.)

That's a bit of a PITB because we have no automatic way to pass the length of the app to something which will set the fuse and I don't know a way of finding the length of the app at run time so we can work back from the end of memory to see how much space we have left for data! Surely there must be a way?

How does your suggestion about NVMCTRL.CTRLA help to find the end of the app?

SpenceKonde commented 4 years ago

I don't propose setting any fuses. I propose using that call to do what it's there for, and that is to be a call in the bootloader space which writes to NVMCTRL.CTRLA to write to the flash within the app section. Up to the user to make sure they're not writing over their code, though. User code fills the temporary buffer, calls that with the erase-write command, being careful to page align the writes and all.

trusleymike commented 4 years ago

OK. Many thanks Spence. I'll close this down now.

SpenceKonde commented 3 years ago

2.3.2 introduces a Flash.h library which supports writing to the flash from the application. APPEND does not matter here; it achieves this by calling an entry point embedded in the bootloader (the interface is identical to that used to call optiboot from the application area on many classic AVRs, and completely different from the Flash.h that DxCore has, which I wrote with no knowledge of how it was done on classic AVRs). It requires Optiboot - it will not work on non-optiboot board definitions (Flash.h on DxCore does, largely as a consequence of the different sort of entrypoint it uses)