Copter-4.5.1 has been released as the official version for multicopters and helicopters and can be downloaded using MP, QGC or directly downloaded from firmware.ardupilot.org.
This release includes just one small but critical bug fix to the CSRF driver. That change is listed in the ReleaseNotes and copied below.
Critical bug in the CRSF R/C protocol parser that can lead to a hardfault and a vehicle crashing. A similar fix was applied to the GHST protocol, although we believe that GHST could not be affected by the bug, so this was just a precaution.
If you are flying 4.5.0 and use the CRSF RC we strongly recommend upgrading immediately to 4.5.1.
I have 3 out of 12 Pixhawk V6Xs got IOMCU error after upgraded from 4.2.3(factory version)/4.4.4 to 4.5.0/4.5.1.
The relative error messages:
IOMCU: 0 0 0
Config Error: Failed to update IO firmware
Config Error: fix problem then reboot
I’ve tried holding the safety switch while plugging the usb cable. Then it showed:
IOMCU: 0 0 0
PreArm: IOMCU is unhealthy
After that I reboot the FC normally, it showed the same error messages again:
IOMCU: 0 0 0
Config Error: Failed to update IO firmware
Config Error: fix problem then reboot
Could that be due to a bug or just hardware issues?
There are some timing challenges updating to the new iomcu firmware. I am surprised that holding down the safety switch while powering did not work for you. Its worth reflashing 4.4 and then doing the safety switch trick to see if that resolves it. Do you get a rapidly flashing light when holding the safety switch?
I flashed 4.4.4 firmware on one of the faulty FCs and did the safety switch trick. Then it worked normally. However, the same problem occurred when I flashed 4.5.1 firmware once again.
I’m not sure which light you’re referring to. If you mean the safety switch LED, it is not on for about the first 10 seconds after power on.
A long shot, but please can you try setting BRD_IO_DSHOT to 1 and then try the safety switch trick again. It should not make any difference since what you are experiencing is a failure at the bootloader level, but worth checking just in case. Setting that flag tries to install a different version of the IOMCU firmware that uses different clocking. Its the CUAV board you are trying to upgrade correct?
Could a similar (in previous FW versions) have been causing my CRSF nano problem? It appears its firmware gets corrupted, mostly as the link rate drops from 150 to 50 Hz. It does not occur without an active FC link. After it occurs the RX needs a firmware reload. I have 3 RX all with the same problem and I see some other people starting to report it.
So another thing to try is to replace the bootloader it ships with with the ardupilot bootloader which is much more reliable. If you connect in mission planner and hit “update bootloader” you can get the AP version. I have found the PX4 compatible bootloader has some very weird timing issues.
After uploading the new firmware you should get a tone from windows and then the yellow light on the base board (marked IO and in between the green and blue lights) should flash very rapidly as the IOMCU firmware is updated. If you are not getting this flashing then it probably means the IOMCU is not entering bootloader mode.
I tried that before, there was a pop out message “Upgraded bootloader”. So I guess the bootloader is already the latest?
The FCs were upgraded immediately after being unpacked. Also I always do a parameter reset after upgrading the firmware. Upgrading with the default param loaded didn’t help though. I can provide both the stock param and the default param. CUAV stock.param (18.2 KB) v4.5.1 default.param (15.1 KB)
Yes, I can get the flash either after a firmware upgrade or when holding down the safety switch while powering.
Can you possibly try again with mavproxy connected? It gives a bit more debug info than mission planner. I can also send you a debug build that might give a bit more information about what is going on.