Order Number: 709083
Product Name: Pixhawk 6x Fc Module (Icm-45686) Sku: H11073
Brand: HolyBro
Recently I have been experiencing the following errors with the Pixhawk 6X:
PreArm: Internal errors 0x4000 l:215 spi_fail
It is sporadically but sometimes it does not pass the prearm check. Usually the solution is to reset the FC and hope for the best.
Tried some solutions:
But it was already setup correctly
My guess is that the FC has a hardware failure on the lower level, but I am not ablet to identify it.
Basicly I tested the same setup with a different drone, I mean same configuration (same motors, frame, sensors, etc apart from the FC), however it was running with a Pixhawk 6C mini. Tested with two different FC and no error msgs appeared.
Do let me know if you already experienced that with other customers and what type of additional checks you suggest. Or if it is better to replace the FC.
The error message “Internal errors 0x4000 l:215 spi_fail” generally indicates a low-level Serial Peripheral Interface (SPI) communication problem within the flight controller. The SPI bus is used for communication with critical sensors, most commonly the IMUs (Inertial Measurement Units). The Pixhawk 6X with the ICM-45686 SKU indeed uses these IMUs. The “l:215” likely refers to a specific line in the ArduPilot firmware code where the SPI communication failure is detected.
Your observation that the same setup (motors, frame, sensors, etc.) works correctly with a Pixhawk 6C mini is a strong indicator that the issue is likely isolated to the Pixhawk 6X unit itself, potentially pointing towards a hardware fault as you suspected.
While a hardware issue is a strong possibility, here are a few additional checks you could consider, though given your tests, they may not resolve a deeper hardware problem:
SD Card: As noted in some forum discussions, issues with the SD card or its connection (which can also use an SPI interface) can sometimes lead to internal errors. One user in a similar situation resolved their “spi_fail” error by setting LOG_BACKEND_TYPE = 1 (MAVLink logging) if it was related to SD card logging issues. You could try a different high-quality SD card, ensure it’s formatted correctly, and check this parameter. - I believe you have tried this already right?
Firmware Re-flash: Although you’ve likely done this, a full re-flash of the ArduPilot firmware for the Pixhawk 6X (ensuring you’re using a stable version appropriate for the Pixhawk 6X ICM-45686, which is generally ArduCopter 4.5.0 or later) and a bootloader update, if available and you’re comfortable doing so, can sometimes clear up persistent low-level issues.
Power Supply & Wiring: Ensure the Pixhawk 6X is receiving clean and stable power. Also, double-check all wiring connections to the flight controller for any signs of damage, strain, or intermittent contact, even if they seemed fine during the swap.
Sensor Isolation (Advanced): As a more advanced step, ArduPilot allows for disabling individual IMUs via the INS_ENABLE_MASK parameter. If the issue is with a specific IMU on the Pixhawk 6X, disabling it might make the error go away (though this would reduce redundancy). This is a diagnostic step rather than a long-term solution.
Visual Inspection: Carefully inspect the Pixhawk 6X for any obvious physical damage, loose components, or issues with the pins/connectors.
Regarding whether we’ve seen this specific “l:215 spi_fail” error frequently with the Pixhawk 6X (ICM-45686), while SPI errors can occur on any flight controller, this particular line number and sporadic nature can be indicative of a hardware problem with an SPI-connected sensor or the SPI bus itself on that specific unit. Such low-level hardware issues are not uncommon across complex electronics.
Given your methodical testing, especially the successful use of a Pixhawk 6C mini with the same peripherals, if the above checks do not yield a solution, it does reinforce the likelihood of a hardware defect within the Pixhawk 6X module.
In this case, replacing the flight controller would be the most practical next step. I will send out a request to Holybro about this and let you know once they have any other suggestions or can confirm the fault. We should then be able to issue you with a replacement.
We appreciate your thoroughness in diagnosing this issue and look forward to helping you get your drone flying reliably.
Many thanks for the detailed explanation and additional suggestions.
Here are some answers:
Although LOG_BACKEND_TYPE = 1 is already set, to be honest I did not try to change the SD card before, so will do that as well.
Yes, I have already reflashed the firmware a couple of times and encountered the same messages.
Regarding the power supply, I tested it both via the USB cable and with the battery—same error. The power connections appear to be fine.
When the error occurs again, I’ll try disabling them and will update the post.
Externally, there are no visible physical damages, and the pins also seem to be fine.
The main issue is that the error message is sporadic, so there’s no consistent behavior. I will try suggestions 1) and 4) when the error happens again.
Regarding suggestion 4, I found it a bit tricky. From what I understand, INS_ENABLE_MASK prevents the start up. So I am not able to disable the IMU when the error happens, I would have to restart the FC. The main issue is that the error is not systematic.
However, I was able to run some additional tests.
Changed the SD card
LOG_DISARMED to 1 (Enabled, to record when disarmed)
Powered UAV with battery and waited until the error pop up. Had to restart the FC 3 times to get the error. I tried not to leave it turned on too long to avoid overheating the FC.
In the resulting log, I checked the following:
Both IMU0 and IMU1 showed AH (Accelerometer Health) and GH (Gyro Health) drop to zero, while IMU3 remained ok.
There was a brief loss of sensor data, which triggered an Internal Error 0x4000.
After some time, the system reported the SPI fail error.
This data loss happened 2 times. Here are some figures:
I picked up your ticket and just wanted to update you quickly. Holybro requested some details to process this for you, I have sent them those through on your behalf already and am waiting for a response. Peter from Holybro is fairly punctual so we should have a response from him soon.
I have spoken with Holybro, they have requested that the unit be returned to them. Please can you return the unit, along with all its original packaging, manuals, documentation and any miscellaneous spares or parts.
An RMA (Return Merchandise Authorization) has been created for your order.
You should receive an email shortly at the address associated with your order. This email will contain:
Your RMA number
A link to our RMA form
Instructions for completing the return process
Please check your inbox (and spam folder) for this email. If you don’t receive it within the next hour, please let us know here.
Remember to complete the RMA form and initiate your return within 30 days. If you have any questions, feel free to ask them in this thread.
Please can you let me know once you have sent the unit back to us, so we can be on the look out for it and then I can also process the rest of the return for you?
Hope this helps.
If there is anything else I can help with please do let me know.
