Discussions

Hey guys (mainly 3DR, but anyone who has input/suggestions)

I have quite  a few APMs and three APM2. I've got one that I haven't flown (an APM2) and I just put a case on one of them... I believe, in fact, that I've hadn't yet flashed this one, as it does not boot. 

I just slapped a case around all my APM2's, and was prepping them all with a custom 2.40 HIL codebase. This process was seamless for my HIL-dedicated APM1, and for two of my APM2s, but I encountered a problem with this final APM2. I'm looking for suggestions about anything I may be overlooking before contacting support and asking them if there is something I can do, or if I should RMA. 

Here is the environment:

Build Environ #1

- Mac OS X 10.7.4

- Arduino 1.0.1

- ArduPlane 2.40 (GIT, release, and custom, all behaves the same way)

Build Environ #2

- Win7 64bit on Parallels 7, latest patch, on Mac OS X 10.7.4

- APM Planner 1.0.84, 1.1.92 mav 0.9, 1.1.94 mav 1.0, 1.1.96 mav 1.0 (each attempted)

- ArduPlane 2.40, ArduPlane 2.40HIL, ArduCopter 2.6 Quad, QuadHIL attempted

Here are the symptoms:

In build environment #1, uploads of small sketches are successful (multiserialmega, etc) 

Uploads of GIT, AP2.40HIL release, custom AP2.40 all compile, but uploads fail with:

Binary sketch size: 113,778 bytes (of a 258,048 byte maximum)

avrdude: stk500v2_ReceiveMessage(): timeout

avrdude: stk500v2_ReceiveMessage(): timeout

avrdude: stk500v2_ReceiveMessage(): timeout

avrdude: stk500v2_ReceiveMessage(): timeout

avrdude: stk500v2_ReceiveMessage(): timeout

avrdude: stk500v2_getsync(): timeout communicating with programmer

avrdude: stk500v2_ReceiveMessage(): timeout

...

avrdude: stk500v2_getsync(): timeout communicating with programmer

avrdude: stk500v2_command(): failed miserably to execute command 0x13

avrdude: stk500v2_paged_write: write command failed

avrdude: stk500v2_ReceiveMessage(): timeout

...

Meanwhile, in build environment #2, the results are always the same:

APM Planner detects that the EEPROM needs to be erased, begins to upload, then fails with the standard System.IO.IOException (most likely getting the timeout shown above). 

In cold boot, the board does not boot with the normal LED behavior, on first connecting the USB cable, the APM2 (i.e., not daughterboard) blue LED flashes briefly, afterword none of the A, B, or C LEDs are lit... no alternating red, blue LEDs. The daughterboard LED behaves as expected, and the green power LED is lit. The TX/RX behave normally initially during an upload attempt, but when the upload fails, one of the TX/RX LEDs remains lit for a few seconds, and both go dark. This supports what the Arduino IDE reports in terms of what is going on.

I tend towards suspecting a DFU firmware timeout issue, but by all accounts, I have .0001, if the firmware is stock 8UT (I don't know that it is...thus I haven't tried to re-flash) 

Additional background:

Although upload errors are seen both within Windows and natively in Arduino 1.0.1 on a Mac, I did already review the windows-side serial driver, everything is just as you'd expect (and works for the three of my other units, same cable, tried different cables, every combination, only this APM2 has the issue, no matter which [working] cable is used. I also uninstalled/deleted drivers, reinstalled, disabled/enabled drivers, changed com ports (four times, to lower/higher numbers) but as I said, uploads fail in both environments. 

This APM2 hasn't flown, and I'm pretty sure I haven't used it yet, I don't think I've even attached an RC RX yet to this one yet. I could be mistaken, but other than running up MultiSerialMega, I haven't been able to push anything that runs the CLI to do things like poke about with tests. I could push a much older version of the code, but I'm not certain what value that might have, since I only plan to run "modern" code on this board....

Thoughts or suggestions welcome. Or should I contact Jordi & team for an RMA?