Open booo opened 1 month ago
Thanks for the detailed report.
I happen to have one of these on my desk right now, and I'm unable to replicate. I've tried master and 4.5.5.
The easiest/most critical thing to look at is the serial device:
lrwxrwxrwx 1 root root 13 Aug 3 09:18 usb-ArduPilot_SpeedyBeeF405WING-BL_37002F000E47333034313838-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Aug 3 09:18 usb-ArduPilot_SpeedyBeeF405WING_37002F000E47333034313838-if00 -> ../../ttyACM0
product strings change for me:
pbarker@fx:~$ lsusb -d 1209:5741 -v
Bus 001 Device 028: ID 1209:5741 Generic SpeedyBeeF405WING
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1209 Generic
idProduct 0x5741
bcdDevice 2.00
iManufacturer 1 ArduPilot
iProduct 2 SpeedyBeeF405WING
iSerial 3 37002F000E47333034313838
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
pbarker@fx:~$
pbarker@fx:~/rc/ardupilot((HEAD detached at Plane-4.5.5))$ uname -a
Linux fx 6.5.0-41-generic #41~22.04.2-Ubuntu SMP PREEMPT_DYNAMIC Mon Jun 3 11:32:55 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
pbarker@fx:~/rc/ardupilot((HEAD detached at Plane-4.5.5))$
Another thing you could try is resetting all the USB buses to see what happens. I have this script in my path to make that easy: https://github.com/peterbarker/dev-tools/blob/master/reset-usb . Not a solution, but will bisect the problem between the linux machine and the board (bisection could also be done with a powered USB hub, probably)
echo 0000:00:1d.0 > /sys/bus/pci/drivers/ehci-pci/unbind
echo 0000:00:1d.0 > /sys/bus/pci/drivers/ehci-pci/bind
With this I can reset the usb pci driver I guess. This results in a change of the product name :mechanical_arm: And QGC automatically connects to the port.
I have a usb_reset script as well. But that does nothing helpful:
sudo usbreset 1209:5741
I have a vague memory that this happend with other boards in the past as well. But the memory is quite vague...
I used modprobe to add usb monitoring:
sudo modprobe usbmon
Then I used wireshark to take a closer look at the frames.
We only receive one "string descriptor" with the product information:
A dump from wireshark can be found here:
https://downloads.borgers.it/speedybeef405wing-usb.pcapng
What we can observe as well is that we request the serial number twice. But on the second attempt (I guess once the actual software starts) we only request the serial number and no other information such as the product name.
Bug report
I have a SpeedybeeF405WING flashed with ArduPilot. But I'm having problems connection to the device with QGC. As far as I understand QGC is waiting for the devices to change its product name to something without the "BL" suffix. Unfortunately the host system never sees this change and QGC thinks we are stuck in the bootloader. Which we are actually not because if I connect with mavproxy or manually connect with QGC the connection via USB works and I can e.g. reboot the devices which in turn results in a change of the product name for whatever reasen. Which in turn lets QGC do its auto connect magic.
I use linux:
Linux x220 6.6.35-2-lts #1 SMP PREEMPT_DYNAMIC Fri, 21 Jun 2024 21:05:23 +0000 x86_64 GNU/Linux
Similar problems encountered on other versions of linux systems.Any ideas what is going on?
Maybe the bootloader should stop the usb peripherals before loading the actual firmware? That way the host maybe gets the updated product data via a new message?
Version
4.5.5
Platform [ ] All [ ] AntennaTracker [ ] Copter [x] Plane [ ] Rover [ ] Submarine
Hardware type
SpeedybeeF405WING
Logs
Kernel log:
After a reboot the output changes slightly: