Firmware update via UART connection

Safranek42 · November 23, 2023, 12:23pm

Hi,

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 px_uploader.py 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: https://github.com/PX4/PX4-Autopilot/blob/1c8ab2a0d7db2d14a6f320ebd8766b5ffaea28fa/boards/px4/fmu-v6x/src/hw_config.h#L72 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: https://github.com/PX4/PX4-Autopilot/blob/1c8ab2a0d7db2d14a6f320ebd8766b5ffaea28fa/boards/px4/fmu-v6x/default.px4board. 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 mavlink_shell.py 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!
Benedek

JulianOes · November 23, 2023, 6:04pm

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

Safranek42 · November 24, 2023, 9:32am

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

Connected the Pixhawk to the uart (on a companion computer)
Connected the Pixhawk to a laptop via usb (so I can access its terminal via QGC)
Confirmed that telemetry is coming via the uart port, then stopped that process
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))
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.

JulianOes · November 27, 2023, 5:51pm

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:

github.com

PX4/PX4-Autopilot/blob/2734c44533dbfd360f4fbf4a5f3a47c237f8280f/Tools/px_uploader.py#L280


      
              return
          
          def __send(self, c):
              # print("send " + binascii.hexlify(c))
              self.port.write(c)
          
          def __recv(self, count=1):
              c = self.port.read(count)
              if len(c) < 1:
                  raise RuntimeError("timeout waiting for data (%u bytes)" % count)
              # print("recv " + binascii.hexlify(c))
              return c
          
          def __recv_int(self):
              raw = self.__recv(4)
              val = struct.unpack("<I", raw)
              return val[0]
          
          def __getSync(self, doFlush=True):
              if (doFlush):
                  self.port.flush()

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

github.com

PX4/PX4-Autopilot/blob/634ad3893e1eb5b47ac6a2252e3471c42f89a1bb/boards/px4/fmu-v6x/src/hw_config.h#L72


      
          #define SERIAL1_DEV    0x04
          
          #define APP_LOAD_ADDRESS               0x08020000
          #define BOOTLOADER_DELAY               5000
          #define INTERFACE_USB                  1
          #define INTERFACE_USB_CONFIG           "/dev/ttyACM0"
          #define BOARD_VBUS                     MK_GPIO_INPUT(GPIO_OTGFS_VBUS)
          
          //#define USE_VBUS_PULL_DOWN
          #define INTERFACE_USART                1
          #define INTERFACE_USART_CONFIG         "/dev/ttyS0,1500000"
          #define BOOT_DELAY_ADDRESS             0x000001a0
          #define BOARD_TYPE                     53
          #define _FLASH_KBYTES                  (*(uint32_t *)0x1FF1E880)
          #define BOARD_FLASH_SECTORS            (15)
          #define BOARD_FLASH_SIZE               (_FLASH_KBYTES * 1024)
          
          #define OSC_FREQ                       16
          
          #define BOARD_PIN_LED_ACTIVITY         GPIO_nLED_BLUE // BLUE
          #define BOARD_PIN_LED_BOOTLOADER       GPIO_nLED_GREEN // GREEN

Safranek42 · November 28, 2023, 8:23am

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.

JulianOes · November 28, 2023, 5:28pm

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

For the px_uploader.py 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.

Safranek42 · November 30, 2023, 10:06am

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

Safranek42 · December 4, 2023, 1:53pm

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

Currently mavlink_shell.py 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 px_uploader.py 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.

Safranek42 · April 23, 2024, 6:34am

@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.

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?
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.

JulianOes · April 23, 2024, 9:57pm

What are you using to download the file and what version? If MAVSDK, what version?
If you download via USB-C to the Pixhawk you are limited to USB 1 speeds as far as I know.

Safranek42 · April 29, 2024, 6:44am

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.
Thanks, then the speed makes sense.