Save/restore the MPM's internal storage

[raphaelcoeffic]

Description

When transferring models from one radio to the other, either because the user uses only that new radio, or because he wants to use 2 radios in parallel, transferring the model files is not enough, as the MPM holds the binding information for each receiver, which is not part of the model files.

In short, a full backup is not really possible as it only contains the model files, but not the module's internal state.

Proposed solution

Ideally, we should be able to backup the MPM's internal state and dump it to disk to allow a full backup / restore. This requires some protocol extension to be able to query the module for its internal state, but also to write that state to the module.

For some protocols, the internal ID (in some cases the MCU ID) of the module is used for some computation, which would need to be overridden to make the "restore" operation perfect and tackle the case where the user wants to make a perfect copy of an MPM into another. This is already possible for some protocol by using either a compile time option, or by using a specific feature at runtime ("Clone" feature).

I understand that the internal state has a format that depends on the firmware version, and obviously, this would only work if both software version are identical, or the restore destination has a version that is >= the source version.

[benlye]

For external modules this can already be done using Flash Multi to read and write the EEPROM data. Of course that doesn't help with internal modules, which I guess is what most people have these days.

[pascallanger]

Hi Raphael, I started to do that with the "Config" protocol : https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/tree/master/Lua_scripts#multiconfig
I was thinking to code a backup and restore feature but I haven't done it since I didn't knew if people where interested. The structure is nearly there if I remember.

The big warning is that both radios then can't be used at the same time otherwise they will transmit using the same ID. Unless you force the old one to another ID but if you sell it and the guy format the eeprom then you will have a conflict... If people understand that then this is ok.

[pfeerick]

Why does it need to be the full state? Why not be able to read/write the required details (i.e. MCU ID/binding UUID), and let the MPM continue to worry about storage format. i.e. say I set a model up with Frsky D16, when I set the protocol the unique identifiers can be read from the MPM, to be saved into the model config of the radio. Then, when the model is loaded next, that ID can be sent to the MPM on load, and potentially saved if different to the value in EEPROM. IMO there's no need for that if the radio is capable of read/writing them though.

Or should I just back away quietly and let the big boys figure this out? 😆🤭

[pascallanger]

@pfeerick For some protocols, you need more than just the ID. This is why you need to backup/restore the "virtual" eeprom...

[raphaelcoeffic]

@benlye In fact, I was thinking we could do that a bit smarter. We have implemented for ELRS a pass-through mode that basically bridges the module's serial port with USB serial. If you send some commands before switching into that mode, you can even reset the module and hook into the bootloader for updates. That being said, it is only implemented for internal modules right now, but could be extended easily to the external modules as well if needed.

[pascallanger]

@raphaelcoeffic You can do it through the bootloader isn't it, read instead of write ?

[raphaelcoeffic]

@raphaelcoeffic You can do it through the bootloader isn't it, read instead of write ?

Not sure I understand that right. Can you please give me some context? 😅

[pfeerick]

EdgeTX's VCP-CLI mode allows you to send commands to the transmitter, which among other things allows you to power cycle/reset the module, toggle the boot pin, and bridge the serial link with the module, thus "passthrough flashing". Allowing for software like flash-multi or even some web-based flasher to be able to do the flash or otherwise interact with the bootloader.

For reference, this is how ELRS does this to enter passthrough flashing...
https://github.com/pkendall64/ExpressLRS/blob/a005e3120aa4ef1bb89e61595bb680d7d560caf2/src/python/ETXinitPassthrough.py#L14-L51

[pascallanger]

Multi does not have a CLI but instead a bootloader which is looking for commands at the module boot. If the module doesn't receive any commands within a short timeframe the multi code is launched. I think from memory that the bootloader can read/write the flash so you can dump the module content the same way that you flash it.

[pfeerick]

ELRS doesn't have a CLI either... instead, it's looking for a boot pin that is held down on power on, to go into bootloader mode. Which is what that snippet of code tells the EdgeTX CLI to do... stop pulses, turn off the rf module, set the boot pin high, power on the rf module, set the boot pin low again, bridge serial to rf module ...

So for the MPM, it would probably just be stop pulses, turn off the module, turn on the module, enable serial bridge (with appropriate delays), and then it's over to the controlling software (i.e. flash-multi) to tell the bootloader what to do.

[pascallanger]

I mean Raphael already did it when he implemented the flash procedure of Multi from OpenTX at the time. All I'm saying is that you need to do the reverse instead of sending write commands to the bootloader, send read.

[raphaelcoeffic]

Now I see: the MPM stores the binding information I to its own flash space, thus reading the full chip will produce a full backup including all bindings stored, correct?

[pascallanger]

Exact, you never overwrite the flash "eeprom" space when you flash the module because we make sure the code is not overlapping with it. But you could if you wanted to fully reset it...