Basic python script to setup Ardupilot passthrough

[brad112358]

And restart Rx in bootloader in preparation to use standard serial flashing tools

Based on earlier upgrade_receiver.py by Olli

This has been tested on Linux with flashing R9mx Rx. STM flashing requires Ardupilot passthrough parity PR soon to be submitted.

[brad112358]

See the Ardupilot PR here

[olliw42]

@brad112358 trying to try this it requires pymavlink, which I have not installed via pip (and don't want to for reasons of having my various own versions) it is mLRS/modules however, so I want to import it from there. This sort of thing usually works for me. I do have however problems with working out the import line (yeah, I'm pretty weak on such things usually). Any idea? got it, sys.path.append(os.path.join("..",'mLRS','modules','mavlink')) seems to do the trick

[olliw42]

@brad112358 I'm probably doing somethiong simple wrong, but can't connect STM32CubePorgrammer

I put your code into my BetaPilot fork: https://github.com/olliw42/BetaPilot/commit/cf228530f3a4c8163d26d7476b7f7dbd17992950

I've slightly modified the py script: flash_rx_via_ap_passthru.zip

this is my usb port and SERIAL setting for the mLRS receiver

from within the tools folder the py script appears to run fine I can see the receiver stop blinking

I then try STM32CubeProgrammer with option UART COM5 57600:

[olliw42]

a bit more tidied py script flash_rx_via_ap_passthru.zip

[olliw42]

I actually don't understand how this can work at all I mean, shouldn't the fc put into passthru AFTER the receiver was set into reboot? I find it surprising that that you can open the passthrough and then still talk to the receiver. Well, maybe not, but the passthrough ports must then be openend with no parity ... while later it needs even parity for the Cube ... If I reverse the order, doing passthrough after receiver boot it doesn't appear to work either ... very strange ...

[brad112358]

I ended up with this order because I was initially testing reboot shutdown via the script and doing the passthrough manually and I needed it in this order. But, if mLRS delayed longer when starting the bootloader, the order could perhaps be the way you suggest.

I actually don't understand how this can work at all I mean, shouldn't the fc put into passthru AFTER the receiver was set into reboot? I find it surprising that that you can open the passthrough and then still talk to the receiver. Well, maybe not, but the passthrough ports must then be openend with no parity ... while later it needs even parity for the Cube ..

But the USB CDC ACM connection is not a simple serial port.

This is the whole point of reflecting the baud and parity from the USB ACM to the passthrough serial port. Changes made on the PC side to serial speed or parity are noticed via the USB CDC protocols and the same change is made on the Rx serial port.

You run the script and get passthrough and the Rx in the correct state using the default parity (none). Then, the script exits and the port is closed. Then when STM32CubeProgrammer opens the port, it sets the parity to even which is reflected through Ardupilot to the settings on the serial port on the other side of passthrough.

The baud and parity used by the script doesn't need to match the baud and parity used by the programmer.

But I'm testing on Linux and you are on Windows and perhaps even though I have previously verified that windows correctly reports baud rate changes, perhaps it's not doing the same for parity setting which would be very unfortunate.

