Bootloader ATmega 2560 for OTA

[mkaiser]

Hi,

I have been searching the web for a while now, but I am still confused about all the OTA stuff, which seems only to work on 328 devices for MySensors.

For a sensor node I want to use an ATmega 2560 (can't use 328), which is supported by the current Optiboot v8 by westfw (https://forum.arduino.cc/index.php?topic=570160.0).

Is it possible to use optiboot v8 with MySensors? The DualOptiboot project does not support the 2560, was not updated for a long time and looks deserted to me.

I have been digging around in optiboot's and dualoptiboot's code for some time, but I am not sure where to begin yet (as I did not understand much of the bootloader magic)

The current optiboot v8 also supports direct EEPROM writes via the dospm function. (see git optiboot\optiboot\examples\test_dospm). Does this help in any way to integrate it into MySensors?

If you could point me in a promising direction I would be happy to contribute the results

Martin

[mkaiser]

After some intensified research, I am pretty sure, that my desired OTA (MySensor sketch directly to MCU flash without requiring external flash (DualOptiBoot requires flash) and being transport-agnostic (not MYSBootloader uses RF24)) with a 2560 can be done with the optiboot-fork bootloader by MCUdude (for the ATMega 2560 the variant is called "MegaCore", see https://github.com/MCUdude/MegaCore/). The MegaCore provides some macros for the SPM (storage programable memory) functions, which are passed to the bootloader like __boot_page_fill_short, __boot_page_write_short and __boot_page_erase_short.

The repository comes with precompiled bootloaders as .hex files and a nice Arduino GUI integration (see wiki).

My next step is to integrate the example sketch SerialReadWrite.ino into MySensors/core/MyOTAFirmwareUpdate.[c|h].

Currently I am still a bit confused about the used defines. As far as I understand the

#define MCUBOOT_PRESENT represents the MySensors bootloader by Tekka,
the #else or #ifndef MCUBOOT_PRESENT branches are for the DualOptiboot bootloader (which is somehow deprecated).

It looks like several defines are declared in #include "generated_dts_board.h", but I cannot find the file. Also there must be some kind of #include towards the dualoptiboot or mysensors specific bootloader header files, right?

[mkaiser]

after more research and testing I am pretty sure that the current optiboot development branch (https://github.com/Optiboot/optiboot) is the best way to go.

I can successful compile and flash the standard optiboot sources for the ATmega328 and ATmega2560.

One of the next steps are

• use an RF24 shield to test the current branch of https://github.com/mysensors/MySensorsBootloaderRF24 with an 328 and 2560.
• port to optiboot and call "MySensorsBootloader();" using RF24
• port the RF24 related RX/TX functions to my serial interface (CAN-Phy)

I am still wondering why nobody ported this before - what am I missing?

~Martin

[mfalkvidd]

@mkaiser my guess would be that
• almost no-one uses the mega
• very few use ota
• mySensors does not have CAN support (at least as far as I know)
• not many are skilled enough to create a bootloader

Combine those and you get about 1 person - yourself

But you are very welcome to share how you did it - maybe we can increase the number of people that have the skills thanks to your knowledge.

[mkaiser]

thank you for your answer

I guess I accept the challenge and keep you posted

[tekka]

@mkaiser That's a great idea - code contributions are always welcome

[NeverDie]

This explains how to do it: https://forum.arduino.cc/index.php?topic=610354.0

Fortunately, Optiboot 8 recently added a new function do_spm() which, from what I gather, you call from your code. It then takes the new compiled sketch binary that your OTA code is assumed to have placed at the end of flash, writes it to the beginning of flash, and then jumps execution to the start of the freshly written sketch. In a nutshell, it appears that's all there is to it.

Prior to this, you had to write your own bootloader. It appears that now you can get by without having to. Instead, the heavy lifting is moved into your application code, where development is more familiar. That may not be as robust as having an unchanging, tried-and-true FOTA bootloader that's protected, but it does seem like an faster path to get a FOTA for a particular radio up and running across a range of MCU's without having to make a custom bootloader for each one.

What a relief! I was on the verge of switching over to PICs because of this exact issue. Hopefully now I won't have to.