I’m still trying!
This is what appears to happen.
Mission planner (latest) running on Win10 tablet. Power Pixhawk from USB cable (after fresh boot of windows) and device manager sees it as ‘STMicroelectronics Virtual COM Port (COM 10)’, Pixhawk boots Arducopter 3.6.8 and can hear normal startup tones. Can then connect from MP no probs.
If I try firmware update to v4.0.3 using the Legacy tab, it detects the Pixhawk OK (as fmuv2), then asks me Is this a CubeBlack? - I answer No, then asks me Upload ChibiOS?, I say Y, it then asks me to unplug, press OK and replug USB, I do that and the Pixhawk boots, and goes past the bootloader without being picked up by MP, and then I hear the tones again, so its booted Arducopter at this point, bypassing the bootloader. So almost like the bootloader is screwed. If I force it into bootloader then it appears the same as I describe below I.e. DevMgr shows it as Legacy FMU (COM 9) - I am unable to flash with it in this state as it doesn’t locate the port. If I unplug USB and replug after this it sees it as Legacy FMU every time.
If I try the (non legacy) Install firmware tab, it gets to the scanning commports part, I hear the device being detected in windows again then displays ERROR: No response from board. I then see in DevMgr the port displayed as Legacy FMU (COM9).
EDIT:
When the Pixhawk appears in Device Manager as ‘Legacy FMU’ as described above I don’t hear the tones during boot, and think its likely stuck at the bootloader here. If I unplug/re-plug usb after this it returns as Legacy FMU every time and the only way to get it to appear as STM… again is if I switch out of the firmware screen in MP then switch back, then re-plug USB - it then comes back as STMicro… (COM10) again.
where the first port is the regular one and the second port is the bootloader one. This mostly works for me, but requires that you have the source code. I am on WSL.
Finally got the firmware update to happen! Thanks to Q Ground Control. I uninstalled QGC and installed the latest version from scratch. The install goes through the driver installer - looks to be the same installer that MP also deployed during a clean install. I was able to follow the standard QGC Ardupilot firmware install and it just worked! I tried since using MP again and it fails to locate the com port of the bootloader - so I suspect this is an issue with the latest version of Mission Planner. One for Michael Obourne!
Further to my last update, I managed to get the bootloader to upgrade using Mission Planner. The key was getting the pixhawk on the latest firmware first (thanks to QGC). Strangely I still see the Pixhawk servial poirt show up in Windows as the original STmicroelectronics Virtual COM port, and not as the new name that the documentation suggests. I also tried a further firmware update in MP since upgrading the bootloader using the first firmware tab (not legacy) , but still the update fails strangely. I also ran the driver cleanup and reinstalled the drivers using the versions provided with MP (as QGC install had replaced these), but still no change to any of the above on these new drivers.
I have not yet figured out if you finally managed to upgrade the bootloader, I have the same problem as an fmuv2 fc and I have never been able to upgrade.
Thanks
That’s a good point Marco. Even though the bootloader upgrade process returns a popup box saying bootloader upgraded, I am not convinced it actually happened as device manager still shows the com port with the old STMicro… name.
The entire upgrade process I went through yesterday was a bit of a nightmare. I hope one of the devs sees this post to see if they can reproduce the issue.
I upgraded the bootloader, from PIXHAWK 1 2MB .- fmuv2 to fmuv3 I am writing to you the steps I have done.
I opened Qgc to flash firmware 4.03, selected Ardupilot, Chibios, FMUV3, advance settings, standard version (stable).
I waited for the firmware and bootloader flash, and immediately when QGC reconnected to the drone I saw "connect to bootloader version 5 and no longer version 4.
I connected with mission planner and as you can see now it’s FMUV3 and no longer FMUV2, everything works properly.
I had the same problem and thought my Pixhawk was bad. So I ordered a new Black Cube, Carrier Board plus GPS from Hex. Now with QGC my old Pixhawk is good to go. Guess I’ll build something else.
Marco, I think we could have done with better/more detailed information related to bootloader update from the devs. I still have no idea if I have the correct bootloader/flight stack on my original Pixhawk (with 1M bug). Also, I don’t see in your described process where you updated the bootloader. In QGC the bootloader upgrade is carried out once connected then access the firmware tab then check the advanced heck box which then shows the option to specifically update the bootloader. I don’t see that visible in any of your images.
In your proces, fmuv3 being reported at startup is due to you selecting the firmware for fmuv3 and nothing to do with the bootloader.
Yes you are right I forgot to write that in the firmware update screen, there is a tab with chibios bootloader and you have to click on it and then choose the type of firmware. my pixhawck however has 2Mb and not 1.
the bootoader is also updated if you click on Bootloader chibios because BOOTLOADER VERSION 4 was displayed before and when I upgraded, Mission planner displays BOOTLOADER version 5.
I have 2 FMU v2 2.4.6 Pixhawks and 3 FMU v3 2.4.8 Pixhawks. I didn’t know the 2.4.8s were FMU v3 with 2MB of useable flash memory until I flashed the boot loader. I tried the same thing with the 2.4.6s and they stayed FMU v2.
Thanks guys, I tried many things to update my PHL from copter 3.6.4 to 4.0.3 using the latest MP (1.3.72), wasted a bunch of time trying different usb ports/cables, rebooting and different PC’s, till I found this thread, tried QGC and first try, boom, done, must be a MP issue.
Yes, MP has an issue uploading firmwares to Pixhawks with the older bootloader. Once you get the new firmware on there, if you upgrade the bootloader then MP will work again. I’ve reported this issue to @meee1 as well.
