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