Today we discovered a “byte alignment” issue with ArduPilot bootloader that is included with Copter-4.0.0-rc1 to -rc4 that can affect autopilots that use the STM H7 CPU.
Please do not attempt to upload the bootloader with Copter-4.0.0-rc1 to -rc4 on a Hex CubeOrange or Holybro Durandal or you risk “bricking” your board. A fix has been released with Copter-4.0.0-rc5.
This issue does not affect the older Pixhawk boards (CubeBlack, mRo Pixhawk etc) nor any other board that ran Copter-3.6.
This issue will not cause your vehicle to crash. The worst case is it will cause H7 boards to fail to startup and fail to accept new firmwares (i.e they become bricked). The Durandal includes “DFU” pins which can get them out of this state but this is not possible with the Hex CubeOrange.
To provide some background, a “bootloader” is a small piece of software on the autopilot that runs for a few seconds immediately after the autopilot is powered up. It’s purpose in life is to make updating software to the autopilot easier. The reason that the ground station asks you to plug/unplug the board before a software update is so it can communicate with the bootloader.
Most flight controllers come with a bootloader already installed but ArduPilot also comes with bootloader. This new bootloader is only loaded if you connect to the flight controller with a ground station (like Mission Planner) and then specifically tell it to upgrade the bootloader. This button can be found on MP’s Install Firmware screen or the Ctrl-F screen but please don’t push it!
No, I’m afraid it does not. It is apparently possible to disassemble the cube to get at the DFU pins or to use an alternative carrier board that has a “debug port” on it but I don’t think these are easy things to do.
@rmackay9 just to double check, so it is safe to write Matek-F765 with Copter-4.0 boot loader?
Just slightly confused because of “CUAV V5 Nano” mention. It is uses F7 CPU as I found.
I think I’ve either been lucky with my Orange Cube, or the issue is elsewhere, because I could replicate today with two different classic Pixhawk 1s the experience with bootloader update.
1 - install -rc4
2 - reboot and do the bootloader update
3 - reboot and get a “bricked” pixhawk… no matter how many reboots, FMU B/E led is flashing furiously, main RGB led won’t start blinking, MP connect times out.
4 - go to firmware page, reload -rc4, get the message it’s already loaded and nothing has been written, then at the same very moment FMU B/E led goes off, RGB led starts blinking the boot sequence and the FC starts.
5 - all subsequent reboots are OK
I didn’t check Device Manager to see how the Orange had been listed while in the “bricked” state, tho’
I think this “Force Bootloader” link/button is actually different and won’t cause the bootloader to be upgraded. This button is to save the user from having to disconnect/reconnect the USB cable.
@sergbokh,
Thanks for that. Yes, you’re right, the CUAV V5 Nano is not affected so I’ve updated the notes above. It’s actually only the Holybro Durandal and Hex CubeOrange that are affected.
@sergbokh, the matek boards should all be fine. It’s only the Holybro durandal and hex cubeOrange that are affected. I’ve updated the warning to remove mention of the cuavV5Nano.
[@rmackay9] I have a Durandal and I want to enter DFU mode. You mention above that this can be done using DFU pins. Is it possible you could detail this ? I can find no reference in the FC documentation or online and Holybro have not responded to my email on this subject.
The Durandal is working ok and flying a large multirotor with no issues for 12 months. I can connect to Mission Planner running in windows via USB to change Ardupilot parameters, download logs etc.
However I’m not able to update to the latest firmware using MP or QGC as the PC is unable to find the com port when attempting this.
So I thought that if I can enter DFU then I could possibly use STM32CubeProgrammer to flash 2MByte_allzero.bin and/or the latest ardupilot firmware.
