Rover-4.6.2: watchdog when downloading logs

[rmackay9]

I've received a credible report that a single boat running Rover-4.6.2 on a CubeOrangePlus with Here4 GPS is continually failing with a watchdog error. The report is:

1. a very large log file was produced when the vehicle was left armed for a long time
2. during download MP showed an error, "Error in log Timeout on read - GetLog"

3. even after deleting the crash_dump.bin file from the SD card the "PreArm: CrashDump data detected" message persisted (perhaps this means a new crash dump file was produced?

The log files are not immediately available (because the failure seems to occur during downloading) but the crash_dump.bin can be found here. https://www.dropbox.com/scl/fi/zahstgqto7z84ak8o3lec/crash_dump.bin?rlkey=20aw9mkixdx0fqwexlkezsxda&dl=0

The firmware used is AP Rover-4.6.2 which can be found here. This is commit: 1ebd4d9

[tpwrules]

It would be excellent if you could get the user to retrieve the SD card from the vehicle and create a disk image of it using e.g. https://sourceforge.net/projects/win32diskimager/ . A compressed version should not be too awful to share.

[rmackay9]

I think this has most likely been resolved by @tpwrules's recent working including this PR #31620

[IamPete1]

We have also have a report on plane 4.6.3 that is likely the same issue.

https://discuss.ardupilot.org/t/cube-orange-reboots-while-downloading-dataflash-log-via-mission-planner-over-usb-crashdump-detected/141492

The (partial) watchdog message provided by the user decodes to:

    T            Scheduler Task:           21: 21
   SL            Semaphore Line:            0: Not waiting on semaphore
   FL                Fault Line:          217: ?????
   FT                Fault Type:            3: HardFault
   FA             Fault Address:   0x3001e218: ?????
  FTP     Fault Thread Priority:          183: ?????
  FLR Fault Long Return Address:     0x150000: ?????

I have not yet had a chance to look at the provided crash-dump.

[IamPete1]

@tridge had a quick look at the Rover crash dump during the dev-call but the results were not conclusive:

(gdb) bt
#0  0xe000fffe in ?? ()
#1  0x081659fe in ChibiOS::Scheduler::_monitor_thread (arg=0x30017fa4 <schedulerInstance>)
    at ../../libraries/AP_HAL_ChibiOS/Scheduler.cpp:482
#2  0x08020f46 in __port_thread_start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[tpwrules]

That means the CPU and scheduler were still running (and the scheduler deliberately faulted), it was the main thread that was stuck.

[rmackay9]

I'm going to optimistically go-ahead and mark this as resolved. If we find the watchdog occurs in 4.7 then we can re-open