Cube Orange+: "CHECK BARO1 PRESENT" & "Failed to update IO firmware" Errors

Hi Kaan,

Based on the symptoms, I would treat this as a possible hardware-level fault rather than a normal parameter or firmware issue.

The Cube family is expected to have onboard barometers as part of its redundant sensor architecture. CubePilot’s own specifications list the Cube architecture with redundant IMUs and onboard barometers, so a persistent CHECK BARO1 PRESENT means ArduPilot is not seeing one of the expected internal sensors during board validation.

CubePilot specifications:
https://docs.cubepilot.org/user-guides/autopilot/the-cube/introduction/specifications

There are also previous ArduPilot / Cube cases showing similar board-validation messages, including CHECK_BARO1_PRESENT:

ArduPilot GitHub issue:
https://github.com/ArduPilot/ardupilot/issues/22779

CubePilot forum discussion:
https://discuss.cubepilot.org/t/bunch-of-orange-cubes-start-to-fail/11890

I would be careful with BRD_OPTIONS = 128. It can bypass board validation, but it does not necessarily solve the underlying sensor-detection problem. If the error then changes to “Failed to update IO firmware”, that may be a separate issue related to the IOMCU / IO firmware path, not proof that the barometer problem is fixed.

For the IO firmware issue, ArduPilot documents a force-update procedure for the IOMCU by holding the safety switch while powering on the autopilot:

ArduPilot IOMCU force-flash procedure:
https://ardupilot.org/dev/docs/pixhawk-force-px4io-flash.html

There is also a CubePilot forum discussion about the Failed to update IO firmware message:

CubePilot forum discussion:
https://discuss.cubepilot.org/t/orange-cube-failed-to-update-io-firmware-fix-it-and-than-reboot/9839

My suggested next checks would be:

  1. Test the Cube on a known-good CubePilot carrier board.

  2. Flash the latest stable ArduPilot firmware using Mission Planner, then reset parameters to default.

  3. Try the documented IOMCU force-update procedure using the safety switch.

  4. Capture the boot messages, BARO_DEVID values, board ID, bootloader version, and full Mission Planner messages.

  5. Avoid flying this controller until both the barometer validation and IO firmware issues are resolved.

Since you already replaced the barometers and the problem did not change, I would not continue replacing parts. The fault could be on the sensor bus, power rail, internal PCB path, FMU-side interface, or IOMCU / bootloader side.

At this point, I would escalate it to CubePilot or an authorized reseller with the serial number, photos, and boot logs. I would treat this controller as not airworthy until the barometer validation and IO firmware update issue are fully resolved.

Dr. Fares Al Dhaheri

Al-Etihad Industrials, UAE