So, my Pixhawk which were behaving a bit erratic failed during updating to AP 3.3 and my PC will no longer recognize it as a USB device.
Is there anyway of connected a FTDI to it and attempting recovery that way?
So, the DFU software can see it, it can upload the new bootloader and will then promptly crash when trying to verify it.
I think this Pixhawk is very dead.
I submitted a ticket on Sunday…yet to hear anything back.
So much for ‘support’.
It’s out of warranty, but they will not tell me what the warranty policies are. They did offer 15% discount on a new Pixhawk and it’s better than a kick in the teeth, but not by much.
The whole point of buying an official 3DR product was for reliability and support, but it seems that they offer neither.
I had a chat with Tridge about it. He will look into the issue but it might take a few days because he is working on another important issue at the moment. He or me will keep you updated on the issue.
Ok, first, how does the Pixhawk behave after boot? LEDs? Tones?
Then, please post EXACTLY what you did with DFU, which tool you used, which operating system you are on and the COMPLETE output of the tool, including how it reports your Pixhawk. If possible, please find out as much as possible about your Pixhawk, when you bought it, serial number, etc. and post the information.
Please try the following:
Connect the Pixhawk to the PC.
Open a terminal program and try to connect to the Pixhawk.
If you see “nsh>”, type “df” and post the output
If that doesn’t work, please pull the SD card and read it with a PC.
Try to find /APM/BOOT.LOG and post the content here.
Please also describe, how you got your board into DFU mode? Did you put any bridges to the board?
Right. I can now report that it’s completely dead, so you may not want to waste your time, but in any case:
I have 2 PC’s for this: An older laptop on my workbench running Windows 7 and a desktop PC running Windows 8.1 at ‘home’. Both have been used for firmware updates for various arduino’s, gimbal controllers, etc. (And yeah, it’s a pain to get the drivers set up on Win8).
Here’s what it did after the first failed firmware update:
youtube.com/watch?v=smqY8fLOkqc
Take the SD card out and it would light up red.
Same behaviour without holding the safety switch down.
It would show up on the PC as an unrecognized USB device and no amount of un-installing and re-installing drivers would do anything and mission planner could not recognize it in any way or form.
I tried re-formatting the SD card, same thing.
3DR support then recreated that behaviour by unplugging a pixhawk during update and told me that I could fix it by having a powered USB hub ensuring that there was enough voltage.
Now, I’m fairly confident that the USB 3.0 port on my desktop PC provides enough voltage and I could not restore it. I borrowed a USB hub and got same result.
I was then about to bin it, when I then decided to give QGroundControl a go and lo & behold, it would see it and force a firmware update on it and it would show up as PX4MU in the device manager. It wouldn’t boot properly, but QGroundControl would at least connect to it, even if it wasn’t getting anything back.
I then opened Missionplanner and happily updated it to Arduplane 3.3…but it still wouldn’t boot and behaved like this:
youtube.com/watch?v=MpA9IndmS2Q
youtube.com/watch?v=xeTY9Zd3oI0
I then went back to DfuSe Demo v3.0.3
I got it into DFU mode by shorting the FMU_BOOT0 and VDD_3V1101 pads
i.imgur.com/7Ymsgr5h.jpg
Following the instructions here, didn’t really do much:
I would choose the downloaded file
It would ‘upgrade’ very quickly and if I tried to verify, DfuSe would crash
However, if I selected the file under ‘Upload Action’ and same under upgrade, it appeared to upload it correctly and would also verify it.
It changed nothing, however. The main status LED would remain blank and even if I re-uploaded the firmware with QGC and MP respectively, nothing would change and I gave up and put the Pixhawk away.
Then when I saw your posts this morning (And support finally replied to me too!), I went to plug in the Pixhawk and nothing happened. Tried the USB hub and a different USB cable same, thing. In the unlikely event something got shorted when I put it back together I opened it up, but there was nothing obviously shortened and nothing fell out of the case when I opened it.
Not a single LED lights up.
Unfortunately it appears that one of the last things I did before I put it away, was to try yet again to reformat the SD card and it’s still empty, so I have no boot.log 
I might have an older one from when it first failed at my workbench, as I did copy it over before I started messing around with it.
Hi Implicit,
If the large 3-color LED near the microSD slot comes on then the bootloader is working. That LED cannot come on unless the main FMU firmware starts.
Using DFU to change the bootloader is a bad idea. If the LED came on previously and no longer comes on then it may be that the bootloader is now corrupted due to the DFU attempts.
If the board is now in a state where the LED doesn’t come on and you want to continue debugging it then you have two choices:
- attach a serial debug cable to the serial5 port, at 57600 and capture the output of the boot process. See this page: pixhawk.org/dev/wiring
- if you don’t get anything on that then you would need to solder on a JTAG header and use a JTAG adapter, such as the black magic probe
Cheers, Tridge
The main LED stopped before I succeeded in using the DFU tool.
Again, neither the FMU or I/O LEDs are doing anything now. I get no reaction at all when plugging it into the USB.
I’ll try hooking it up to the powermodule to see if it’ll attempt anything that way.