How to do OTA? AVR128DB64

[bgersmann]

Hi,
if I understand corretly, I could update the appcode by writing a new firmware directly in flash starting 0x0200?

But if I have an error while writing my program is broken and the chip will stop working?

Is there any example how to do OTA the right way? Should I use a bootloader and ArudinoOTA library or so?

I have an AVR128DB64 + Sim7080 LTE Module.

Thanks for any tips!

[MX682X]

The whole thing is a bit tricky.
I'd say the most reliable thing would be to write a custom bootloader. Like this:
AppCode sets a flag and does a Software Reset.
Bootloader examines the Flag. The flag indicates a software download. It sends a "ready for programming" command to the LTE module.
The remote programmer, upon receiving the command sends initiates the programming procedure.
The bootloader on the DB writes the data automatically to the Flash.

The BOOT secton can be Write protected, this makes sure that one part of you Program will remain operational.
The 0x0200 Section can be increased, to accomodate for a bigger bootloader, neccessary to have the LTE Interface communication.

[SpenceKonde]

This has "time sink" written all over it... OTA f/w updates are hard.

I think ESPs take the copout option (some bootloaders for them sure do), sacrificing half of the flash (on an external chip, hence space is no problem), and have one half marked as the active one which the bootloader jumps to, and the second one is the upload partition, and the bootloader writes code to and verifies it from there. Once once it's verified does it flip the switch, and start jumping to the other partition.

Of course, this doesn't work unmodified on an AVR because code is not freely relocatable - the compiler has to be told where the image starts to correctly generate code (i've looked at what the problem is like if we were to modify the code on the fly - that looks like a rabbithole that will lead to glory - but it's just a rathole. You'll just end up where you started 4-48 hours later, dirty and fleabitten. (the wide time range because it doesn't look that bad until you realize you need to be able to deal with ld/ldd/st/std, and depending on where the values in the pointer register came from and what they point to, figure out how. if at all, they must be modified. That sounds like it borders impossibility - it means working back from every single ld or st to figure out where it will be accessing, what type of memory that is, but often it's not clear from whence come the values in the pointer registers. So to implement an analogous thing, I think you'd need to double-up the linking step, generating two s, one with each of the addresses, and have the OTA uploader, after talking to the chip, determine if the upload partition was the high or low one, and upload the appropriate binary... but nope, even then, it won't work, because you can't change fuses when uploading via bootloader, and at runtime you only get two options for the start of vectors - they either start at 0x0000 (in the bootloader, no good!), or they start at 0x200 * BOOTSIZE (this is what we want, at the start of the app - but if we had two app "partitions" we would have no way to tell the chip to change the BOOTSIZE except via a updi programmer. So not only is that rathole a dead end, see all those holes burrowed into the hillside there? They're all dead ends!

Any scheme with hope of working (as must have the bootloader trash it's old active partition after verifying, and then write all the data to the flash, then go through the uploaded code for a third time, copying the upload partition to the active one. This also bypasses that near impossible relocation task and the need for workarounds for that, though it produces twice the flash wear. I don't think you can get around persisting at least a byte of auxilliary data probably in eeprom so it knows what state it's in and whether it should run the app, or if it was reset into bootloader to copy the new firmware from the second partition to the first (since we can only run it from the first as discussed above), so that if an upload fails while in progress, either the app is still there because it failed to make it past opening (or trying to) the connection over which the chip, bootloader eventually times out if it was ever activated, and app still runs. A partially completed upload will not be run, and won't harm the app in the active partition. But that burns half your flash - and it's a ton of code to write, and not easy code.

You can do the same thing with an external EEPROM chip too - app receives new code and writes it to eeprom, verifies, then resets itself into your custom bootloader (giving itself the power to write to the appcode section) that loads a firmware image from the external eeprom and writes it to flash

[SpenceKonde]

@bgersmann I've converted this issue to a discussion, as this does not represent a defect in the core, we provide no OTA-update associated functionality, our bootloaders are not designed for the requirements of OTA updates. Viewed as an enhancement request or new feature, that request is rejected as beyond the scope of what this core should supply as well as beyond my ability to provide.

[bgersmann]

First of all, thanks for the infos. As I'm fairly new to this, I hoped for an easier solution.

As the sim7080g has an own flash which is accessible by AT commands, I thought about downloading the firmware in it's flash and from there into the AVR via Bootloader.
As I never worked on a Bootloader yet, it will be hard for me to achieve, but it could be a good task to learn more about it.

I also thought about an ESP, but they don't have a enough I/O and Serial ports for my needs.
Thanks again, also for DxCore itself.

[MX682X]

The AT command reference says the max file size is 10kB. How big is your Application? How much RAM are you using? Asking, because if your entire Program can fit in the 10k, it could be possible to download the new Program into the RAM and then jump to the bootloader and copy the new Program from RAM to Flash. If it's more and the App has to be fragmented, it will become pretty complicated pretty fast.

If it smaller then 64k, you have a chance by "daul-banking" the flash and be able to use the solution I have come up in #510 (comment)
If it is bigger then 64k, you'll need to change the bootloader significantly (e.g. sacrifice avrdude UART uploads)

[bgersmann]

Actual it's 52kb. I saw the other discussion #510 , maybe that's also a solution for me.