Bootloader issues and uploading firmware

I was wondering if I could get some help with debugging my RadioLink Pixhawk(Radiolink PixHawk Advanced Autopilot w/ SE100 GPS - RobotShop). It no longer is able to upload firmware using ./waf and QGC. With ./waf it just hangs at the text saying “if the board does not respond in 1-2 seconds please plug it back in etc etc” (I have unplugged and plugged it and it and no change). Furthermore when trying to upload with QGC I see the following:

.

I have also seen persons suggesting to use Loading a bootloader with DFU — Dev documentation but I am getting issues to get it into dfu mode.

Additional Information:
System: Ubuntu 16.04
Tools used: ./waf and QGC.

Hi Shivrar,
First welcome to the community.
I assume you are pulling the boot pin high.
“When the pin is pulled up apply power to the board (eg. plug in the USB connector) and the board should boot into DFU mode.”

When the device goes into DFU mode you should get some sort of dmsg as it is now a different device.

1 Like

Hi jimdgit,

Many thanks. So I’ve tried pulling the boot0 to high in order to put it into dfu mode but that doesn’t seem to work but after consulting some experts who are familiar with the hardware it seems that may not be the case. So I’m attaching a photo of the pixhawk and the pad I may have been pulling high to enable this might not be the real pad, so I’ve gotten in contact with the producers with the board to see if they know and if that fails (God forbid) when time permits I’ll try tracing F4 from the chip in order to do this method. But due to the time crunch of my thesis I have to move on from this for the time being. Man thanks though and I’ll keep the post updated as I try to debug it.

Wow if that is the boot0 pin that is cruel and unusual punishment. It’s so tiny.

It may actually be the correct pin but you may not be holding it high reliably - an STM board we designed had a boot0 pin that was so hard to hold high we changed the design so it was two plated thru holes you could stick a pair of tweezers in.

It is in the usual location for boot0 for that board though.
Just for fun can you ask a fellow student to let you try it on a windows box?
It may not really need to have the bootloader reloaded. I have never actually blown out an STM bootloader but I suppose it could happen.

This is the STM dfu utility that will at least tell you if it is in DFU mode, and let you update the bootloader if you have proper DFU file:


Only supports windows.

Also here is a link to the datasheet if you want to ohm it out:


Good luck!