MSP Rx Reboot

[jlpoltrack]

For future INAV Passthrough functionality, use the MSP Reboot command to put STM32 receivers into system bootloader.

Tested in combination with: https://jlpoltrack.github.io/mLRS-Flasher/inav-passthrough/

Requires: iNavFlight/inav#11256

[olliw42]

VERY NICE
just few nitpicks

could it make sense to grab the opportunity to also define a MSP_START_RX_PAIR, to set the receiver into bind mode, similar to what we have for mavlink?
https://github.com/olliw42/mLRS/blob/main/mLRS/CommonRx/mavlink_interface_rx.h#L324-L329
@b14ckyy ?

the mavlink version requires three commands to be send before it is accepted, we are sure we don't want such a level of protection here, right?

[jlpoltrack]

could it make sense to grab the opportunity to also define a MSP_START_RX_PAIR

I suggest this for separate PR, as a corresponding INAV update would be required here. Currently, the INAV CLI sends 'bind_rx' message to the FC which then sends the necessary stuff for a Spektrum or CRSF receiver - it doesn't passthrough this MSP messge to the FC/Receiver. https://github.com/iNavFlight/inav/blob/master/src/main/fc/cli.c#L3578-L3597

the mavlink version requires three commands to be send before it is accepted, we are sure we don't want such a level of protection here, right?

So INAV will only enter passthrough mode (which is used for programming) in the first place if the craft is disarmed, so I think this should be safe.

[b14ckyy]

since we have the MSP_RC Messages introduced, this would make sense. I just need to clarify with the guys how to do that since a MSP receiver is not tied to a specific serial port (like in Ardupilot) but just listens to the MSP Parser. So to make this possible, we would send the message to up to 3 MSP devices at the same time that did not request it. That would be against MSP Design specifications and we can't predict how certain devises (like a MSP Lidar Sensor, ESP Radar, 5G relays, etc) behave now or in the future.

Will have a chat with the devs but I have doubts.

Edit:
@jlpoltrack can the STM32 be flashed with other bitrates than 115200? if yes, then you would not need any INAV change and could make a custom solution.
Since you read the serial settings from INAV already, you can keep the baud rate that is set in INAV for the selected port. Then send INAV into Passthrough mode with the same baud rate instead of fixed 115200 and you can send whatever command you want to put the Rx into BL Mode.

[jlpoltrack]

Then send INAV into Passthrough mode with the same baud rate instead of fixed 115200 and you can send whatever command you want to put the Rx into BL Mode.

So this is a gap in my current implementation (any baud rate other 115200 won't work at the moment) but that is straightforward to address. However, the STM32 bootloader talks 8E1, so I still need the INAV update to mirror the encoding and baud rate after entering passthrough which INAV doesn't support today.

Process would be:

• Enter passthrough with 8N1 (at assigned baud rate)
• Send the reboot command with 8N1 (at assigned baud rate)
• Do the programming with 8E1 (will use 115200 since its reliable)

[olliw42]

@jlpoltrack @b14ckyy
I have merged and did few little tidies (the if did not come out as I thought ;)).
Among them is one which might be behavior changing, but which I think should be done for consistency, and which I kindly ask to double check if ok:

all MSP messages which the mLRS receiver sends out (either to the ground or the FC) have the flag MSP_FLAG_SOURCE_ID_RC_LINK set. This is the flag which was introduced to differentiate the origin of the MSP messages. INAV calls it somewhat differently (forgot, inline or so). To be consistent I thus have set this flag also for the response to the FC when the reboot is accepted.

[olliw42]

as regards rx_bind. I hear you but I rerally don't understand why it should be so asymmetric for reboot and rx_pair, doesn't make sense to me.
E.g. if JLP can figure out on which port the reciver sits, I would think that the FC should also be able to do so, and rx_bind by name is very specific to "RX". The only (logical) issue I could see is when there are two receivers, but I bet INAV is not doing receiver redundancy, so nonissue.

