Why does Q Ground Control recover flight controllers that are "dead" to Mission Planner?

This afternoon one of our interns was installing firmware on a Pixracer when someone else pulled the micro USB cable. No matter what we tried (changing micro SD card, firmware type, etc.) we could not boot and install firmware in Mission Planner. I was about to put the Pixracer in my “good” container, when a 10 year old boy took it, and used Q Ground Control to erase and install firmware. Shocked, I took another “good” Pixracer from the container that was labeled “no boot, no firmware install” and replicated the process with Q Ground Control. My question is, what does Q Ground Control do differently from Mission Planner that enables boot and install of firmware on an otherwise dead to Mission Planner Pixracers. I tried with several more “good” Pixracers and all were resurrected with Q Ground Control.This may seem like a “so what” type of question, but if the answer can be determined, perhaps a change in MIssion Planner would be in order.


I’ve noticed the same. When I’ve managed to totally brick a Pixhawk 2.1 Cube, mission planner won’t see it. But QGC seems to totally finie and recovers it just fine.

1 Like

I need someone to work with me to get to the bottom of this issue.


I would be happy to. I have several PixRacers, have seen this problem also and resolved it the same way. I have one on the bench from a crashed quad that is “expendable/available” for this diagnostic purpose.

It currently has 3.6.0-rc6 Chibios loaded and MP won’t flash back to 3.5.7 (QGC will) so we could start with that?

I certainly appreciate the effort. We have wildlife protection drones around the world on arducopter and arduplane with Mission Planner the primary GCS followed by Tower. Most of the smaller aircraft are equipped with Pixracer. So far only Q Ground Control resurects the failed flight controllers.

what I would need is, how the device appears in device manager, the vid and pid of the device. and the missionplanner.log file from c:\programdata\missionplanner\

also did you update the bootloader?

can you guys test beta MP.
I made a few changes.

and I added one other option
but try the normal way first

the new method is open the firmware upload screen
then unplug/plugin the pixracer.
there will be no extra display, but the pixracer should now be in bootloader mode
then click the firmware you want as normal

In Device manager it shows as “STMicroelectronics Virtual COM Port (COM5)”. Attached is the log file. I’m not sure what you are asking with vid and pid. I didn’t update the bootloader just updated the firmware to the Chibios version as normal in Mission Planner.

MissionPlanner.zip (19.9 KB)

After updating to MP beta and attempting to flash to current stable it produced “error the port is closed” and a dialog box “error updating firmware” and now in Device Manager the board is shown as "Legacy FMU (COM6). MP won’t connect to it.Again used QGC to flash to current stable and it now connects in MP still identified as "Legacy FMU (COM6)

while in bootloader mode, you cant connect. I just want to mention that. as I feel things are getting confused.

  1. open mp goto firmware
  2. try upload a firmware.
  3. what happens?
    and provide me a log just after this.

OK, 3.5.7 was installed and I uploaded 3.6.0rc-6 selecting the Chibos option. It uploaded successfully. log attached after performing this.

MissionPlanner.zip (19.7 KB)