Cube orange, config error reboot

Cube Autopilot
21

Hello team,
I’m facing "config error: failed to update IO firmware ", after debugging my cube. I changed the param BRD_IO to 2, sometimes the issue gets solved. After few reboots, another error CHECK_IMUx_PRESENT or CHECK_BAROx_PRESENT shows up.
Here are my queries regarding the error:

  • So, is it necessary to update the IOMCU firmware with every time updating my firmware in cube(custom or Arducopter)?
  • I can continue with (BRD_IO = 2) to already existing firmware of IOMCU ?
  • For every update in firmware from your side, the IOMCU firmware also updates ?

Thanks in advance!

22

I have tried with stable, Beta and dev versions but still the issue persists.

23

I have this issue. What did you do to resolve it?

24

Hi Mark,
exactly what symptoms do you have and what have you tried?

example: Updated to latest stable firmware, done the bootloader update ?

25

I installed a new camera/gimbal on the bench. This required several Cube/system restarts throughout the process.

As soon as I wrapped up, I performed a fresh boot and noticed I had no Herelink connectivity.

I got into Mission Planner and noticed “T Failure” in the HUD with a verbal “Config error fix problem and reboot” message.

I restarted and reconnected the Cube a few times before eventually flashing to Rover and back to Copter (re-loaded params).

I’m able to interact with the Cube but the issue still isn’t resolved. I do not hear normal bootup/beep tones and am beginning to wonder if it’s an issue with the Cube itself…or maybe the Kore carrier board.

Any ideas?

26

Try booting without the SDCard, and also do the bootloader update via MissionPlanner (or hold down the safety switch while booting).

Can you post a screenshot of the messages tab please.

27

Very interesting that the failures seem to move between:

  • IMU presence checks,

  • BARO checks,

  • IO firmware update behavior,

  • and repeated initialization/config validation states.

Looking through the screenshots, it does not immediately feel like multiple sensors physically failing simultaneously. The behavior looks more consistent with initialization sequencing, unstable startup state, IO firmware synchronization problems, or temporary communication/power instability during boot.

One thing that caught my attention was the mention of repeated restarts during camera/gimbal integration before the issue started appearing.

We have noticed during bench integration activities that repeated partial boot cycles, peripheral hot-plugging, unstable startup power conditions, or interrupted initialization sequences can sometimes leave the system in inconsistent states until a clean bootloader/firmware reinitialization is performed.

A few things that may be worth testing systematically:

• Boot completely disconnected from non-essential peripherals
• Remove SD card during recovery attempts
• Verify stable power during startup and IO initialization
• Perform full bootloader update before reflashing flight firmware
• Allow full initialization completion before reconnecting peripherals
• Check whether the behavior changes with different carrier boards or power modules

The fact that some users temporarily recover after reflashing or changing BRD_IO settings makes the initialization/firmware synchronization path especially interesting.

Would be very interesting to know whether the issue reproduces consistently after a completely clean firmware + bootloader recovery sequence with minimal hardware connected.

Dr. Fares Al Dhaheri

Al-Etihad Industrials, UAE