[b14ckyy]

@olliw42
contrary to other receiver protocols like CRSF, sbus, etc MSP is not configured as a dedicated MSP-RX in INAV. same for Mavlink.
"classic" receivers are tied to a Serial port that is exclusively used. That's why a specific serial is defined as a Serial-RX port in inav. And you can only have one.

But for MSP and Mavlink this switch is not enabled. You just enable 1-3 Serial ports as general MSP ports (one is actually already on USB-VCP but not visible). So then you just tell INAV to accept RC inputs through MSP by enabling that in the receiver tab. So in the end INAV will take any RC messages over MSP, no matter over what serial port they come from. You could even feed RC directly over USB then. So INAV literally does not know at what port the Rx sits.

And yes that way even receiver redundancy can be done, as long as you can silence one or make sure they don't send the same channels.

And since MSP is a request-answer protocol, I think it was never intended to send a MSP message out of any serial port without being requested through this specific serial port.

---

TL;DR I will have a chat with Sensei and Jetrell to see if we can do something since they know the inner workings of INAV much better than I do.

[olliw42]

THX
however, how does it then work for REBOOT?
how can JLP figure out which MSP port he needs to put into passthrough?

[b14ckyy]

@olliw42 He pulls the serial config from INAV and lists all ports that have MSP enabled in his web flasher. the User then picks the port where he has the receiver connected to and this port is then enabled for passthrough. So its not fully automatic.

But I might miss something here. If he found a way to send that command to the Rx then it should work with bind too.

@jlpoltrack
Maybe you can explain that for dummies like me :D

[olliw42]

@olliw42 He pulls the serial config from INAV and lists all ports that have MSP enabled in his web flasher. the User then picks the port where he has the receiver connected to and this port is then enabled for passthrough. So its not fully automatic.

But I might miss something here. If he found a way to send that command to the Rx then it should work with bind too.

ohh ... ahh ... ohhh ... ok, fair enough. I missed that point.

[jlpoltrack]

Spot on. To clarify a little further, for both INAV and AP, you can only have 1 serial receiver so they can route the bind to the correct port whereas for MSP and MAVLink you can have multiple, so user would need to be able to pick which one.

[b14ckyy]

@jlpoltrack the question is now. How do you send the reboot command? Is that done before or after the Passthrough is enabled?
because if you do that after Passthrough enabled, then how do you handle different baud rates? (Rx on 230K and Passthrough on 115k)

[jlpoltrack]

How do you send the reboot command? Is that done before or after the Passthrough is enabled?

Reboot is sent after entering passthrough.

because if you do that after Passthrough enabled, then how do you handle different baud rates? (Rx on 230K and Passthrough on 115k)

My INAV update mirrors the baud rate on the PC if it changes while in passthrough, so you can enter passthrough at the baud the receiver is using for MSP (says 57600 for example) and then can still flash without problem at 115200. Relevant bit is here: https://github.com/iNavFlight/inav/pull/11256/files#diff-ee5073ff48ff08ac67809a1bc5ee88b59533dc6a12557b98ce9142c555a1c6eaR642-R646

[b14ckyy]

Ahhh perfect. That makes sense now.

Do you know why the Build Check failed on so many? I added Sensei to review your PR. I am not sure if there is a failure in the auto build process or something needs to be done to fix these. Some firmware's seemed to go through.

---

Regarding the bind_rx thing, I just had a chat with Olli:

For mLRS bind, we would need one of two options:

• A special MSP message that is sent out, but as already mentioned, this goes to all MSP-enabled serial ports. It would require a major restructuring of INAV to restrict this to a single serial port. If a connected device were to behave strangely, it wouldn't be a major issue since this would only happen when disarmed or on the ground.

• Alternatively, a message (MSP format or not) dedicated to mLRS where the serial port is specified in the CLI, i.e., bind_rx 2, which would then temporarily disable MSP on UART2, send the string directly to the UART, and re-enable MSP.

I can't say which is better.