ModalAI Forum

Hi ModalAI team,

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.

@Ben-Linne

Hi Ben,

Thanks for the information.

1. The red LED is NOT triple blinking. It is double blinking repeatedly:

   blink-blink -> pause -> blink-blink -> pause

   This appears to be the normal ExpressLRS waiting-for-binding pattern,
   rather than the triple-blink teamrace/model mismatch indication.

2. I stopped PX4 completely and tested voxl-elrs directly:

   $ systemctl status voxl-px4
   Active: inactive (dead)

   $ voxl-elrs ping
   elrs: auto-detection: voxl-px4 crsf_rc is not running, using qup7
   Sending library name request: libslpi_qrb5165_io.so
   Sending initialization request
   Error: get device info: no response from device (is it connected and powered?)

So the issue does not appear to be limited to PX4 receiving RC data.
voxl-elrs also cannot communicate with the M0184 directly over QUP7
when PX4 is stopped.

The M0184 is powered and its red LED shows the double-blink
waiting-for-binding pattern.

Since this started immediately after upgrading from SDK 1.6.3 to 1.6.4,
and you mentioned that the upgrade updates the ELRS firmware to 3.5.3.23:

• Could the M0184 firmware update have caused the receiver to lose its
  previous binding/configuration?
• Is it expected that voxl-elrs ping gets no response while the receiver
  is waiting for binding?
• Is there a recommended recovery/reflash or reconfiguration procedure
  for the M0184 in this situation?

Thanks.

Hi ModalAI team,

I am troubleshooting an ELRS/CRSF issue on a Starling 2 with the
original M0184 ELRS receiver.

IMPORTANT:
The M0184 ELRS was working normally with VOXL SDK 1.6.3.
This problem started after upgrading from SDK 1.6.3 to SDK 1.6.4.

After the upgrade, the receiver still powers on and can enter binding
mode, but PX4 never receives any CRSF frames.

Hardware:

• Drone: ModalAI Starling 2 (D0014)
• VOXL2: M0054
• SKU: MRB-D0014-4-V1-C26-T8-M36-X0
• tx config: 8 (elrs_m0184)
• ELRS receiver: M0184

Software version:

• Previous SDK: 1.6.3 (ELRS working)
• Current SDK / voxl-suite: 1.6.4
• system-image: 1.8.08-M0054-14.1a-perf
• voxl-px4: 1.14.0-2.0.142
• voxl-elrs: 1.1.6
• libfc-sensor: 1.0.12
• modalai-slpi: 1.2.3

Full voxl-version output is attached below.

Configuration / services:
After the SDK upgrade I ran voxl-configure-mpa.

The detected hardware configuration is correct:

family code:   MRB-D0014 (starling-2 (D0014))
compute board: 4 (voxl2)
cam config:    26
modem config:  36 (Bots Unlimited WiFi (M0213))
tx config:      8 (elrs_m0184)
SKU: MRB-D0014-4-V1-C26-T8-M36-X0

During voxl-configure-mpa, the ELRS configuration failed:

executing: voxl-elrs configure
elrs: px4 running but no crsf data
Error: initialize ELRS: communication channel closed

FAILED TO EXECUTE:
voxl-elrs configure

PX4 was correctly configured as:

GPS=AUTODETECT
RC=CRSF_RAW

I then fully power-cycled the Starling 2.

What I am trying to do:
Restore the M0184 ELRS functionality that was working before the
SDK 1.6.3 -> 1.6.4 upgrade.

What actually happens:
After a full power cycle, PX4 starts the CRSF driver normally:

RC: CRSF_RAW
Starting CRSF RC driver
crsf_rc start -d 7
[crsf_rc] Crsf serial opened successfully
[crsf_bridge] Created pipe 'crsf_raw' on channel 3 with control pipe enabled

However:

voxl-elrs ping

returns:

elrs: px4 running but no crsf data
Error: initialize ELRS: communication channel closed

And px4-listener input_rc always shows:

timestamp_last_signal: 0
rc_total_frame_count: 0
rc_failsafe: True
rc_lost: True
link_quality: -1

Therefore, the QUP7/CRSF driver appears to open successfully, but PX4
does not receive even a single valid CRSF frame.

Troubleshooting already performed:

1. Original configuration:
   M0184 -> QUP7

   crsf_rc start -d 7 opens successfully, but no CRSF frames are received.

2. To rule out QUP7, I temporarily disabled GPS and moved the M0184
   UART signals from QUP7 to QUP6:

   J19 Pin 10 (QUP7 TX) -> Pin 2 (QUP6 TX)
   J19 Pin 11 (QUP7 RX) -> Pin 3 (QUP6 RX)
   

   Power and GND were unchanged.

3. I started:

   px4-qshell crsf_rc start -d 6
   

   Again:

   Crsf serial opened successfully
   

   but input_rc remained:

   timestamp_last_signal: 0
   rc_total_frame_count: 0
   rc_lost: True
   

4. I restored the original wiring:

   • GPS -> QUP6
   • M0184 -> QUP7

   GPS communication on QUP6 works normally after restoration.

5. I ran voxl-configure-mpa, performed a full power cycle, and tested
   again. The ELRS behavior remains unchanged.

Questions:

1. Since the M0184 was working with SDK 1.6.3 and stopped working after
   upgrading to SDK 1.6.4, are there any known M0184 / CRSF / SLPI
   compatibility or configuration changes between these SDK versions?

2. Could the SDK 1.6.4 upgrade or voxl-elrs configure have changed or
   updated the firmware/configuration on the M0184?

3. Does rc_total_frame_count: 0 in this situation indicate that no
   UART data is being received from the M0184, or could this also be
   caused by a CRSF protocol/baud/configuration mismatch?

4. Is there a recommended way to test the M0184 UART independently of
   QUP6/QUP7?

   For example, can I connect a 3.3V USB-UART adapter to the VOXL2 USB
   host and run:

   voxl-elrs -p /dev/ttyUSB0 -b 420000 ping
   

   with:

   M0184 TX -> USB-UART RX
   M0184 RX <- USB-UART TX
   GND      -> GND
   M0184 powered separately from 5V
   

5. If the above USB-UART test is supported, is 420000 baud / 3.3V UART
   the correct electrical and serial configuration for the M0184?

Thanks.

Hi ModalAI team,

I have a VOXL2 (M0054) board with a small SMD component near the J10 connector that was physically damaged by an accidental impact.

I removed the damaged component from the board. The component is approximately 2.0 mm × 1.0 mm, has multiple bottom pads (approximately 8 pads), and the top marking appears to be:

5BETB1

I have attached photos showing the component, its location on the VOXL2 board, and the PCB pads after removal.

The VOXL2 itself is still operating normally. J10 is currently not used in my application, so I cannot determine the function of this component from functional testing.

Could you please help identify this component and provide the following information, if possible?

Manufacturer and part number
Component type/function
Electrical specifications
Package type and pinout
Recommended replacement or compatible alternative

If the exact BOM part number cannot be disclosed, a compatible replacement specification would also be very helpful.

I would like to repair the board rather than replace the entire VOXL2.

Thank you for your help.!