Using the Wiki instructions for flashing the APM2 I am unable to connect to USB with the FLIP software.
After connecting to USB port and installing the jumper on JP2 port I use a wire to reset the Atmega. At that point I hear the USB disconnect/connect sound and the board goes to DFU mode. However I get a "new USB device found" message. In the device manager I see "Arduino Mega 2560 DFU" under "Other Devices". It's like there is no driver for this and it will not assign a USB port to it.
When I run the FLIP software and try to connect via USB I get a "Could not open USB device" message.
I have tried this on two different computers with the same results.
Anyone tell me what I am doing wrong?
So the computer pretty much told you what's wrong, you need the driver associated with the hardware detection (AKA Plug-n-Pray).
Like every Arduino IDE, there is a folder with the install containing the required driver file (AKA .inf file)
"C:\Program Files (x86)\Atmel\Flip 3.4.5\usb\atmel_usb_dfu.inf"
Your folder may vary slightly.
However I get a "new USB device found" message. In the device manager I see "Arduino Mega 2560 DFU" under "Other Devices".
So, in device manager, right click on that device, update the driver by browsing to the Arduino FLIP install folder (usually in the programs folder, but in win7, there are often 2 of them).
That got me past that hurtle.
Now it seem I am not downloading a valid copy of the hex file from the repository. I am tryimg to fumble my way through with GIT but not having much luck. Is there a tutorial on how to retreive files from the repository?
It might be easier to just grab the file you want from the web interface here:
The newest is 1.68, so if you try this file:
See the link on the right that says "Raw file"? Right-click and save-as, or save-link on your browser to save that hex. Then flash it!
Thanks Andreas. That worked and I was successful in flashing the software.
The Rx LED now flashes quickly when receiving from the RC radio. It flashes slowly when radio signal is lost. The LEDs never came on in the earlier version.
This also makes the failsafe work with my standard 9X radio.
However my XBeePro telementry stopped working. Is this related?
Telemetry might be affected by the automux function if USB is plugged in. In other words, the port the directions tell you to use can either be UART 0 or 2 based on the solder jumpers on the bottom of the APM, but also, that is shared with the USB port. By default they have the traces connected right but again, that is automux. There is a hard wired UART near the 6 pin ICSP connector that is hard wired to UART0 not through the automux. Simply move to those pins and it works for sure-no matter what the PPM is doing.
In other words, the new firmware shouldn't mess with it. In the unlikely event it has a bug, then fine, we ignore it and connect to the hardwired port anyway. I personally have had trouble and so have others with the automux port. In other words, it seems to have a problem with impedance load and some Xbee adapaters don't work (also could be pullup resistors) no matter what on the port shown in telemetry directions. Plugging into the hardwired port solved it. Thus my recommendation was for them to add that info for telemetry, but I got tons of kickback from the moderators, when really that info should be on that wiki page. Here's a thread with pictures. http://diydrones.com/forum/topics/no-signal-on-apm2-0-uart0-and-xbe...
WTH is the "automux"? (H = heck, not the H-word)
IMPORTANT: On APM 2, you cannot use the Xbee while your APM board is connected to the USB port. That's because the Xbee and USB share the same serial port, with some clever multiplexing to detect if the USB cable is plugged in and switching output to the USB if so. Although that has the huge win of freeing up a serial port for some other use (want to connect an Android phone, anyone?), it does mean that you need to disconnect the board from the USB cable and power it some other way when testing wireless telemetry on your bench
AKA MUX as labeled on the bottom of the board.
There are mutliple UART pinouts as screenprinted on the board, some have sharing features (or limitations depending on how you look at that), some are hardwired to the mega 2560 directly. Covered in the linked thread in the other post.
Here is the hardwired-non-muxed port.
I need to add the obvious-neither port can be used when USB is plugged in. On the muxed port (AKA the one they tell you to use) it outputs nothing when USB is plugged in. The port linked above that is hardwired will interfere with the USB when plugged in. So if you use the hardwired port-unplug the 3DR or Xbee radio when you plug in USB-or else you get no USB connection. Personally, I see little difference from a limitation point of view. Neither one works both USB and radio at the same time. It's just how the blocking works where the one they say to use, USB is priority, and the hardwired one is serial priority.
There's no actual multiplexer though right? They've just wired the ports together, essentially forcing you to use one or the other at a time.
Found that the XBee was bricked somehow. I unbricked it and now everything is working together.
There seems to be a lot of information that should be on the Wiki but is not.
The fact that reflashing the PPM encoder will make the failsafe work with a standard 9X radio is huge.
That information on the hardwired port is good to have.
Thanks for your help.
That's what I was getting at in the other thread. There IS something active in the circuit because my Xbee will not work, but the 3DR radio will. Also tested with a FTDI cable and that also didn't work from the "mux" port. I believe it's either pullup resistors or some other signal issue, but let's just say it's less robust for sure. Again, the same device (Xbee 900mhz pro) works from direct UART0 but craps out on the mux UART 0/2 and to be clear, obviously not with USB plugged in since Chris must have asked that several times. The board is not defective, I have 2 of them that work identically, it's a design that either impeadance is off or pullup resistors are not strong enough with certain loads. The UART0 direct port obviously works as expected. In other words, there is a mux or buffer in the path of the UART0/2 and for me and a lot of others, it may not work as well as the direct UART0.
If you ask the administration they may let you edit the "wiki". That's another bit of info that might be good to include there.
Does anyone know how to Do this flash using a isp programmer. My apm is not seen in windows at all and i cannot get it into DFU mode. any ideas?