Board / Firmware
- Board: CubeOrangePlus (ID string from boot log:
001B003F 30325112 33383839) - Firmware tested: ArduCopter V4.6.2, V4.7.0, and V4.7.1 — same fault reproduces on all three
- Git hash (from the one clean boot log I have):
dbe79216(ChibiOS:d103983f) - ChibiOS/OS: as above
Symptom
On most boot attempts, the board hangs/crashes with corrupted serial output at exactly the “Init Gyro” line during boot (confirmed via raw serial console, not just GCS). After this, @SYS/crash_dump.bin is created and the FC reports repeatedly over MAVLink:
AP: Crash Dump incomplete, dumping what we got!
AP: PreArm: AHRS: EKF3 not started
AP: EKF3 waiting for GPS config data
This repeats indefinitely (does not resolve on its own). Heartbeats and MAVLink status text continue to be sent even while this is happening, but the vehicle never reaches a state where EKF3 starts, and full PARAM_REQUEST_LIST parameter fetches stall/never complete, even though the connection to the FC is otherwise alive.
What I’ve tried / ruled out
- Different USB cables — no change
- Full firmware reflash across 3 different ArduCopter versions (4.6.2 → 4.7.0 → 4.7.1) — identical crash signature every time
- Physically reseating the Cube module on the carrier board — no change
- Gentle mechanical flex/pressure testing on the Cube module and carrier board while booting (to rule out a marginal connector) — no change in behavior regardless of pressure applied
- Connecting via 3 independent paths — USB direct, UART to a companion Raspberry Pi 5 (running MAVProxy), and QGroundControl — the crash signature is consistent regardless of connection path
One anomaly
I have one dataflash log (attached, 00000001.BIN) from ArduCopter V4.7.1 showing a fully clean boot — no crash dump, no watchdog messages, all sensors (IMU, EKF3, GPS, barometers) initialized normally, though the vehicle was not armed/flown in this session (bench boot only). This is the outlier — every other boot attempt on this same firmware has hit the crash described above. I do not have a dataflash log from a session that ends in the crash itself, since the crash appears to happen too early in boot for a meaningful log to be written.
Question
Given the fault reproduces identically across three firmware versions and survives a full reflash + reseat + mechanical flex testing, I suspect a hardware fault (possibly one of the onboard IMUs) rather than a firmware/config issue — but I’d like help interpreting the attached crash_dump.bin to confirm which subsystem/IMU is actually faulting, if possible, before I pursue a hardware replacement.
Attachments
-
crash_dump.bin (pulled from the SD card, exact firmware version it was captured on unknown — found after the fact, not captured with matching log)
-
00000025
.BIN (the one clean V4.7.1 boot log, for comparison/context)
Happy to provide any additional info (full parameter dump, further logs, etc.) — parameter fetch currently stalls on the crashing boots, but I can provide the param file from before this issue started if useful.
This is what claude asked me to put here to identify my problem, any help is appreciated
25.bin should be a good flight test file and 26.bin is the last bin I have before everything stopped working
crash_dump.bin (5.5 KB)