I recently got an APM2 and am suffering from the verify failed after succesful upload error after all attempts to load a firmware.
The board boots OK and I can completely configure it. I have never tried to get a GPS Fix because I was trying this indoors... Radio input works, I haven't tried the PWM outputs because the frame isn't built yet. And I don't want to fly like this either...
After erasing the dataflash through the CLI it shows no logs but after subsequent arming and disarming it always lists 153 or 156 logs, but only 3 filenames. If I try to dump with dump 0, mission planner crashes after the output gets stuck. This behaviour (erase, unrealistic loglist appears after next arming, crash upon dump) is reproducible.
The APM2 shows the same flashing behaviour without the card, though.
What is also strange is that if I let the terminal window open (configured on the help screen) I see plenty of MAV link errors. CRC errors and lost packets in flightdata mode. Link stats show quality 25%-95% - this is through the USB cable!
Something in the serial connection seems to be weird, but on the Windows side I am using an UART (albeit virtual) and other USB handovers into the same VM work flawlessly (webcam, flashing my radio with an FTDI for example).
I do not have a native windows PC at my fingertips - only Macs. I could only try another VM with Win7 64 bit under VMWare.
I have already spent two complete evenings on this and am wondering whether my boad is OK, considering the DataFlash behaviour.
Any hints / tips / test procedures? I have seen reports of other people having the same issues (also with native Windows machines) but haven't found a reliable solution in the answers.
Greetings from Germany, Otto
The dataflash erase issue is a known issue affecting a few % of boards. This issue is addressed has already been patched and tested and is awaiting upcoming release.
I've had intermittent verification and flashing problems, the timing is a bit finicky, especially if you're going through a VM on a Mac (I've seen similar behavior occasionally). Mission Planner flashing on a PC is 99% reliable, on a VM about 75%. I just workaround by repeating the process if necessary.
You're seeing similar issues I suspect with the MAVLink errors, however MAVLink is designed for "lossy" conditions so it doesn't matter in practice too much.
I would recommend looking at qgroundcontrol, a native Mac GCS. It is not as tightly integrated w APM as Mission Planner, but works very nicely on Mac and has some great features. I find it easier for actual missions than running a VM.
I believe your board is fine. By next release the dataflash issue will be gone...
I don't know if you like CLI, but if you do then you *must* check out Tridge's amazing python ground control station MAVPRoxy.
It is a modular, python based CLI interface, GCS, MAVLink proxy, MAVLink repeater and RC simulator.
Tridge recently added several new developments and a module system, including a GUI using wxPython and a recently added lightweight web browser moving map which can be loaded in a smartphone screen too.
It's the ultimate hacker's GCS
Thanks for answering so quickly!
It is only partly comforting to know that I have an "affected" board.. :-) However, I am going on a business trip tomorrow so maybe the new version is released by the time I get back next weekend? Is there an ETA for the new version (what is that going to be? 2.6.1?).
If not - I was counting on using this project to get back into programming. I might want to get kickstarted by necessity of rolling my own firmware. Is there a Mac specific beginners guide for Arduino programming, you can recommend?
In the meantime is there any test I can do to confirm that that is the only issue with my board / firmware combination?
Browsing through the source repository I have seen the notes about the flash issues, so I was half expecting this answer (why do I always have to be so lucky?).
I also think that the communication issue is only affecting the uplink (seen from the board) direction. I find it hard to believe that a corrupted downlink during firmware writing would result in anything bootable although during flashing there might be a different serial communication stack at work than in normal operation.
APM seems to use a non-stock library for serial communication. I find it quite questionable to see the many communication errors, when other devices work fine. 115.200 bps is not really challenging in any way even for a USB to VM handover, so I am wondering whether we can't get better with the MAV link. It may be fault-tolerant but seeing up to 75% corruption on a 4 ft. cable isn't reassuring. Looking at the communication path it is the 32U2 handling the USB <-> serial conversion, then a regular serial link to the main processor on its pins PA1 and PA2?
I can't seem to find the code for the 32U2 serial stack - maybe you can point me to it? I am curious how many buffers there are on the way between PC and 2560.
I will try the other GCSs but for starters I was very pleased with the userfriendliness of Mission Planner. CLI is fine, I am an old (since 1994) Linux adept... but as life progresses time for hobbies gets less.
Thanks for your help, Otto