I’ve looked several places for solutions, e.g.
Parameters reset to default values,
Clean up and extend RAMTRON driver,
Hold CS pins high in bootloader - fixes param reset issue,
Cube orange randomly reset parameter to default
Updating the Bootloader, Pixhawk 2.1 randomly reset parameters,
Hard landing causes all parameters to be reset to defaults?!?
but haven’t been able to resolve the problems reported below. Also, I haven’t found anyone recently having issues with the STAT_RESET parameter… Okay, here goes:
My most recent parameter file for this Cube was saved on 6/8/20 X61-53-6-8-20.zip (4.6 KB) at which time the Cube was performing normally; here’s a partial list of its parameters at that time: STAT_BOOTCNT 564, STAT_FLTTIME 110628, STAT_RESET -504921600, STAT_RUNTIME 894120.
This Cube lost all parameter and stat values last week during bench testing with dual HERE2 GPS and several other peripherals connected. At that time firmware was 3.6.12 so I applied the bootloader update fix; freemem was ~45K, and after the bootloader update freemem was reduced to ~17K. This didn’t resolve the issue and all parameters continued to be lost intermittently after several power cycles or reboots. I disconnected all peripherals and tried powering via BEC and via USB only with no change in behavior.
After a while I noticed that the STAT parameters listed above had all reset to 0, including STAT_RESET which if I understand correctly is a read-only (even though its description indicates that setting to 0 will reset statistics). Since first noticed, STAT_RESET has remained at 0 every time parameters are checked, as have the other STAT parameters except for STAT_BOOTCNT which remains in the single digits.
I flashed firmware to 4.0.4 and then 4.0.3, each time comparing and writing the saved 6/8/20 parameters, but this did not resolve the intermittent parameter loss issue either. I’ve now performed several firmware version flashes (of varying success) to the Cube including to and from Rover 4.0.0 and Copter 3.6.9, 3.6.10, 3.6.11, 3.6.12, 4.0.3 and 4.0.4. The flashes always seem to stick, but I can’t always connect to the Cube with Mission Planner after the flash, as the correct COM port isn’t always listed. I updated Mission Planner software and have attempted connection with two separate Windows machines.
Along the way, the following two symptoms began presenting with increasing frequency until now they are everpresent:
- Repeated status message: Check BRD_TYPE: Failed to init CubeBlack – sensor.
- Critical Service Bulletin warning
The log downloader is throwing the following error:
Error:System.TimeoutException: Timeout on read - GetLogEntry at MissionPlanner.MAVLinkInterface.<GetLogEntry>d__252.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MissionPlanner.Utilities.Extensions.<>c__DisplayClass1_01.<<AwaitSync>b__0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MissionPlanner.Utilities.Extensions.AwaitSync[T](Task1 infunc) at MissionPlanner.MAVLinkInterface.GetLogList() at MissionPlanner.Log.LogDownloadMavLink.<LoadLogList>b__12_0
but I managed to download a log file 140 12-31-1969 6-00-00 PM.bin (1.9 MB)
which may or may not be useful. Log download failure may be because of the “failed to init” error…
Another of our Cubes, purchased from ProfiCNC in 2020 and fresh out of the box within 10-20 boots began losing parameters as well, only dual HERE2 GPS modules connected, no other peripherals. This occurred back in February or March, and after learning about the bootloader issue I shelved the unit for later investigation. I hadn’t dug into Cube #2 until Cube #1 lost its parameters, and a hunch led me to check Cube #2’s STAT_RESET parameter; sure enough, it is also set to 0.
If STAT_RESET is read only, how would a person go about setting it to 0?
Once set to 0, is it supposed to auto-populate with the correct number/date after next power cycle? Where does this STAT_RESET value come from, and is there a way for a user to trigger or input the correct value?
Does this sound like an RMA?
Am I missing something obvious?