Yes, I am on the most recent - v3.5.2
Another thing that may be related is I don’t think the new Cubes respond to the USB reboot commands the same way. The command line tool that I use (the px_uploader.py python script in the PX4 repo) used to work more robustly:
On older cubes and other flight controllers, I can have the flight controller plugged into the computer prior to running the upload script and it would reboot the vehicle to the boot loader and upload the firmware just fine.
Now, with the newer cubes that have the upload issue in QGC, I must have the flight controller disconnected when I run the script, and then plug in the flight controller once the script is sitting there waiting for the boot loader. This is the only way it is successful now.
If this is on Windows the first thing I would do is make sure you have installed new PX4 drivers. A re-install of QGC Stable should give you that option.
I had tested firmware upload with the Blue Cube and ArduPilot bootloader. But let me try that again.
I am on Ubuntu, but I can try on a Windows computer just as a comparison.
Ah, ok. No that’s fine.
Actually now that I say that trying on Windows would be useful. I don’t have native Ubunutu only a VM and flashing on that generally doesn’t work. So I can’t really verify that directly.
Also what you show as dmesg output is correct behavior. The ArduPilot bootloader first shows up and then the PX4 code takes over.
OK, I will try Windows in a little bit and let you know what happens.
I do know the dmesg output is different now from what it used to be on the older cubes that work. On the older ones, only the second portion shows up. I never see the CubePilot part, only the 3DR part.
That’s because of the new bootloader. Old bootloader would have transitioned from “Product: PX4 FMU-BL v2.x” to “Product: PX4 FMU v2.x” if I remember correctly.
Which shows itself exactly how in QGC?
I’ve verified to OSX is working fine with this combination which is the closest I can get o Ubuntu flash.
Also can you try a daily build on Ubuntu. Daily should be equal to stable with respect to ArduPilot bootloader support. But maybe I missed carrying something across.
Also wait on trying new Windows Stable. I just realized that it’s not updating the drivers correctly.
It happens too fast for me to get a screenshot, but it says it’s normal “detected …” and then it rapidly says “upgrade cancelled” and then the parameters load and it goes to the Summary tab.
Ok. Can you create a QGC Github issue for this with details. Forum is a crappy place to try to figure this out from. Then from there I’ll point you at next steps.
QGC Github issue here:
I mentioned in that post, but I did just try the latest daily build. There was new behavior. It looked like it was working (it didn’t immediately kick out into a normal boot) but right when I hit the last “OK” it seg faulted and crashed the program.
I’m trying to load the latest firmware to a “new” (just back from the reseller “Fixed”) Pixhawk 2.1 Cube Black. Mission planner says an update is available, but when I try to get it there is a Hash not matched failure. This has happened repeatedly yesterday and today. Any ideas?
For anyone following along this thread, but not the GitHub issue. The latest QGC daily build works correctly. I may or may not be able to backport whatever fixes are in there to a new Stable.
1 Like
Hey Don,
Sorry, I’m a new here. Where would one go to find the most recent daily that resolves the bootloader issue?
Hi everyone,
I just got my cube orange and have been experiencing the same issue. I am trying to flash px4 through QGC daily (tried on multiple devices and both on stabile and daily version).
I followed everything written here and on github. I am using Win 10 and downloaded daily release of qgc, however the issue is still present.
Do you have some suggestions?
Also you can see video here https://www.youtube.com/watch?v=S8k_tIdjeHk&feature=youtu.be
Thank you
Dusan