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!
I'm not sure if this is related to your problem or not but I too am having a problem with uploading the new 2.9.1 firmware. I have a Hexa and it is already loaded up with 2.9.0 firmware but when I try to upload the newest one this is the error I get.
If anybody has any suggestions, I'm all ears. :)
Because there is some mention of a serial problem I have unplugged the Sonar and deselected it in the APM. I have also unplugged the telemetry radios but with each step the problem remains.
I tried a different computer and was able to upload the firmware to the current version. It did take 2 tries though before it completed successfully. Weird.
The new computer was running Windows 7 and hadn't had MP installed on it before so it was clean.
Sorry for thread jacking. I hope that this helps to solve your problems too!
The above result means that it wrote a 1 in the second from the high bit of the byte at address 35124 but when it verified it read it as a zero bit.
Richards suggestion is worth pursuing.
But calling Craig tomorrow seems likely.
For want of a bit a hexacopter was lost!
Hi Richard: Thanks for the suggestion, I acted on it but no joy. Also just worked with Gary McCray on this by phone (he lives nearby and we fly together a lot). Among other things tried downloading the FW for the quad rather than the hex, got the same error on verify, 77 instead of 37 but at a different location. Gary thinks it's a memory hardware problem. So I guess I'll be calling 3DR in the morning.
Matthew: First they came for XP ... now they want Win7 ... I'll give it up when they pry my cold dead hand from the mouse! Seriously, I've found that dedicating an "obsolete" (and thus really cheap) laptop to this stuff and keeping it otherwise empty is a great way to avoid all sorts of problems.
Ran through all this with Oliver with full setup erase then load hex and still wouldn't verify showing a bad bit 6 at address 35124.
Also tried full erase and loading quad just to see if it produced different result slightly different address, but still bit 6 wouldn't verify wrote a 1 and read a zero.
This is absolutely verified as a bad flash memory (on his brand new APM 2.5) and his board needs to be replaced.
I also tried this on my own APM 2 and had no trouble with verify on either hex or quad.
Gary, I PM'd you personally about this. Did you not get the message?
I understand your perspective and can appreciate your frustration. But we can't replace a board until it has been returned and inspected. It may very well be, as you say, that there is a bad component and the board must be replaced. But until the tech team can run diagnostics on it, we can't know for sure.
Just as a point of reference, we have shipped nearly 30,000 APMs and this is the first one I have ever heard of with what you describe as a bad bit, so as you can imagine the team will be very interested to inspect the board.
One way or another, Oliver will get a correctly working board ASAP.
Chris, first of all I'm a huge fan of yours and what you're doing and while I'm of course anxious and concerned that I get a working board, I'm also concerned, like Gary, that you remain successful as a major pivot point of this wonderful evolving technology.
Secondly: The talk about this maybe being some issue at my end has made me a bit nervous and wondering if somehow I've done something stupid. So what I've just done is set aside my trusty little Toshiba laptop on which I do all of my R/C stuff and instead downloaded the latest version of Mission Planner onto my monster Alienware lap-crusher (to which a job like this is a nice little snack). I hooked the 2.5 up to it and infused it with the 2.9.1 Hexa firmware as before. I would have been happy, albeit somewhat abashed, had the result been different. But no surprise, the result is exactly the same: MP reports "Upload succeeded, but verify failed: exp 77 got 37 at 35124." Which I think should erase any doubt about this being anything other than a hardware problem on the board.
But I already knew that, as did Gary and as the folks in San Diego should have on the first report. I'm not upset that the board appears to be defective, that can and will happen even if, hopefully, rarely. But I was somewhat taken aback by the process of reporting and asking for help with what to all appearances is a DOA item. I began by starting this thread yesterday, thinking that one of the developers and/or you, all of whom are so helpful here, would surely offer some advice. You did in fact chime in, but to an unrelated problem that was posted in the thread by someone else. I next emailed 3DR, and got an auto-response that did not sound like I was going to hear more anytime soon. So early this morning I phoned 3DR and was politely told that no, I couldn't talk to anyone about the matter. On applying a bit of pressure I was promised an email reply "in a few hours." I waited until late afternoon and called again, and after again having to play "squeaky wheel" was told that I would be contacted in 15 minutes. An hour later I got an email stating that this was likely a software problem (!!) and asking what kind of computer and OS I was using (about as relevant, since I had already made it clear that I had no problems with 2.0 firmware installs, as asking what kind of car I was driving when I picked up the board at the Post Office). I answered that question and then was issued an RMA etc., together with a bunch of boilerplate that leaves the impression that the exchange/replacement is going to take an indeterminate and perhaps lengthy time. Overall this did not make for a pleasant or productive day and I still don't know when to expect to be back on track here with my projects.
I realize that 3DR has to be insulated from hoards of people who can't figure out which side of an APM is up, but I suggest that when an established customer offers a clear picture of a genuine problem it is in 3DR's best interest to take a couple of minutes to at least talk about it. I should have been put on the phone with someone who would taken a quick look at the obvious and who then would perhaps have facilitated an immediate exchange (this being a DOA issue, which as you know is far different than something going wrong in a week or a month).
Now I'm seriously thinking that maybe I should return this APM for a refund and at the same time order another one, which would get me out of whatever further loops and hoops are in store, and would assure me of getting a new, not repaired, APM quickly for the cost of some postage. I shouldn't have to think like that...
Sorry for the wall of text and again, this is meant as constructive FYI (not that I'm all happy, obviously).
Just so you've heard of more than one board in 30,000, I have the exact same issue as Oliver with both my APM 2.5's (purchased 3 months apart, so prob different batch). One loading Hexa and the other loading Quad firmware 2.9 and 2.9.1. Interestingly I did not have the issue when loading 2.8.1.
On both boards there is one line that says firmware upload successful but verify failed, and gives one line of error in the description. No matter what i do, the verify fails.
Admittedly, i've been flying the Hexa successfully but i guess i should stop? Will this cause a code crash (and hence my hexa)?
So, I suspect there maybe be a lot more out there doing the same that have not reported the issue.