I am experiencing a serious random reboot issue on a Starling 2 / VOXL2. The issue does not happen on every flight. Typically, the vehicle can fly several times normally, and then VOXL2 suddenly reboots during a later flight. When this happens, the vehicle immediately loses control and falls because PX4/Offboard also disappears during the reboot.

System information
Platform: Starling 2 / VOXL2
VOXL2: M0054-1, QRB5165M
VOXL Suite: 1.6.4
System image: 1.8.08-M0054-14.1a-perf
Kernel: 4.19.125
PX4 running through voxl-px4.service
Indoor flight without GPS
OpenVINS + Vision Hub
PMD ToF rangefinder
4x VOXL ESC
Reboot confirmation

Immediately after the latest event:

$ uptime
15:58:55 up 7 min

$ cat /proc/uptime
467.18 2576.05

This places the reboot at approximately 15:51.

The services also restarted at approximately the same time:

voxl-open-vins-server : ~15:51:15
voxl-vision-hub : ~15:51:15
voxl-px4 : ~15:51:17

Therefore, this does not appear to be only an OpenVINS reset or a PX4 service restart. The complete Linux system rebooted.

PMIC reset reason

The most interesting information from the new boot is:

qcom,qpnp-power-on ... pm8150@0:
PMIC@SID0 Power-on reason:
Triggered from CBL (External Power Supply) and 'cold' boot

PMIC@SID0:
Unknown power-off reason

qcom,qpnp-power-on ... pm8150b@2:
PMIC@SID2 Power-on reason:
Triggered from CBL (External Power Supply) and 'cold' boot

PMIC@SID2:
Unknown power-off reason

qcom,qpnp-power-on ... pm8150l@4:
PMIC@SID4 Power-on reason:
Triggered from PON1 (Secondary PMIC) and 'cold' boot

PMIC@SID4 Power-off reason:
Triggered from S3_RESET_PBS_WATCHDOG_TO

The kernel also reports:

msm_watchdog 17c10000.qcom,wdt:
MSM Watchdog Initialized

However, there is no /dev/watchdog* or /sys/class/watchdog/ interface available on this image.

Could you clarify what conditions on VOXL2 / QRB5165M + PM8150L can cause:

S3_RESET_PBS_WATCHDOG_TO

and whether this reset reason indicates a known VOXL2 hardware, PMIC, subsystem, or firmware issue?

Previous SLPI failure

I previously observed a separate failure on this same system involving SLPI / IMU communication.

The log included messages similar to:

ERROR [muorb] Sending kill command to SLPI!!!
Accel #0 fail: TIMEOUT!
Keep alive timeout from Apps
Created /data/px4/slpi/keepalive_fail
Forcing blind descent / land

In that previous case, /data/px4/slpi/keepalive_fail was created.

For the latest full-system reboot described above, /data/px4/slpi/ is empty after reboot:

$ ls -lah /data/px4/slpi/

total 8.0K
drwxr-xr-x 2 system system 4.0K Sep 21 11:47 .
drwxr-xr-x 6 root root 4.0K Sep 15 16:16 ..

I am therefore wondering whether the earlier SLPI/SSC failure and the current PMIC watchdog reset could be related.

Wi-Fi behavior after the abnormal reboot

There is another repeatable symptom that may be relevant.

After this abnormal reboot, Linux/VOXL2 comes back up, but Wi-Fi does not recover correctly.

A normal reboot/power-up normally provides Wi-Fi access, but after this failure the Wi-Fi connection remains unavailable. I have to completely remove power from VOXL2 and power it on again before Wi-Fi works normally.

So the observed sequence is:

Normal operation
↓
Several flights
↓
Unexpected reset during flight
↓
VOXL2 performs a full/cold reboot
↓
Linux/PX4 services restart
↓
Wi-Fi does not recover
↓
Complete physical power cycle
↓
Wi-Fi works again

This makes me suspect that some subsystem or peripheral may not be completely reset by the abnormal reset sequence.

Temperature and system load

Immediately after reboot, system temperatures and load were normal:

CPU temperature: ~53 C
GPU temperature: ~51 C
CPU utilization: ~28%
Memory usage: ~2.2 GB / 7.7 GB

Therefore, I do not currently see evidence of a thermal shutdown or memory exhaustion.

ESC status

All four ESCs were online after reboot:

esc_count: 4
esc_online_flags: 15
esc_armed_flags: 15

ESC temperature: ~46 C
esc_errorcount: 0
failures: 0
Battery information

At the time I checked after the event:

voltage_v: 6.274 V
cell_count: 2
remaining: 0.27263

The ESCs reported approximately:

6.256 - 6.276 V

I understand that this is a low battery voltage, so I am also investigating possible voltage sag / power integrity issues under motor load.

However, I would particularly like to understand whether a simple input power/brownout condition would normally produce:

S3_RESET_PBS_WATCHDOG_TO

or whether a different PMIC reason such as UVLO would normally be expected.

Questions
What exactly causes S3_RESET_PBS_WATCHDOG_TO on the VOXL2 QRB5165M / PM8150L platform?
Is this a known issue on VOXL2, system image 1.8.08, or VOXL Suite 1.6.4?
Could an SLPI/SSC subsystem hang eventually result in this type of full-system reset?
Could a short input voltage drop/brownout produce S3_RESET_PBS_WATCHDOG_TO, or should we expect a different PMIC reset reason such as UVLO?
Could the fact that Wi-Fi remains unavailable after the abnormal reboot, but recovers after a complete power cycle, indicate that a peripheral/power domain is not being completely reset?
Are there any additional Qualcomm crash dump, PMIC, watchdog, minidump, or reset-reason logs that we can enable or collect to determine the root cause before the next occurrence?

This is currently preventing further flight testing because a VOXL2 reboot during flight causes an immediate loss of control and the vehicle falls.

Any guidance on additional debugging steps or logs to collect would be greatly appreciated.