Pixhawk 2.4.6 solid 'red' power LEDs. Is it bricked?

Hardware Pixhawk family
1

Hi. First post. Thanks for having me.

I bought a used Pixhawk 2.4.6 but I can’t load the firmware on a PC using Mission Planner OR on a Mac using APM 2.

Both power lights are glowing red instead of green. (Well, more and orangey red. But not green)

In mission planner, the PC recognised the board on COM5, so went ahead and downloaded the firmware, but when I get to the part where I unplug, click ‘OK’ and plug it back in, it searches the comports and reports an error, saying ‘no response from board’.

When I tried it on the Mac, on the update firmware page, the various configuration options weren’t showing.

I tried booting the Pixhawk holding the safety button down, but no joy. I tried booting it with the SD card out. No joy.

Is this thing a brick or can it be salvaged?

Thanks in advance…

1 Like
2

Are the power lights on each side the only ones that light up? Nothing else?

I had a simillar issue on one of my pixhawks… But as far I can tell those LEDs on the side are single colour (correct me if I’m wrong anyone) so yours happens to have orange ones, and they light up so power seems ok.

I my case it was a blown IO processor… lets hope It’s no hardware issue in yours (i dont think it is, for now).

Seems like the bootloader has packed up. This is what runs as soon as the MCU boots, and loads the main OS etc. MP has to communicate with it when flashing the firmware (hence the disconnect and reconnect. MP tries to catch the MCU in bootloader mode), and your bootloader isnt responding. You’ll need a to reflash it.
Try this: https://ardupilot.org/dev/docs/using-DFU-to-load-bootloader.html

This should work. If your cannot find / run the specified DFU utility, use this: https://www.st.com/en/development-tools/stsw-stm32080.html <<I’m not sure this will work, try the specified utility and use this as a last resort.

Good luck! (I know how frustrating these harware (or is it software?:unamused:) problems can be :joy:)

2 Likes
3

Ha. Love your username. Sums up my current state of mind perfectly.

Hey, thanks for your reply.

To answer your initial question, there ARE other LEDs glowing.

The FMU PWR is solid orange. (BTW, every single YouTube video of a Pixhawk 2.4.x shows green power LEDs. The Ardupilot LED page just tells me it means ‘error’. ) Below the FMU PWR LED, the B/E LED is flashing red quite quickly.

On the other side of the Pixhawk, the IO PWR is also solid orange. Below that, B/E is solid red and ACI is flashing blue, about twice per second.

The main LED near the ‘forward’ arrow sometimes glows blue, sometimes red and occasionally white, dependant on what I’m trying to do at the time.

When I plug the Pixhawk into Windows, the computer makes the proper ‘noises’ and recognises it on COM5. The Pixhawk also makes its happy, chirpy ‘I’m OK’ sounds.

Moving on to your suggestion, it sounds promising, but I had a look at that page you linked me to and I have no idea how to do this-> "pulling the “boot0” pin high on the processor when it is powered on."

Any chance of a quick tutorial?

1 Like
4

Hehe… I’m all too familliar with that mindstate!:joy:

Right. Intresting. I think on the LED page they are talking about the main LED, it is solid red when the pixhawk is in error, not the FMU PWR or those other small ones. The pixhawk 2.4.x is open source hardware, so different manufacturers will put different colour LEDs (pretty sure those small LEDs are single colour) and you just happened to have got one with red LEDs (congrats, they may be very rare :joy:)

Hmm… so this means there is some sort of AP code running on the pixhawk (if the chirpy noises and main LED works)… Looks like the damaged bootloader isn’t allowing you to update it.

No problem, a quick tutorial it is!

So, stm32 MCUs all come with the factory bootloader on them, which cannot be erased, and this what they mean by DFU mode. The way you access it is by giving +3.3v (NOT 5V!!, it could damage the MCU) to the boot0 pin and 0v to the boot1 pin (which, on the pixhawk, is already grounded so no need to worry about that) on the MCU and then powering it on, and it should land in DFU mode.

Now usually most pixhawks come with a pad that goes directly to the boot0 pin on the MCU, and DFU can be accessed by soldering a jumper from it to a +3.3v pin on the board and then powering on, but the issue here is most. One of my pixhawks didnt have it (atleast not at the specified location). Could you post a detailed picture of both sides of your pixhawk board (open up the case and send the internal board) so I can try and point out this elusive pad?

IMPORTANT - There may be 2 boot0 pads of your pixhawk, one is for the IO processor, and the other is for the main FMU, the latter is the one we need.

Are you okay with the software bit? If you need any help with that, just ask! Lets get back to it once we’ve identified the boot0 pad.

Also, read this: How to enter DFM mode on Pixhawk

[edit] One more thing: your sure its not a pixhawk to PC communications issue that preventing the firmware update? Usually bootloaders don’t just go ‘missing’… Maybe something happened, I’m not sure. Can you connect over mavlink? (assuming some AP code is running on the PH). Lets keep trying the DFU as well, you never know.

1 Like
5

Thanks heaps mate.
To address your final paragraph first… When I plug the FC into a Mac running APM Planner 2, or into a PC running either APM Planner 2 or Mission Planner, the computer recognises it and selects the appropriate COM port. The FC then does it’s little chirpy tune.

In APM Planner, on both machines, the aircraft configuration choices don’t show when I select ‘Install Firmware’.

In Mission Planner, I get to choose which aircraft I’m using, then it downloads the software, asks me to disconnect, press ‘OK’ and reconnect.

After some time of scanning the Comports, it responds that there is “no response from board”.

Not sure if that answers your question…

