Firmware update via UART connection


I have asked this on the Dronecode Discord channel, but got no answer so I’ll try it here as well.

I’m trying to flash firmware to a Pixhawk 6X board without using QGroundControl. I’m using the script from the PX4 repo’s Tools folder, and I successfully flashed the firmware binary .px4 file via USB. My main goal would be to do the same with UART connection. I found this piece of code: that would mean that via ttyS0 I would be able to flash the firmware using baudrate 115200. Since that port originally is the gps port, I reassigned it to the TELEM3 port (easier to access for me) here: However, I’m only getting Attempting reboot on /dev/ttyTHS1 with baudrate=115200... If the board does not respond, unplug and re-plug the USB connector. exception in idetifying bootloader: __getSync unexpected b'\x00' instead of INSYNC (The name of the function in the error message is not in the original code, I put it there as there are two identical error message from two different functions.) response from the script. I tried powering it before, and after connecting the UART, but that did not help Is there anything I’m missing or doing wrong, or is the flash through UART not possible at all?

I’m having the same problem with the script. Via USB I can open the flight controller’s nuttx shell, with UART connection it is stuck at “Connecting to MAVLINK…”.

The UART port works if I use mavsdk-python, I can get telemetry and send commands to it.

Thanks for any help!

Try rebooting the Pixhawk using the command reboot -b. It should then stay in bootloader mode and you can try the script again.

Thanks @JulianOes, I have tried it, but didn’t have success:

  1. Connected the Pixhawk to the uart (on a companion computer)
  2. Connected the Pixhawk to a laptop via usb (so I can access its terminal via QGC)
  3. Confirmed that telemetry is coming via the uart port, then stopped that process
  4. Gave reboot -b command in the mavlink shell. The board went into bootloader (did not reconnect to QGC and the middle I/O LED started blinking orange, I believe it is some kind of bootloader error (from here))
  5. Tried the px_upoader script with various baudrates as well. I tried also starting the script first and then rebooting the board into bootloader mode. The output of the script is always
Attempting reboot on /dev/ttyTHS1 with baudrate=115200...
If the board does not respond, unplug and re-plug the USB connector.

(With the baudrate I’ve given it.)

Edit: When I use the script via USB, and it runs successfully, I don’t need to run the manual reboot command; also the orange led in that case blinks the same way as it does when I manually reboot it into bootloader mode.
I’ve also noticed that cat command only sees traffic on that port after I start mavsdk_server once (I can stop it and still see the incoming bytes). I tried experimenting with starting and stopping it and then running the uploader script, but it didn’t change anything. However, running the uploader script stopped the traffic on the port. In bootloader mode there is no traffic visible on the port.

That’s expected. It’s now in bootloader mode and no longer sending mavlink.

Also expected. However, it should respond to the sync bootloader commands.

First step would be to uncomment this print statement to check if the bootloader is talking:

And then, what version are you trying this with?
I just checked and it looks like the baudrate is 1500000 with v1.14:

First step would be to uncomment this print statement to check if the bootloader is talking:

That print does not print anything, but if I put a print before the if statement then that on prints, so the error is raised inside the if.

And then, what version are you trying this with?

1.12.3 and 1.13.3 based custom firmwares, most of the customizations are in the modules and the airframes; the boards were only modified to add the missing telemetry port TELEM4.
Those versions have 115200 baudrate set for /dev/ttyS0.

Oh I see. At this point your debugging is as good as mine.

For the script it’s often tricky as it hides a lot of errors using blanket try-excepts. I usually add prints in all the excepts to check what is going on.

I’ll continue trying it, and I’ll put here if I find the solution.

1 Like

Some improvements after I have changed the UART cable to a shorter one (now about 30cm).

Currently works, if given the correct baudrate.
The shorter cable also enabled to download ulog files via mavsdk-python (although the max speed that I could achieve so far was 0.23MBps).
Now the puts the board into bootloader mode, but then gets stuck again at the same line, now receiving empty strings instead of INSYNC.

Strangely (for me) the setting of the --baud-bootloader parameter affects whether the board is sent into bootloader mode or not.

@JulianOes finally we determined that the USB of Pixhawk 6X board is better and easier to be used. Firmware flashing and parameter update works fine with that.

However there are 2 strange behavior when trying to download a logfile from the flight controller.

  1. For large logfiles (bigger than around 100MB) the download gets stuck and hangs indefinitely. We have also tried to download a random binary file of several 100MB, and that seemed to work fine. We are still investigating it, but do you have any idea what could cause it to hang up the logfile download? We have tried increasing the mavlink timeout, but it had no effect. Maybe the underlying grpc has its own timeout value?
  2. The maximum download speed achieved was around 300kB/s. This is pretty far from both the USB2 theoretical maximum and the SD-cards reading speed. The behavior is the same when downloading via QGroundControl, where the max download speed I can achieve is about 500kB/s over USB (in this case the USB C connector). Even when running sitl simulation and connecting to it with QGroundControl, the max logfile download speed is only 1.7MB/s. What is it that slows down the download speed so much?

For not-sitl setup, we are using mavsdk python and its ftp plugin.

  1. What are you using to download the file and what version? If MAVSDK, what version?
  2. If you download via USB-C to the Pixhawk you are limited to USB 1 speeds as far as I know.
  1. We are currently using mavsdk-python version v1.4.17. We could get it work with a ~700MB logfile, butfor a 2GB one (max possible size on NuttX) it still gets stuck.
  2. Thanks, then the speed makes sense.

Got it, likely some int overflowing somewhere. If you can create a github issue that would be great.

If this is urgent for you consider sponsoring me.