I recently received a ArduPilot Mega 2.5 and have had some issues getting it to work correctly. 
Firstly I plugged it into USB and when it first ran it had the default test menus in the serial terminal. I proceeded to upload new firmware using the Mission planner 1.2.11 (ArduCopter V2.7.3 Quad to be specific). The firmware uploaded without error and I can access the CLI interface. When I try to connect through the connect button in Mission Planner, it stalls at "Already Got param STAB_D" or "ACRO_P" or similar messages
Then I get the "Connect Failed" with the details of:
Timeout on read - getParamList
Received:241 of 245 after 6 retrys
I've tried the other firmwares available and they all stall at a similar message. 
Another thing I've noticed is when I try to run test -> ins through the CLI interface, it does not show me anything except for:
"Hit Enter to exit.
InertialSensor"
Then does nothing indefinitely, so I can't read the IMU data through the CLI interface. After I did this, I soldered some pins onto UART2 to test if UART0 and UART2 were streaming serial correctly, and they both stream numbers at 115200 baud correctly without error.  
I've only soldered the jumper pins and 4 pins for UART2/+5/GND onto the entire board and have kept the device in the static bag up until I used it, so I cant imagine any hardware damage has happened since arrival a few days ago. Any ideas on how to fix this problem? 

Views: 9472

Reply to This

Replies to This Discussion

The uart 0 is  switched between the usb and the telemetry port if you see the data stream at the serial 0 but not usb

it may be the usb circuit is bad . When usb is not pluged in   the baudrate is switched to 38400 baud  and you can run the CLI through the serial port.  This is the fix for apm2's with broken USB connectors that were beefed up in 2.5

It will not  have the reset function  so MP firmware update does not work  and you will have hit reset button to get arduino to upload

 

 

The switched baudrate is 57600  not 38400

 

Hi Greg,


I have the exact the same issue with my new APM2.5 board.

I can upload arducopter V2.7.3 but when trying to connect, it always ends with a connection error.

Here is the resulting message:

Did you have any luck with yours yet?

You can connect mission planner ( mavlink) on the serial  0 as well  . Change the speed in MP next to the connect button to 57600.    You could also edit the serial 0 speed in arduino  to someting slower and use the USB ,  it could have someting to do with the pc your running MP on .

 

Thanks for the info John.


I've tried connecting with USB on three different computers and I had the same result.

  - Macbook Pro - running Vista under parallel

  - Macbook Pro - running XP SP3 under parallel

  - Acer notebook - running XP SP3

I will try the serial 0...

Thanks again.

I had a similar issue that has taken me 2 days to solve. I think I have found the bug that causes this. I will need to give a brief history because the answer is not something I can give as a step by step fix. You will need to frig around until you find the exact sequence that works for you. I will need to write what looks unrelated at first.

First is that I have 2 APM2's

One is my quad but is a few firmware releases back because I had no time this summer to work on it..

Second board is for my airplane but has gone unused since I received it back at the beginning of 2012. So the firmware is very old and factory default.

It was this second airplane one I decided to build as a test stand for testing peripheral hardware/software with. It would not communicate with the CLI or mission planner. In the CLI it said the port  comm 3 was open, but would not respond to any commands.

After messing around for hours, I opened windows device manager I checked that the board was recognized and went into admin properties and saw I could interrogate the board hardware ID# etc. From there I decided to change the port from comm 3 to unused comm 7 and also 10. 

Back in MP I opened the command box to see the details when I hit connect comm 7. Suddenly it began giving me at least the board ID comm etc but error and timeout filled connections At least now the board identified itself. Now I went to the CLI and still keeping the mission planner command window open I could see it identify itself and in the CLI now I got the test list. The test list was not working 100% but would send and receive the test results along with some random garbage.

Progress finally. Bur try as I might that was as good as it got. So at this point I decided to try my quad APM2. I got very similar issues with it but not an exact match on behaviour. This lead me to believe there were two important variables. Different versions of the mission planner and different versions of APM firmware. So my conclusion was to play around until I could get it to communicate on a comm port long enough to upgrade the firmware.

Now this is why I can't give anyone a step by step fix. I don't know the exact combination. The important part is to keep the command window open so that you can see what responds and what doesn't line by line. All I can say is through the CLI, I was able to get the firmware on the APM upgraded and put it back on comm 3.  Now everything works like it should and the clue I got was using windows device manage to interrogate the board to ensure it worked at that level first first. Next  was in keeping open the command window in the MP and comparing the lines responding back from my 2 APM's that had very different revision levels. making sure the usb/comm hardware got reset and the values you test with stuck.

I got similar results using uart0.

Occasionally the connection work and I manage to get most of the parameters but it always end with a comm error message...

I also have an APM 1 which work just fine so I doubt that the problem is related to my computers...

Any other idea?

This APM 2.5 is about to do his maiden flight ...by the window.

So on the serial 0  at 57600  baud you had the same problem ?     You could  edit the Speed down to like 300 and literally watch each parm sent.

I take it that you are loading with arduino with no problem ?  if that works  at 115200  sending over 128k and reading it back to verify it  one would have to think the apm is ok.

Have you tried older versions of Mission planner  or the latest  I do not know if their is something different for the 2.5  board,   I imagine you are pretty fustrated  by now have you asked about a RMA for the board

 

I got an RMA for the board. Because I could not read the IMU using CLI, it seems there might be something wrong with the IMU. So after sending it back I am still waiting on a reply of what happened to it.

I've since my last response. I've discovered that for some reason the low numbered comm ports are erratic. Sometimes they work and other times they don't. Even though they show to be available something just isn't right. Since I moved to using port 8-10-16 etc., I haven't had this problem.

First is this is on my laptop and later I'll make my point on saying this.. Now this isn't a total fix but it certainly for me removes one point of failure. The second regarding the port baud rate is still causing problems. I have only had 100% success by using 57600 baud.

Because I have two sets of everything. I can confirm that if you are beginning with old firmware and trying to come up to the latest, that you must begin with 9600 baud. No matter how many times I reset and begin the process again, it is not stable with anything but 9600. Once I update then 57600 is solid. For me at least.

I suspect that it is possible that some issues are dependant on the computer you have. For my laptop I used Win7. My early suspicion is that hardware timing of the comp you use does have an effect on stability. I think it is more important than the OS. My other comp is completely different from hardware to the OS and I get completely different errors. But doing what I did with the laptop and I get the same success. This is why with the baud rate change and port number used, changes results and degree of success or failure. That's why I'm beginning to think there is a hardware timing factor involved, along with possibly (or not) other as of yet, identified variables. At least now, for me at least, I can consistently get it to load and work (Just not at 115200, yet).

Hi Serge,

Did you have any success on this issue? I´m having exactly the same problem and tried everything, but no success at all. Please tell me if you got rid of that error message, ok? Thanks a lot!

Hi Guilherme,


With help from 3D Robotics, I found a problem with the accelerometers.

The "INS" CLI test was failing (hanging).

The replacement board they've sent me worked right away.

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service