Tested several time a cube Orange (stand alone, no GNSS …). Powering on and off via USB from Laptop. Done some parameter changes for a quadcopte. After sometime doing powering off/on all the changed parameter values are set back to standard quadcopter. This issue accurs two times during one day.
I think fix was to update boot loader.
@rmackay9 ?
Does the Cube ask you to re-calibrate in Mission Planner?
Yes, as @Mallikarjun_SE suggests updating the bootloader normally resolves the problem. We have instructions here on the ArduPilot wiki with the procedure including a video down at the bottom.
By the way, the most common cause of the problem is bytes from the telemetry radio flowing into the autopilot as it is booting up. In very rare cases these bytes can cause the wiping of the eeprom.
Yes, he does - starting with selecting the right frame class and so on …
Thanks a lot to all for the help 
How long does it takes to update the bootloader? In my cases immediately after clicking “Bootloader update” the message “Uploaded bootloader” occurs. Is that correct?
Hi Randy,
Would setting TELEM_DELAY,2 help?
I thought about this while typing, and figure the FC needs to be fully booted up before any params take effect anyway - so I guess not.
As you guessed, setting the telem_delay parameter won’t help. In fact, the main ArduPilot flight code isn’t even running yet when the troubles happen. It’s all in the bootloader. The fix is for the bootloader to hold one of the eeprom chip’s pins high so that it doesn’t listen to the bytes arriving in on the serial port. I can’t quite remember how the bytes from the serial port reach the eeprom chip…
2 Likes
Didn’ fix at 100% I had again a parameters reset in a cuble black after update boot loader with 4.0.4 rc3
Randy, can it help, when I turn on the plus pole of the telemetry parts with an external switch after the cube has booted?
@Axel_Weckschmied, it could help but we think the bootloader change already resolves the parameter reset issue caused by the external telemetry point receiving data during startup. It is likely that there are a number of different ways that parameter resets can happen. We’ve resolved the causes that we know about but as @Agridroni has reported we have had (a smaller number of) resets even with this fix in place (I’ve had one myself).
One of the real challenges of this parameter reset issue is that it’s quite rare. Once someone can regularly reproduce the issue we can work with them to fix it… but most often the person sees the issue one or twice and then doesn’t see it again for months.
I too have had this issue while testing a hexacoppter with a cube black.
Fortunately we would record all parameters after a change and could reload the desired settings.
I would notice some odd behaviour like poor handling so would land and look at the param and compare to find a lot of default settings Re applied. As Randy mentioned, after many flights ( and rechecking Params before taking off) it hasn’t reoccurred for a long time.
I had this issue today, in my case it was a cube orange with the ADSB carrier board, arducopter 4.0.3 after power on with a USB cable. Before that (yesterday), after a marginally succesful flight I recalibrated the IMU with the solex app on my herelink (because the drone was drifting a little too much in non gps modes) and rebooted the cube, everything was looking normal. Then I disconnected the batteries and went to sleep. So I guess the parameter reset happened this morning after I plugged the USB cable.
Do we know if this happens with USB connection only? or is it possible to have the parameters reset while powering on the cube with the power module?
Also I would like to know if I will have to calibrate IMUs or compasses again if I upload the bootloader and then go back to arducopter 4.0.3.
I would very much appreciate your help with these questions.
Did you updated the bootloader like described on this page below ?
https://ardupilot.org/copter/docs/common-bootloader-update.html
Not with that one, but I had the same issue today, another set of the same hardware, running arducopter 4.0.5. I thought the bootloader update was included in arducopter 4.0.4 and higher.
Has this issue with Cube Orange and arducopter 4.0.5 yestersay (11-16-2020). It’s worrying. What can I do to prevent this from happening in the future?
We had this problem with the last 4 copters. They have all the same setup, kore board, orange cube, with latest 4.0.5 firmware and bootloader. It never happend, when we did the first start in the day. But after some powercycles the reset does happen very often, I would say 1 in 10 cycles.
It never happend before with the black cube, the rest of the hardware is the same on the copter.
Everyone just make sure you have correctly updated the boot loader as it’s not done automatically. The boot loader is included in the firmware but it’s dormant. You must force the update after installing the new firmware.
So install the latest firmware then click update bootloader.
Again don’t assume the bootloader is updated with the firmware automatically
More info https://ardupilot.org/copter/docs/common-bootloader-update.html
Hi MadRC,
thanks for the hint - that was new to me that the bootloader doesn’t installed automativally.