ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.71k stars 17.17k forks source link

SpeedybeeF405WING USB product name does not change after bootloader started ArduPilot main code #27737

Open booo opened 1 month ago

booo commented 1 month ago

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:

[671046.852651] usb 2-1.2: USB disconnect, device number 105
[671049.112144] usb 2-1.2: new full-speed USB device number 106 using ehci-pci
[671049.211179] usb 2-1.2: New USB device found, idVendor=1209, idProduct=5741, bcdDevice= 2.00
[671049.211187] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[671049.211189] usb 2-1.2: Product: SpeedyBeeF405WING-BL
[671049.211191] usb 2-1.2: Manufacturer: ArduPilot
[671049.211192] usb 2-1.2: SerialNumber: 270033001447333135373837
[671049.212399] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
[671054.175412] usb 2-1.2: reset full-speed USB device number 106 using ehci-pci

After a reboot the output changes slightly:

[671054.175412] usb 2-1.2: reset full-speed USB device number 106 using ehci-pci
[671329.605221] usb 2-1.2: USB disconnect, device number 106
[671329.821305] usb 2-1.2: new full-speed USB device number 107 using ehci-pci
[671329.920123] usb 2-1.2: New USB device found, idVendor=1209, idProduct=5741, bcdDevice= 2.00
[671329.920132] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[671329.920136] usb 2-1.2: Product: SpeedyBeeF405WING
[671329.920138] usb 2-1.2: Manufacturer: ArduPilot
[671329.920141] usb 2-1.2: SerialNumber: 270033001447333135373837
[671329.921591] cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
➜  ~ lsusb -d 1209:5741 -v

Bus 002 Device 106: ID 1209:5741 Generic SpeedyBeeF405WING-BL
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1209 Generic
  idProduct          0x5741 SpeedyBeeF405WING-BL
  bcdDevice            2.00
  iManufacturer           1 ArduPilot
  iProduct                2 SpeedyBeeF405WING-BL
  iSerial                 3 270033001447333135373837
  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 [unknown]
      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
peterbarker commented 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)

booo commented 1 month ago
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:

screenshot_20240803_122418

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.