If you can't get it working, I'll have to try testing on windows. :(

[olliw42]

I understand the idea of this USB thing, and for baudrate one is using this all time ... my feeling however is that, at least on Win, it doesn't seem to work that way for parity ... at least, whatever I try I don't get it to connect

I wonder if it wouldn't be also easier to just add an OPTIONS parameter, with which one can set the parity

did you had a look at the code in my betapilot fork? not that I did a stupid mistake there ...

[olliw42]

EDIT: ok, stupid me ... I tried with a receiver which is F1 and for which serial is NOT on Uart1 ... GRRRHHH sorry man, will need to see what other of my many receivers will be suitable LOL

[olliw42]

so, also pulled out the R9MX ...

if I do first passthrough and then receiver boot, then it WOKRS !!!!!!!

if I do the reverse order, first receiver boot, then passthorugh, it does not work. Not sure I understand this, maybe the switch to passthrough puts out some level changes which the systembootloader doesn't like

anyway, GREAT JOB, sir !!!

the CubeProgrammer can be called via cli, so the script can be extended to do the full job ...

[olliw42]

why did you made the ardupilot PR a work in progress?

[olliw42]

that's btw my current py version: flash_rx_via_ap_passthru.zip made baud an optional argument and also tidied it a bit more into reusable functions

[brad112358]

why did you made the ardupilot PR a work in progress?

Because I'm not real happy with the replicated code in so many places. I may move what I can to the base class.

Anyway, thanks for updating me before I wasted too much time on getting things installed on windows.

Your version of the script is obviously much better looking. Should I test your version and then just close this and you can commit your version?

[olliw42]

just update your pr with that version ... you made the key step here ...

I wonder if not to add a simple tk gui interface ....

[brad112358]

No doubt, lots of features could be added, but I'd like it to also retain the capability of performing just the setup task from the command line so any serial programming tool can be used.

Does the reboot shutdown command work with the esp devices to start it's bootloader?

if I do the reverse order, first receiver boot, then passthorugh, it does not work. Not sure I understand this, maybe the switch to passthrough puts out some level changes which the systembootloader doesn't like

The automatic baud rate detection in the bootloader apparently works by looking at the time occupied by the first received byte. My guess is that MAVLink messages received after it starts have the wrong byte length on the wire because of the missing parity bit so it ends up choosing a baud rate which is slightly off. But it could also be getting confused by the content of the data I suppose. Your script implies that mLRS waits 5 seconds before starting the bootloader, but my version of the code seems to indicate it only waits 1 second. Ardupilot also waits 1 second before starting passthrough. I think if you make mLRS wait longer, it might work to do the reboot shutdown first.

[brad112358]

Since we can communicate with the Rx just fine via passthrough to start the bootloader, the order I use is reliable. But, the other order has the advantage of not even needing to specify a baud rate which matches the rate used by the Rx. Any baud rate would work. So if we can get it to work reliably starting the bootloader first and then setting up the passthrough, we can eliminate the need to specify the baud rate of the Rx.

[olliw42]

Does the reboot shutdown command work with the esp devices to start it's bootloader?

I don't think so, don't know however

we can eliminate the need to specify the baud rate of the Rx.

I think we also could do that by simply reading the baud setting for the specified SERIALx

I'd like it to also retain the capability of performing just the setup task from the command line so any serial programming tool can be used.

yeah 👍

working on tkinter GUI just know, seems to be not so difficult LOL

[brad112358]

just update your pr with that version ... you made the key step here ...

I did test your version on Linux, and of course, it works just fine.

I'm not worried about credit in the git logs. You wrote most of this code and it sounds like you are on your way to a full GUI. It really makes more sense to me to get out of the way at this point. If it's OK, I'll just close this.

[olliw42]

runs gui when you don't give any params: flash_rx_via_ap_passthru.zip

:)

[brad112358]

runs gui when you don't give any params

Cool! Looks like the GUI works on Linux too. I'm closing this PR now. Comments still work if we want to discuss this more here. I'll let you take it from here and I'll focus on cleaning up the Ardupilot PR next.

[olliw42]

with flashing flash_rx_via_ap_passthru2.zip

maybe you can test this too on linux ...

the script will need some robustifications here and there, to catch error situations, like com port not existing, already in use, and such things ... but it runs through for me ... kind of cool actually

I think we also can avoid the baudrate b yreading it from the fc

[brad112358]

with flashing

It ran fine until it looked in the wrong place stm32_Programmer_CLI.exe.

I'm not sure why you included the windows executable in the zip file; that doesn't help much on Linux.

I suppose we need some tricks to find the tools like in run_make_firmwares.py. But for some reason I didn't install the programmer in /opt so it's in a directory off of my home directory and it's also not in my path. I need to check where the installer normally puts it.

[olliw42]

I'm not sure why you included the windows executable in the zip file; that doesn't help much on Linux.

haha ... you of course are right LOL ... I just quickly copied over what I do for my STorM32 project maybe we can add what is needed for linux too? or do some find the thing magic as you suggest

anyway, if you don't specify the firmware file, it should run maybe the easiest is to just exclude that option if the os is luinux

btw, I've pushed a pr with a version3, which does also find the baudrate