Copter 4.6.1 Custom Build - Crash Dump

I’m running a custom firmware build for the first time - 57591cb8. I did a maiden and a few tuning flights on Friday, then we had what appears to be an ESC failure out of nowhere during Autotune… all ESC telemetry cut out, and the aircraft tumbled to the ground after flying quite well all day. Not sure what caused the ESC failure yet.

I’m in the process of rebuilding, and I see that a crash dump file was generated, though I don’t see any indication of that in the log from the crash. Here’s the crash dump and dataflash log from its last flight. Am I safe to continue using this Cube Orange+ and custom firmware build, or does the crash dump indicate a major issue I need to address?

crash_dump.bin (208.1 KB)

https://drive.google.com/file/d/1on-Clp1N4IDTPrHLS0YILlrvCeY1VoZN/view?usp=sharing

I think we will need your custom build hwdef to diagnose the crash dump - but a crash dump is always bad - it indicates a bug in the code.

Here’s the build.log and extra_hwdef.dat - is that what you need?

Also, I played back some tlogs from the last few hours on the bench… looks like the crash dump was generated in between 2 sessions of downloading dataflash logs via MP, not during a flight.

build.log (158.8 KB)

extra_hwdef.dat.txt (23.9 KB)

Ok if it was from downloading then that is more explicable as log download puts a lot of load on the CPU

2 Likes

The crash was because the ESC completely stopped working mid-flight, I think you already know that. The flight controller was OK and was still commanding motor outputs to try and recover.
Could be a connection issue, either power or signal, or the ESC is faulty.
Temperature and vibrations were not an issue.

Yes, we’re still trying to replicate the ESC failure… my main concern for this post was making sure there wasn’t some fatal bug in my custom firmware build that could lead to a crash during flight, but I’m not quite as concerned following andyp1per’s response.

Maybe you could clear something up for me, I was about to make a new post specifically about the ESC issue - it was a brand new Lumenier Siege 55A 4-in-1 (running AM32 v2.17), connected to FMU/AUX out 1-4 running bdshot. No physical damage observed under a microscope; we also inspected & probed the cables and they’re fine.

For that flight, I had the ESC’s telem wire and signal ground hooked up to SERIAL2 rx/gnd, because some docs suggest that bdshot only returns RPM, so the telem line is needed to receive full telemetry. Elsewhere, I read that EDT can send full extended telemetry over just the signal lines… I did not have EDT enabled for any of the initial flights, but I would like to run it going forward so if we have another failure, we’ll hopefully capture an error msg from the ESC.

That being said, should I retain the telem line? If not (or either way), should I tie the signal ground into the servo rail instead of TELEM2? Not sure if FMU outs are isolated from other ports in any way. I also increased SERVO_BLH_TRATE from 10 to 100 which I saw suggested when using ESC telem based notch filtering - is that indeed recommended?

One weird observation - ESC telem reports 90A current draw at takeoff each flight, which slowly climbs throughout… my shunt battery monitor (verified with a power meter on the bench) reports ~17A in a hover. I don’t expect the ESC current sensor to be super precise, but being this off seems odd to me. Maybe it needs to be scaled like any other batt monitor, but I assumed it did that internally. Here’s a plot from another flight:

All the logs seem great to me aside from the tune not being dialed in yet, so I’m really struggling to identify a possible cause of the failure. My next troubleshooting step is to hook up a scope to the signal lines and make sure they’re not too noisy, though if they were I’d expect some evidence of that in the logs. Any insight or advice is greatly appreciated! If you need any further details to assist, please let me know.

Nothing obvious in the log. Your ESCs are getting hot - up to 60+ degrees when they cut out. I would definitely check for shorts and things like that.

EDT will supply the same info that you get from the telemetry wire so no need to connect. AM32 supports EDT.

Seems unlikely it was a simultaneous desync on all four motors - more like some kind of electrical problem on the ESC.

I was definitely concerned about temps, the longer previous flight got up to ~85C. Our airframe is fully enclosed so the ESC had no airflow, and it was nearly 100°F and sunny outside. I’ve since added air ducts that should keep it much cooler.

And I appreciate the clarification on ESC telemetry. Removing the dedicated telem wire resulted in much more sane current readings from the ESC.

More flight tests tomorrow with a new ESC, fingers crossed. We found no evidence of physical damage to the old ESC, and it seems to operate normally now at least with props off… so no idea.

Thanks for your help!

I would probably only go as high as 20, but that’s just me. I dont think there’s a need to go any higher even when using ESC data for the harmonic notch filter. If using Bidirectional DSHOT the RPM data is actually coming back to the FC at the DSHOT rate anyway, and so SERVO_BLH_TRATE could actually be lower than 10. I prefer not to flood the FC with unnecessary or redundant data.

Maybe show a screenshot of your AM32 settings in the ESC. I’d be looking for current-related settings and a general sanity check.

If you have EDT TRATE can be set to 0