Copter-4.0.7 stable released!

Copter-4.0.7 stable has been released and is available for download from the ground stations or from the build server. The changes vs 4.0.6 are in the ReleaseNotes and copied below.

  1. added automatic backup/restore of parameters in case of FRAM corruption for F7/H7 boards with 32k FRAM parameter storage
  2. fixed a bug in EKF2/EKF3 that could cause memory corruption if external naviagtion sources (such as vision based position and velocity data) is supplied before the EKF has initialised
  3. fixed a problem with low accuracy data from UAVCAN GPS modules when GPS blending is enabled
  4. fixed an arming check failure with u-blox M9 based GPS modules
  5. fixed a race condition in SmartRTL which could cause a LAND mode to be triggered
  6. fixed build on Durandal board
  7. multiple fixes for mRo boards: ControlZeroClassic, ControlZeroF7, ControlZeroH7, ControlZeroOEMH7, PixracerPro

The main reason for this release is the parameter backup/restore. This has been an ongoing issue for quite some time. The symptom is an unexpected full parameter reset on boards using FRAM (also known as RAMTRON) for storage, particularly those using F7 or H7 based MCUs. The issue has most commonly been seen on the Hex CubeOrange board, but has been seen on boards from other vendors as well.

The issue has been frustratingly difficult to reproduce. We did narrow down one cause last year which was a floating CS pin in the bootloader triggering corruption before ArduPilot starts. An updated bootloader reduced the occurrance of the issue a lot and we thought it was solved. Since then the problem has still happened a few times on boards that have had a bootloader update.

This release avoids the issue by keeping a complete second copy of the parameters in the 2nd half of 32k FRAM devices. On boot we check the integrity of the primary parameter storage area via a simple signature check and if it has been corrupted then we restore from the backup area. We also raise an internal error named" params_restored". You will then need to reboot to clear the error, but your parameters will have been automatically recovered, avoiding the need to reload parameters and re-calibrate.

If you get this internal error then it would be appreciated if you could send us the contents of your APM/STRG_BAK directory on the microSD card so we can analyse the corruption that happened and ensure that the fix covers all real cases.

As always, thanks very much to our beta testers for putting their vehicles at risk to help us ensure this is a safe release.


Thanks for this update! Fix 4 looks like it will help me avoid issues when I upgrade my Solo to the experimental mRo M9 GPS.

A big thanks to all involved developers!
I just completed a couple of test flights with 4.0.7 on my Tarot 650. Lidarlite, Px4flow, IR-Lock, ADSB, a TX2 connected via APsync and MavROS - all systems work well. Copter flies rock stable and smooth.


After the Update i don’t get telemetry data from the ESCs anymore, if i flash it back to 4.0.5 it works again
Anyone else with the same issue?

@pkocmoud can you help @Daniel_Met out? He is having problems with

@Daniel_Met - Which board are you having trouble with?

Hi Philip,
im using the mro F7 board.
The other issue i have with the board with 4.0.5 i have described here

Hello after the update to stable 4.0.7 the motor test is not working properly. when I test the motors one by one motor A cannot be tested. Testing all motors works ok. In particular testing motor A rotates motor C, testing motor B is ok, testing motor C ok, testing motor D is ok. testing the motors in sequence gives the same problem. Have you noticed a similar behavior or have an indication for the problem.

It will run in sequence (A,B,C,D…) if you press the “Test All In Sequence” button. Starting from The Front Right Motor (A). It won’t run in Motor Output number order.

1 Like

I build a new Copter based on Matek H743-SLIM.
In Loiter mode after a while (about 10-20 min) the copter tilts forward and flies away.
After deactivating IMU0/ICM20602 all is fine.
I think this is the same issue with ICM20602 AccelY offset which was fixed with 4.1.0 some days ago … and is btw working fine with my 4.1.0-dev rover toys.
FC/AHRS_ORIENTATION is mounted 90 deg CW, so it tilts to the front and not to the left.

Will there be a backport of the PR to 4.0.7? And perhaps also for the plane release?

1 Like

What PR was that, do you have a number for me to look at?

1 Like
1 Like

@amilcarlucas @tridge IMU2 in Cube Orange is the ICM20602. I am afraid to fly my drones now. Unless you are planning for a 4.0.8 release, this must be backported. Any suggestion?

1 Like

Can you create a PR against the Copter-4.0 branch?

I backported the bugfix on top of 4.0.7. Can anyone test it? I do not have the hardware to do it


@amilcarlucas I can give it a try. Where can I get the APJ file for MatekH743?
I’m not able to compile by myself.

@amilcarlucas thank you very much! I will give a try and report back as soon as possible.

So… is there an ICM-20602 accelerometer bug present in 4.0.7 ?

I’m trying to commit an Orange Cube to a build and I’d hate to collect its remains from the field in a bag.

1 Like

Did anyone test my bugfix? If no one is willing to test… It can not be merged!