Hi,
I really hope this is the place to report/ask about this.
I’m running ArduPlane 4.6.2 on a CubePilot Orange+ mini carrier board. Attached is crash_dump.bin file. I can provide other details if I know what is needed.
crash_dump.bin (15.6 KB)
Looking forward to an expert giving me some direction.
Cheers,
Tim
Is there any way for me to analyze a crashdump myself?
I saw another post where “Log Analysis” was part of the subject line, is that what it takes?
Incidentally, I did try to just delete the crashdump.bin file with MavFTP but then I get an exception thrown in the dotnet code.
Failed to OpenFile - kCmdRemoveFile kErrFailErrno 0
at MissionPlanner.ArduPilot.Mavlink.MAVFtp.kCmdRemoveFile(String file, CancellationTokenSource cancel) in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\ExtLibs\ArduPilot\Mavlink\MAVFtp.cs:line 1770
at MissionPlanner.Controls.MavFTPUI.<>c__DisplayClass14_0.<DeleteToolStripMenuItem_Click>b__1(IProgressReporterDialogue iprd) in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\Controls\MavFTPUI.cs:line 451
at MissionPlanner.Controls.ProgressReporterDialogue.RunBackgroundOperation(Object o) in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\ExtLibs\Controls\ProgressReporterDialogue.cs:line 111
Just for grins I looked at the crashdump.bin file in the binary editor of visual studio. I saw multiple occurrences of gyros not healthy. The plane (an F15 I 3D printed 🦅 RC F-15 C/D/E twin 70mm / 80mm EDF Retracts・ STL File for 3D printing・Cults) is on a stand and as it’s booting up and the servos are energized it does wiggle just a little bit. Could this cause that “gyros not healthy” or is it more like the CubeOrange+ has issues?
“gyros not healthy” is common during startup until the EKF is stabilized, or if you haven’t done the initial calibrations. If the plane is any stabilized mode (FBWA, etc) the servos will twitch or move as everything is settling down.
Is there a specific issue you’re up against?
Hi Allister,
The “servos not healthy” was just something I noticed looking at the crashdump.bin in a binary editor. I had not noticed that at all in Mission Planner.
What is still plaguing me in Mission Planner is the “Crashdump data detected”. I can’t figure out if there is still a real problem and a crashdump.bin is getting regenerated (each time I flash the Orange+) or, if that’s no longer a problem, how to remove the crashdump.bin. I have flashed the Orange+ with plane 4.6.2 a number of times because the docs said that’s the recommended way to get rid of crashdump.bin. The file persists though and I can’t tell if it’s new following a reboot or if it’s old and didn’t get removed properly. I’ve only seen the files in sys via MAVFtp and it doesn’t show a timestamp. If I run terminal and cd to sys and then run ls -l will it show timestamps?
I’m sorry for all of the noob questions, I’ve only been about it a month or so now. I have all of the control surfaces (including flaps, landing gear and airbrake) working now and I can run the ESCs if I force it to arm. I just can’t get it get over the crashdump.bin problem.
Thank you for any direction you can provide.
Tim
Crash dump files are only created if the CPU crashes, and that’s not common.
Has this flight controller flown, or has it been armed? There might be some clues as to what’s going on in the log file from right before or during the crash dump. Can you share that log file?
You shouldn’t have to force arm. Is that because of the crash-dump error or is there anything else?
You might need to re-flash a different version of the firmware (copter or rover) and then back to plane. I would suggest saving a back up of your parameters. But don’t load them back because I’m wondering if there’s something there that’s caused the problem. A filter setting or logging, or something that has accidentally been set in such a way that it’s overloading the CPU.
Hi Allister,
It has never flown but it has been armed in the past (without force arming).
Yes, the reason for for force arming is because the crashdump.bin file persists.
I’m happy to share anything log file, .bin, etc. but I’d need a little guidance. As I recall there are a handful of log files (maybe I’m thinking of .bin files), which one(s) do you need. Do you want the log file(s) before or after I start re-flashing with copter or rover?
How do I save a backup of my parameters? Never mind, that must be in the docs somewhere.
If I don’t restore the parameters I’m redoing the setup, right? A little bit of a bummer but it should go a lot faster this time since I’ve been through it once. Are you interested in the backup parameters file?
I also have backup Orange+ cubes on hand. I could try restoring the backed up parameters to a new cube if you’d be interested in that. Might rule out any sort of hardware failure.
Thank you so much for helping me work through this.
Tim
Ideally the bin files from the arming before and when the crash dump file was created. From the log file will have the parameters in it so anyone looking at the will be able to see them.
If you don’t restore the parameters, yes you’ll be re-doing the setup. I am thinking there’s an error in the parameters so that might not be a bad thing. The other cause of the crash dump could be a hardware failure so this would be a way to verify that.
Here’s a handful of files. I turned on my transmitter, started MP and then turned on the plane. I’ve included the parameter list too.
log_bin_files.zip (120.5 KB)
Updating to rover firmware and the back to plane got rid of the crashdump warning. Now I’ll go about redoing my setup.
Hi Allister,
I rebuilt it and now I don’t have the PreArm: crashdump.bin warning and everything is working. I do get a Check mag field warning but I understand what that is (after googling). I’ll try to move my GPS further away from my radios and recalibrate the compass.
If you should desire to look at the info I sent, for posterity’s sake, I would be interested in what you find. However, I would also totally understand if you don’t care now that I’m rolling again.
Regardless, thank you for your help in getting me going again.
Cheers,
Tim
Hi Tim,
The tlogs don’t help. It would need to be the .bin file off the SD card in the controller. But if you’ve re-flashed everything that may have been wiped clean (but I’m not 100% on that one). I looked at the parameter files and I didn’t see anything that jumped out at me as overloaded. Sorry, no smoking gun.
Cheers.
Hi Allister,
In case I need this in the future, what is the name of the file that matters? Is the name consistent or does it change?
I didn’t know there was an SD card in these. I do know that I didn’t install one myself. Where do I find that on a CubeOrange?
Thanks for all of your help Allister.
Tim
On the cube the SD card is right below the usb port. It’s tucked in there so it’s hard to see.
You can use mission planner to download the logs, or if you pull the SD card you can find the logs on the card. There’s a file structure on the card but you’ll figure it out pretty quick.
The log files will be named with the date and time of the log with the extention .bin.
Thank you. That is a very helpful link.