Just upgraded my Flamewheel 550 Hex from the APM 2.0 board  to APM 2.5 (plus the ublox GPS) (all directly from 3DR). On firmware installation, at the end of the "verify" phase, there's an error message stating that the firmware upload was successful but that verify failed "exp 77 got 37 at 35124." I repeated the upload four times with the exact same result. Does this indicate a defective board, or?? Thanks for any help!

Views: 6004

Reply to This

Replies to This Discussion

Hello all,

I deleted my own negative and ranting responses.

Negativity is not very beneficial in this group and I hold Chris in the highest regard and trust he will eventually get customer service straightened out.

I am distressed to see my friend Oliver being dealt with as he has been, but it is not my business (literally) and I know that concerns there are far different than what I can see.

As Donald Southerland said in Kellys Hero's "Watch the Negative waves Moriarty".

I was rude, ranting and rambling.

I definitely apologize for the rude and ranting parts.

I probably can't fix rambling,but hereafter I am going to try to avoid negative issues and concentrate on what positive influence I can have on this community, it needs assistance more than criticism.

Luke, thanks. Again, this is new to me, but I'm the CEO, not the tech support desk, so I'm not seeing everything that's reported. I don't know what would cause this but if it's worrying you please contact tech support and ask for a RMA. 

BTW, we just did an analysis over the past few thousand boards, and determined that approximately 3% of customers have problems in the field. Sometimes that's due to user setup errors, but sometimes there are indeed hardware issues that cropped up after QA (vibration-induced failures in use, for example) or a component that failed under load.

When a customer emails with an issue, the tech support team is supposed to ask the customer to do the bare minimum of tests to decide if it's a hardware or setup/software issue. If it's hardware, they get a RMA so the engineering team can inspect the board and diagnose what caused it to fail. We have eight people on QA alone (above and beyond the three on customer service), so this is something we take seriously. But autopilots (and especially the variety of ways they are used, given that ours is open source and designed to be tinkered with) are one of the most complex products out there, so this is not an easy task.

When you charge $10,000 for an autopilot, you can hire engineers to give individual hand-holding to customers; when you charge $179, the economics of that don't work. So we do count on this community to do much of the peer-to-peer support that we as a company can't do ourselves. That's why we've invested so much time and money in creating and supporting this community, so it can be a useful resource for users above and beyond simple RMA-based hardware support. 

  

Update: After a bit of back and forth I'm happy to report that the replacement situation regarding my defective board has been resolved satisfactorily.

I've had this happen several times when trying to load Arducopter firmware 2.9.1;  after (4 or 5) attempts, successful load and verify was achieved.   In the midst were a couple of reboots of the virtual machine.  I'm running windows 7 home premium (guest) in Virtualbox under Ubuntu 12.10 (host).   An interesting note; the code that didn't verify seemed to run fine, but I just didn't trust it...

I had the same issue...found the answer in another thread. Went into windows device manager, selected the com port of the APM (com3 for me) and set it to 115200/8/N/1 and enabled XON/OFF flow control. I'm not 100% sure this is the FTDI chip being used, but the linked doc recommends always using flow control on page 12.

http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLa...

Well, there are no doubt any number of things lurking in Windows etc. that might cause a genuine or false error report. But in my case it certainly appears to have been hardware (in particular memory) related, based on one simple thing: The bad 2.5 wouldn't verify on multiple attempts (on two computers), always reporting the same memory address error.  I returned it and bought another one and it verified on the first attempt with no changes whatsoever having been made to either the computer or to the procedure.   

I'm very concerned and upset too. My APM 2.5 is dead after less then a year and it shouldn't be. I spent the extra bucks on the legit board from 3d robo and I expected higher quality it to last longer then this. Im not definite that its dead but I definitely didn't abuse it in anyway and one day it just stopped working. I'm wondering if I got bad gear and if maybe I should have bought a cheap knockoff instead.

OK been a few months. Decided to plug my APM in today and try to figure out hows going on and it powered up normally. This leads me to believe that I got a faulty board. I don't want to try and fly this thing and have to turn off on me in flight.

Seems to be true!

Matthew Dickinson said:

For me, whenever I try updating firmware using mission planner running inside a Windows 8 or XP virtual machine using VMware fusion, It fails - I find I have to go find a 'real' PC to get it to update.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service