Whenever I initially use the latest version of Mission Planner, I reflexively "upgrade" the APM 2.5 firmware. It's an instinct I've developed after working with computers for 30+ years to make sure everything is concurrent, and I've done this for the last 6 revs of the MP. I take it this is different than flashing an ordinary eprom, because reflashing something usually results in damage to the eprom. Besides, it would see that the firmware is up to date and wouldn't touch it... right?

I DL'd MP 1.2.52 did then 'upgraded' the firmware (which was already 2.9.1b, but y'know how reflexes are). Now it won't connect to the MP, nor will it arm the motors from the Tx. The usual blue and red LEDs aren't lit but the Tx/Rx LEDs are active. It's appearing in the device manager as "ArduinoMega"

The reset button on the APM doesn't seem to do anything...

I'd reformat the eeprom, but I can't connect to the MP...

Any ideas?

Views: 7326

Reply to This

Replies to This Discussion

Everything disconnected except USB: The blue light flickers for a split second then stays dark, and the green LED by the GPS port is lit.

I reconnected everything (like I had before, except the telemetry and the power module which have the ports dislocated) and it produces the same effect as it was when the connectors were connected, when I first posted this topic.

For power, I connected only the USB as the PM port is shot.

Isn't it an issue that one of the three major LEDs (the yellow "B") doesn't light up and never has?

Everything including the GPS has been disconnected.

Different USB cable: no change.

My PC definitely is seeing the FTDI interface. Just to make sure, I re installed the drivers. The APM is appearing in the device manager, so that means the USB cable and FTDI are fine, right?

Trust me that the APM is the ONLY device connected to the PC, and the USB is the ONLY thing connected to the APM.

I've contacted 3DR last week and they haven't replied, probably because of Memorial Day and the resulting backlog.

Regarding your male pin housing, yes, it should stay on the pcb when you pull the cable end off.

It looks like the latching part of the housing/shell has failed.

As long as you do not reverse the cable (mix pins numbers up), you should be fine.

I would try some 5 min epoxy -- VERY LITTLE -- applied to the board in a line along the male pins. Insert the cable/housing. Count to 10 min and you should be good.

The purpose of the housing is ensure correct keying/mating so that the pin numbers are not reversed.

At first I thought your male pins were not soldered to the pcb very well but they stayed put, just the shell pull away.


Thanks for the epoxy pointer Doug! So, if I were to reattach the ports, does the red wire in the bundle need a particular orientation towards or away from the center of the APM? On

Wow, you have a good eye, Monroe! But I have always set my MP baud rate at 115,200. That screenshot must have been from when I was trying every connection speed just to see if that somehow would make a difference. You've been under the correct assumption that I've been at 115,200 during our dialogue.

But I'm throwing in the towel on this. I think we've diagnosed the following: it is irreparably broken. I'll have to go through all the basic troubleshooting again with Tech Support when they get back to me, so thank you to everyone for helping me quadruple-check all the basics and a bit more. When/if the dilemma reveals itself, I'll update this string.


Visually inspect the pcb silkscreen and notice the pins are offset closer to one edge.

Also notice the I2C connector (next to the PM connector in your pic) has a similar offset. Here is a quick graphic to help...

Notice that all the connectors are offset from center.

Before applying the epoxy, dry fit a couple times to help ensure you are correctly lined up.

Good luck!


I'd like to learn more of this "JTAG" you speak of, as I now have a spare APM to experiment upon >:]

Let's take the JTAG chat offline?


My APM was in fact bricked. It doesn't even communicate with JTAG. No matter, I'll just get an APM 2.6 and never ever EVAR flash the firmware unless I need to, i.e. for an update. 3DR could as well include a warning about that, but they would also need to include a warning to never fly your drone underwater, or to never operate the drone while heavily medicated.

Now I know *nods*

Hello Dave, sorry i know its an old thread, but i 'm having the same problem as you now.

Have you tried any other methods to reprogram it ?



I'm having the same issue since today, except worse : can't even see a COM port on the PC. Also have the single green led lit, nothing else.

I just do not know how it got bricked...so frustrating.

Any ideas ?

Boy this sounds like the same as mine. I wound up reflashing firmware many times trying to update and configure, and not being sure of what I was doing,… Is this the cause of bricking the APM? If Dave could answer on this I would appreciate as he made reference to reloading firmware too many times, Or any one else I would like to know more about this as I had no idea this could happen.

I tried to reflash the firmware without success. I did a description here :


Look at this article

Sorry if this is a duplicate post of someone elses  -  kind of bleary eyed after solving this issue. Just wanted to notify people in case this is a  3D Robotics production programming issue that customers might find later on.

First a question so not to get lost in my description of the problem. Is the bootloader for Ardupilot identical to the Arduino bootloader ? or is a custom bootloader needed ?

I received a Ardupilot 2.5+ last week to upgrade my XAircraft X650 v8 frame. Because of the XAircraft ESCs, I need to modify the PWM software of the Ardupilot.  I went to install freshly compiled software and it failed to install - both with Mission Planner and with Arduino IDE. Thus being an absolute Arduino noob, the start of an all-nighter debug session.

In a nutshell, the Mega2560 Lock Bit "BLB1" was set in the factory to "LPM_SPM_DISABLE". This prevented firmware upgrades.

Fortunately, I anticipated that I would eventually corrupt the bootloader and ordered a Pololu USB AVR programmer. After installing AVR Studio 6, wrestling with it's major quirks, connecting to the incorrect ISP pins (I soldered on a 6 pin connector for the "other" on board CPU), fortunately figuring out the correct ISP is disguised with the accessory servo pins, I could read the fuses and lock bits settings.

After erasing the flash memory, I could now modify the BLB1 lock bit and reinstall the bootloader via AVR Studio 6, and then use Mission Planner to upload "custom firmware". I used the Arduino 1.

Arduino-1.0.3\hardware\arduino\bootloaders\stk500v2\stk500boot_v2_mega2560.hex bootloader. Seems to function correctly - will know shortly after putting the APM back together. But first......

Off to desoldering the 6 pins I placed thinking the empty pad was the ISP connector. The APM cover won't fit with those newly added pins.

Oh heck, I will mention one other possible production issue. The red-wire on the UBlox GPS to APM cable seems to be reversed. Doesn't affect operation, since the connectors are keyed, but IMHO a wee bit strange seeing the red wire aligned up with the ground pin.

Thanks for any information on the bootloader.

Sorry for my ramblings. Cheers

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service