[STAT_RESET = 0] + Losing parameters + "Check BRD_TYPE" + Critical Service Bulletin on Cube Black

[XWorks (Brian)]

Hello! (@philip @rmackay9)

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:

Cube #1

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…

Cube #2

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.

Questions:

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?

Thank you!

[philip]

@Michael_Oborne

[Michael_Oborne]

cube #1, can you check the sdcard. im starting to wonder if the sdcard is involved with this problem.
the MP error about Timeout on read - GetLogEntry is saying that MP asked the AP for a log list, and the AP never responded.

cube #2 this is a black as well?

to get STAT_RESET to 0, all params must be reset/wiped. you can do this from the raw param screen “reset to defaults”

also given the #2 cube is new, can you details the exact setup you have on that? ie where cables go and how you are powering it etc. (are both gps’s on one can ports etc)

[TunaLobster]

Anecdotal, but I had this issue with different sd cards (different brand, class, and capacity) as well as with no SD card on an orange. Since I updated the bootloader from master branch it has not done a reset. I made a Lua script play a tune letting me know that the parameters have not been reset. It’s a terrible work around, but it works.

[XWorks (Brian)]

Awesome, thank you!

I checked the SD card:

Looks like it’s ok, doesn’t appear to be corrupted, although the latest logs look like they are from more than 1 month ago. As mentioned, I’ve had LOG_DISARMED set to 1 recently, shouldn’t there be more logs on the SD card in that case? I also swapped the SD card for a 32GB Samsung EVO Select card, no change. Is that card compatible? What would you suggest I look for in the SD card or elsewhere to indicate whether it’s a problem?

Another piece of info: After flashing Rover to the Cube, freemem shows 65535. Flash back to Copter, freemem shows 0.

And yes, Cube #2 is also a Cube Black, but contrary to my previous post it looks like it may have been purchased in 12/2018 (rather than in 2020) and shelved until recently. I’m waiting on confirmation from ProfiCNC.

Cube #2 Setup details: powered with two Mauch BECs (Power1 and Power2) with HERE2 GPS on i2c and CAN1, TELEM1 to a datalink and TELEM2 to a companion computer. USB to a buzzer. MAIN 1-6 outs to BLHeli32 ESCs, AUX outs to landing gear and a gimbal. RC IN from an FrSky X8R radio link, SBUS out to the same.

@Michael_Oborne

to get STAT_RESET to 0, all params must be reset/wiped. you can do this from the raw param screen “reset to defaults”

I’ve tried what you suggested on another, healthy, normal cube (Cube #3). “Reset to defaults” on the raw parameters screen resets all parameters, but STAT_RESET keeps counting upwards.
Before Reset to defaults:

After Reset to defaults:

Here’s what the problem Cubes look like:

Also, there’s this:

@Michael_Oborne thank you very much!
@TunaLobster thanks for the info! I’ll give it another shot!

[Michael_Oborne]

can you try removing all the logs/backup from the sdcard? so the card is blank. and see how it responds?

also stat_reset requires a gps lock to set. ie it doesnt know the time if you dont have gps lock. so i dont see anything too odd about what your seeing.

[XWorks (Brian)]

Ok, I erased all folders and files visible through Windows File Explorer on the SD Card and set Cube #1 LOG_DISARMED. Results:

I’m able to load and play Telemetry Logs (not DataFlash) that are newly created by the Cube and stored in the Mission Planner > logs > Hexarotor.

I’m not able to load DataFlash logs as before, Mission Planner gives the same error:

Removed SD card and checked in File Explorer: APM>LOGS folder was created, but is empty.

[Michael_Oborne]

If you set log disarmed but are not getting any logs makes me think there is a comparability issue with the SD card

[XWorks (Brian)]

Hi @Michael_Oborne I swapped SD cards in the Cube with no luck, also used the SD card from this Cube in another Cube and recorded logs just fine. I believe it’s the SD card that came with the Cube, a standard SanDisk EDGE 8GB.

I’m still getting the “Check BRD_TYPE: Failed to init - sensor” error as well as Critical Service Bulletin popup on every Cube #1 power up now. Should I RMA? Thanks!

[XWorks (Brian)]

Also, thanks for the tip on STAT_RESET. As soon as I got GPS lock on Cube #2 STAT_RESET populated with a value other than 0.

[XWorks (Brian)]

@philip @Michael_Oborne should this be an RMA? Have tried several SD cards including those shipped with the Cubes but with no luck, still keep getting "Check BRD_TYPE: Failed to init - sensor” error as well as Critical Service Bulletin popup on every power up, I’ve attempted factory resets, Rover/Plane/Copter firmware reflashes, Mission Planner is 1.3.72, etc.

Thanks!

[philip]

You are welcome to rma it. Please refer to this post when you do

[XWorks (Brian)]

Will do, thank you Philip

[sibujacob (SJ)]

Hi,

Do you have a script procedure available to implement the lua script

[philip]

Look in the Ardupilot wiki, just search Lua and Ardupilot

[Dineshkumar_elumalai]

@XWorks

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?

You can reset it using MAVProxy, refer to this post - How to manually update STAT_FLTTIME parameter? - #4 by Dineshkumar_elumalai - Copter 3.5 - ArduPilot Discourse