ArduPilot caught itself in a state that should never happen
What ArduPilot says:
- Internal Errors 0x0x…
- PreArm: Internal errors 0x0x… l:N …
ArduPilot keeps a list of things that must never happen: a sensor chip that had to be reset, a number that is not a number, a main loop that stalled, a reboot by the watchdog. At least one has happened since power-on. The hexadecimal number holds them as bits; in the pre-arm line “l:” is the source line of the latest and the short names at the end say which. “Internal Errors 0x…” alone is sent the moment a new one is added. The list is cleared only by a reboot.
What to do, most likely first
A one-off at start-up or during setup: a sensor that answered late, a reset after a firmware or parameter change.
CheckEach name has its own explanation here: search for it.
FixWrite down the names at the end of the line, then reboot. If it does not come back over several starts, go on.
It comes back at every start, or after some minutes: a real hardware or wiring fault.
FixFollow the name: an IMU, SPI or I2C error points to the board, its power or a device on that bus; unplug external devices one at a time to find it.
A firmware fault: the same name on a healthy board, often after a certain action.
FixLoad the current stable firmware for your board. If it stays, report it on the ArduPilot forum with the full line, the firmware version and the log.
In flight the aircraft keeps flying when “Internal Errors” appears, but something inside the flight controller has gone wrong: land soon and read the log before the next flight.
Where to do it:Firmware Inspector
The code that sends it
Internal Errors 0x0x…
libraries/AP_Vehicle/AP_Vehicle.cpp AP_Vehicle::loop() · Open in ArduPilot Copter-4.7.1
PreArm: Internal errors 0x0x… l:N …
libraries/AP_Arming/AP_Arming.cpp AP_Arming::system_checks() · Open in ArduPilot Copter-4.7.1