Writing to atmega flash at runtime

[WhiteHare]

Finally!  Looks as though there is now a bootloader which can allow you to write to the atmega flash memory at runtime:  http://forum.arduino.cc/index.php?topic=332191.0

I'm hoping it provides a runtime means to install new firmware into the atmega flash (though one or more of us may have to write the runtime part) that will run on the next reboot without requiring the use of external flash memory as a tempoary holding place.  Also, that way you don't need to cram wireless programming into a 4K bootloader....

[Felix]

Hmmmmm. Maybe i'm missing the light but what happens if:

1) Fuses restrict writing to atmega's flash from application code? It's generally a big NO-NO to write flash memory from app code. Hence there are fuses specifically to block this behavior.

2) Assuming writing flash space is allowed: what if RF packets or the hex streaming is stopped or writing is interrupted by unexpected conditions? Now your flash is corrupted with no way of recovering other than by means of bootloading

3) If the new sketch is larger than the new sketch. Are you overwriting your existing sketch? Or where do you even put it in memory?

I haven't read the whole thread but one statement by the author does not make sense to me:
"I've made a modification to Optiboot bootloader, so now application can write to flash if this version of bootloader is installed."
If writing is done from the app code, what does the bootloader have anything to do with this? 

I have read a little more in the thread and it sounds like he is circumventing the fuses that block flash writing from app code by jumping to the bootloader code to do the actual writing. Yikes, all my red lights went blinking instantly when I read that

Here's a somewhat funny post down in the thread:

I hope it will get in the official bootloader

Interestingly, the "issue" requesting that this be added to Optiboot showed up at approximately the same time as a separate request to make optiboot "more secure" by preventing it from being callable from the application section :-)
It might make it into the optiboot release at some point; getting into the Arduino releases is harder and slower, and this is a relatively dangerous feature.

To me it's not only dangerous but feels very wrong.
So ... awesome hacking but no thanks, my list of requirements for wireless programming still checks at every point, in support of using the additional external FLASH MEM chip.

[joelucid]

I'm hoping it provides a runtime means to install new firmware into the atmega flash (though one or more of us may have to write the runtime part) that will run on the next reboot without requiring the use of external flash memory as a tempoary holding place.  Also, that way you don't need to cram wireless programming into a 4K bootloader....

I think the only really viable way to avoiding the external flash is to delete the current application before installing the new one. That means the "runtime" needs to be capable of downloading the new app. And it can't share code with the application, so no RFM69 for you. And it needs to deal with failure by repeating the process.

So then you're back to creating a very small, fail-safe and self-contained "runtime". Of course if you do that why not just write a bootloader?

Esp since the hw bootloader support gives you a separate irq table, a reliable entry point etc.

Joe

[WhiteHare]

Of course if you do that why not just write a bootloader?

4K limit.

[joelucid]

4K limit.

First try if you can fit it in 4k. That is very much the preferable way to do it. If it's not start another .text section at 0x6000 if you want and map some of your functions there. Your bootloader just has to enforce an app size < 0x6000 then.