Steps to reproduce
1. flight controller is connected via USB
2. USB device is
reset without unplugging it, for example
explicit reset via ioctl(fd, USBDEVFS_RESET, 0);
implicit reset due to host computer reboot, by OS/BIOS
physically unplugged and then replugged (while FC remains powered through servo headers) and subsequently initialized by the OS
graceful USB client device re-initialization. No effect on higher order firmware functions or flight control
flight controller reboots (even if in flight , if USB connection is active in flight)
Debug Trace: (useless)
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000bd4 in ?? ()
#0 0x08000bd4 in ?? ()
#1 0xffffffff in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Code to reproduce:
find out dev tree of flight controller and explicitly reset it by sending aproprate ioctl:
$> lsusb | grep Clay
Bus 001 Device 117: ID 20a0:415e Clay Logic
with usbreset code snippet from
If GCS is connected via USBHID, and the reset is sent, controller does NOT reboot, but the telemetry stream is interrupted. Then two things can happen.
If GCS is manually disconnected and reconnected to the USB device (which might change device ID - sometimes), then this step can be reproduced indefinitely
2. if GCS is kept in its degraded connection state or simply closed and not reconnected, any further RESET ioctl will crash/reset the flight controller. the same happens if GCS was never connected
STM32f4 for example Openpilot Revolution, revomini, ...