I’ll go pull the board out now and take some photos. (I ‘SHOULD’ be OK with the software side… but don’t go away!)

Back soon…

Thanks again for your help.

1 Like
6

High(ish) res photos in links below…

Top of Pixhawk

Underside of Pixhawk

1 Like
7

Here’s something else I just discovered…

I tried to connect to the Terminal Console in APM Planner 2 and this happened…

Youtube link to video

1 Like
8

If you just need to get firmware loaded or updated try QGroundControl.
I’ve noticed the same sorts of issues with MissionPlanner, but it seemed to be more reliable when I went into (windows) device manager and set the default port speed to 115k baud as each new com port is discovered.

2 Likes
9

Very intresting… Seems like you are on the wrong baudrate, hence the garbled nonesense (in the terminal). 9600 should work. Also, your pixhawk is bieng detected as a legacy FMU, which I believe should not be happening. Could you try it with all the other hardware, external LED and all, removed? What is the internal Main LED flash sequence like then?

Seems like some sort of AP is running on it (chirpy noises and main LED), so we can assume that the bootloader works okay… (assume!) But your FMU is still bieng misread as a legacy, could be a number of reasons.

Try changing the baud rate to 9600 and uploading the firmware again (although I suspect this may not fix it, lets just try it) If it doesn’t work, We know it is defenitely a bootloader or connection issue.

I’m not entirely sure about APM planner, but try the baud rate change on mission planner. Also, try connecting ‘normally’ to the pixhawk over mavlink from mission planner (don’t go to firmware update) and see if you get the HUD moving etc. If an okay AP is running on the pixhawk and the GCS connects, we can rule out the connection issue entirely and go straight to DFUing a new bootloader.

If it doen’t connect over MAVlink, it could be either a connection issue or becuase theres no proper AP running on the board, and to fix this, we will have to resort again to DFU.

DFU, which I will guide you through, is not too difficult. That HAS to fix it, and I’m pretty sure it will, if the baudrate change didn’t.

The good news is your pixhawk has the necesary pads, labelled correctly (yay! :grin:) so if we have to do a DFU update it shouldn’t be too difficult…

If none of this works, lets go straight to a DFU bootloader update,

1 Like
11

Thanks xfacta.

I went into device manage and it was on 9600 and I changed it to 115200 as suggested above, but same old same old.

However… QGroundControl has been able to make a connection. Looks like I’ve got to learn another piece of software.

If this works out, I’ll drop Mission Planner and APM Planner completely. I don’t want a different software for each aircraft…

1 Like
12

Hey insanity. I went into Device Manager as suggested above and it was already on 9600.

That screen shot was from APM Planner on the Mac. The windows version of Mission Planner showed the correct hardware. APM Planner on the PC showed the same as the Mac.

So I’ve downloaded QGC and so far it looks like it may get me out of trouble…

I’ll keep you both informed of my progress later this evening. Currently involved in replacing the flyscreens on my patio doors. Keeps out flies & mosquitos, but not dogs…

13

I’ve edited my prevoius post a bit, have a look at it again, Thanks.

Awesome! so QGC connects… as in over mavlink? Try the firmware update.

This has never happened before to me… (MP not working but QGC does) this is very wierd… What version of MP did you try? Thanks @xfacta… I had no idea!

14

Mission Planner 1.3.71

Anyway, I was able to configure the quad using QGC on the Mac, calibrated all the sensors and calibrated the radio. So the FC ‘IS’ able to communicate with the computer over USB.

I don’t like QGroundControl. I just got used to Mission Planner and there are heaps of YouTube videos on MP. Not much on QGC. I’ve now got to the flight modes part and it’s a bit more complicated than Mission Planner.

So I put it back on the PC and tried Mission Planner again, hoping that the QGC experiment shocked it into behaving.

Nope. Still saying there’s no response. So QGC it is then…

1 Like
15

In MP, have you tried to connect over mavlink? (not firmware update)

image
image2014×386 282 KB

Yeah… same reason I avoid QGC… But MP should have the same functionality…

Also, if you want you could try a firmware update over QGC and see what happens…

16

Yes. I did do a firmware update on QGC and set up a new quad. It looks like it worked :smile: If I move the FC around, it shows the movement in the on screen horizon and compass.

So… we know the Pixhawk works. We know the computer can see it. We also know that the FC can communicate back to the computer. What I don’t understand is why MP continues to say it gets no response from the board?

1 Like
17

I’m going to try downloading an old version of MP…

18

Awesome!! Great work. Glad we didnt have to get our hands dirty in DFU :wink:

I use MP 1.3.70 which works great. Does it say no response only when uploading FW or also when connecting via MAVlink?

19

The older version actually responded to the FC. So there was some level of success. But then I couldn’t get into the mandatory hardware page. It was a version from about September '18. It’s gone now. Deleted it because…

…I had another look at QGC and loaded the Ardupilot version instead of the PX4 version. It’s more like Mission Planner. So I think I’ll stick with it for now.

Thank you so much for your help.

1 Like
20

All the comms is set to 115k baud for USB right? Not 9600baud…
And 57600 is used for telemetry radios.

APM Planner only does mavlink ver1 so there’s limitations with that too.

21

Have you tried uninstalling mission planner then installing the newest version. It installs newer drivers during a clean install that aren’t done during an update. I had a similar issue, mission planner couldn’t get mine into bootloader mode to flash it, but qgroundcontrol could. So I used that to update the bootloader on my pixhawk (so it was recognised as a 2mb model). Once I’d done that and clean installed mission planner (this is probably enough if you don’t want to do the bootloader update) it’s worked ever since which is good as I much prefer it to qgroundcontrol.

1 Like