Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

sample hci_usb fails with zephyr 2.2.0 (worked with zephyr 2.1.0) #23866

Closed
lawrence-king opened this issue Mar 27, 2020 · 19 comments
Closed

sample hci_usb fails with zephyr 2.2.0 (worked with zephyr 2.1.0) #23866

lawrence-king opened this issue Mar 27, 2020 · 19 comments
Assignees
@carlescufi @eobalski
Labels
area: Bluetooth area: USB Universal Serial Bus platform: nRF Nordic nRFx

Comments

@lawrence-king
Copy link

Describe the bug
The sample zephyrproject/zephyr/samples/bluetooth/hci_usb/ fails to operate as expected when built with Zephyr v2.2.0. It works exactly as expected when built with Zephyr v2.1.0.

To Reproduce
Steps to reproduce the behaviour:

  1. mkdir hci_usb
  2. cd zephyrproject/zephyr
  3. git checkout v2.2.0
  4. west update
  5. cd ../../hci_usb
  6. rm -rf build
  7. west build -b nrf52840_mdk ../zephyrproject/zephyr/samples/bluetooth/hci_usb/
  8. west flash
    • unplug and replug the USB cable for the nrf52840_mdk board
  10. sudo hciconfig hci0 up
    Can't get device info: No such device

Expected behavior
The hciconfig command should complete without an error message. When the same sample is built with Zephyr v2.1.0 it works as hci0 perfectly. To test this, repeat the above steps except checkout v2.1.0.

Impact
I have not yet tested my other Bluetooth code using kernel v2.2.0, but the fact that a 'simple' sample doesn't work makes me nervous.

Screenshots or console output

Environment (please complete the following information):

  • OS: Linux 19.04
  • Toolchain Zephyr SDK 0.11.2

note the v2.1.0 hci_usb works correctly on both Windows and linux.
The v2.2.0 hci_usb does not work on either Windows or Linux. On Windows the error is:

This device cannot start. (Code 10)

{Operation Failed}
The requested operation was unsuccessful.

although I have no idea what code 10 means.

Additional context
@lawrence-king lawrence-king added the bug The issue is a bug, or the PR is fixing a bug label Mar 27, 2020
@carlescufi carlescufi added area: Bluetooth area: USB Universal Serial Bus platform: nRF Nordic nRFx labels Mar 27, 2020
@eobalski
Copy link
Collaborator

eobalski commented Mar 31, 2020 •
edited
Loading

I do not have nrf52840_mdk with me but I've checked that with nrf52840_pca10056 and everything works as expected.
Could You please check what is the log output to console by the sample?
You can add DBG logs by adding:

CONFIG_LOG=y
CONFIG_USB_DEVICE_LOG_LEVEL_DBG=y

in the sample's prj.conf file

@lawrence-king
Copy link
Author

lawrence-king commented Mar 31, 2020 via email

@eobalski
Copy link
Collaborator

Yes, I am using USB hub, this should work without any difference. Ok, from log's I can tell that the USB HW on nrf was successfully powered on, otherwise You would see

Failed to enable USB

I've edited the comment in regards of additional logs. Could You please try to add:

CONFIG_LOG=y
CONFIG_USB_DEVICE_LOG_LEVEL_DBG=y

to the samples prj.conf and see the log output? Previously I forgot to add the CONFIG_LOG (sorry about that) line that's why it does not outputs anything more despite this:

*** Booting Zephyr OS build zephyr-v2.2.0  ***
Bluetooth over USB sample

@lawrence-king
Copy link
Author

lawrence-king commented Mar 31, 2020 via email

@lawrence-king
Copy link
Author

Update: I should have been clearer about my test setup. I am working with a Win10 laptop, on the laptop I am also running Oracle VirtualBox which then runs Linux 19.04. When I plug in the usb_hci device first Win10 probes the device and decides what it is, then it hands the device over to Linux. The Win10 probe is failing. Win10 does realize that it sees a "Generic Bluetooth Adapter", but the adapter has some issue (Error 10), hence the device doesn't get handed over to the VM Linux.
Bluetooth

@lawrence-king lawrence-king reopened this Mar 31, 2020
@lawrence-king
Copy link
Author

I don't know how I got this closed. Oops...

@carlescufi
Copy link
Member

carlescufi commented Mar 31, 2020 •
edited
Loading

@lawrence-king I think we need to separate two things here: hci_usb working on Linux (in 2.2.0) and hci_usb working on Windows at all.

I just tested both Zephyr 2.1.0 and 2.2.0 with the following results:

  • On Windows,
  1. If I don't disconnect my built-in Bluetooth, I get the following event in the event viewer if I try to connect the dongle:
    image

That's because I already have a Bluetooth adapter in my Windows machine, and it doesn't support two active.

  1. If I disconnect my built-in Bluetooth, I get the following:

image

My suspicion here is that Windows 10 does not like single-mode adapters, and probably requires a dual-mode one.

On Linux:

Works fine out of the box:

carles@zephyr-nrf ~/src/zephyr/zephyr ((zephyr-v2.2.0))
$ hciconfig
hci0:   Type: Primary  Bus: USB
        BD Address: 00:00:00:00:00:00  ACL MTU: 27:7  SCO MTU: 0:0
        UP RUNNING
        RX bytes:486 acl:0 sco:0 events:41 errors:0
        TX bytes:217 acl:0 sco:0 commands:41 errors:0

@carlescufi
Copy link
Member

@lawrence-king

note the v2.1.0 hci_usb works correctly on both Windows and linux.

When you say "works correctly on Windows" what do you mean exactly? You can actually use it with the Windows built-in Bluetooth stack? Because I just tried that and it doesn't seem to work.

@carlescufi
Copy link
Member

Update: I should have been clearer about my test setup. I am working with a Win10 laptop, on the laptop I am also running Oracle VirtualBox which then runs Linux 19.04. When I plug in the usb_hci device first Win10 probes the device and decides what it is, then it hands the device over to Linux. The Win10 probe is failing. Win10 does realize that it sees a "Generic Bluetooth Adapter", but the adapter has some issue (Error 10), hence the device doesn't get handed over to the VM Linux.

I use the exact same setup except I use VMWare Workstation and I do not have the same problem. From VirtualBox or VMWare you can select explicitly where a USB device is to be connected:

image

and then:

image

@carlescufi carlescufi added question and removed bug The issue is a bug, or the PR is fixing a bug labels Mar 31, 2020
@lawrence-king
Copy link
Author

In my setup (Win10/VirtualBox/Linux) I can use the v2.1.0 hci_usb adapter from the Linux VM to successfully do over the air updates to a nrf52840 based Zephyr board.

With Zephyr v2.2.0 I am unable to connect the usb_hci adapter to the Linux VM, and Win10 gives the same error 10 you are seeing. The BT adapter is not visible to VirtualBox.

VirtualBox has similar settings to the ones you are showing for VMWare.

My laptop (Lenovo T480s) has a built-in BT adapter, it is up and running all the time, I don't need to disable it. Turning off the built-in adapter makes no difference (other than my external mouse and keyboard stops working)

If there is anything else I can try to help resolve this, please let me know.

@carlescufi
Copy link
Member

In my setup (Win10/VirtualBox/Linux) I can use the v2.1.0 hci_usb adapter from the Linux VM to successfully do over the air updates to a nrf52840 based Zephyr board.

Right, but when you plug in a v2.1.0 hci_usb adapter and don't direct it to the VM, what do you see in Device Manager? I see the following:

image

image

Which basically means that Windows cannot use it anyway. I just want to make sure that with v2.1.0, when it works in your Linux VM, Windows does not however know how to use it.

With Zephyr v2.2.0 I am unable to connect the usb_hci adapter to the Linux VM, and Win10 gives the same error 10 you are seeing. The BT adapter is not visible to VirtualBox.

That is very strange. If Windows sees it then I do not understand why VirtualBox doesn't. VirtualBox and VMWare intercept the device very low in the USB stack, so the fact that Windows doesn't know what to do with a particular device should have nothing to do with the VM being able to use it or know. i.e. a device for which you have no driver on Windows should still work fine when redirected to the VM if Linux supports it.

@lawrence-king
Copy link
Author

With Zephyr v2.2.0 I see exactly what you see

With Zephyr v2.1.0 I see this:
win_ble
win_ble2
win_ble1

of course windows then blue-screens If I actually try to use the device, but it is in good enough shape that Windows is happy to hand it over to VirtualBox/Linux where it works great. Here is the Log from the v2.1.0 device as it starts up, windows probes it, hands it over to VirtualBox and Linux starts it up.
v2.1.0_startup.txt

@carlescufi
Copy link
Member

@lawrence-king

With Zephyr v2.1.0 I see this:

OK, I am puzzled because even with zephyr v2.1.0 I see the same error on my side, whereas as you say in your case it actually manages to start up the controller, which contradicts my theory about it being single mode preventing Windows from using it, and also not sure why it doesn't fail given that you already have a Bluetooth adapter and a second one should fail.

but it is in good enough shape that Windows is happy to hand it over to VirtualBox/Linux where it works great.

Can you tell me how exactly you are sharing the device between Windows and VirtualBox? On VMWare there are two ways of doing that:

  1. Share Bluetooth with the VM (this is a bad idea)
    image

This is not a good idea at all because then VMWare inserts itself at the HCI level and complicates things quite a bit

  1. Connect the whole USB device directly to the VM

image

This removes the device from Windows completely and lets Linux take full control. This should work regardless of whether the device has been correctly configured by Windows or not (i.e. even with the failure I see in Device Manager I am still able to use this option to redirect the device to the VM and use it there without problems).

If you are using something similar to 1. please try 2. instead.

@carlescufi carlescufi assigned carlescufi and unassigned jfischer-no Apr 1, 2020
@carlescufi
Copy link
Member

carlescufi commented Apr 1, 2020 •
edited
Loading

@lawrence-king
First, let me tell you that with VMWare Workstation or with VWMare Player there are no issues at all, I have confirmed this in more than one machine. VMWare seems to be much more solid at handling USB devices than VirtualBox. VMWare Player is free for non-commercial use (just like VirtualBox) so I would recommend you try with that.

I just investigated a bit with @anangl who uses VirtualBox as well, he uses VirtualBox 6.0.18. We tested the hci_usb sample in Zephyr 2.1.0.
What we saw there is VirtualBox trying to take the USB device but failing with a nonsensical error message, so my theory as of now is that VirtualBox has a bug that prevents the USB device from being taken correctly, and for some reason in your case it appears in 2.2.0 but in other machines (like @anangl's) this appears even in 2.1.0.
My recommendation to you: switch to VMWare Player/Workstation. I have been using it for years with all sorts of USB devices with no problems whatsoever, including all sorts of Bluetooth radios.
If you do take that advice, please remember to disable the "Share Bluetooth devices with the virtual machine" option in the USB settings.

@lawrence-king
Copy link
Author

Hi Charles:

In VirtualBox I am taking the whole device, not trying to share.

I had tried sharing the BT adapter that is built into the machine (an Intel BT chip) but I was unable to do the one thing I wanted which was push new OTA images to my Zephyr devices. So I took an MDK, built the Zephyr v2.1.0 hci-usb image, loaded it onto a nfr52840_mdk board and it worked perfectly. My coworker who uses a MAC did the same thing and we are both capable of downloading images to the systems. All was great, I was happy. (I haven't checked with my co-worker to see if v2.2.0 works on a MAC).

Then I upgraded my product to v2.2.0 and repeated all of the steps for building my app (made changes for the GPIO APIs), and went to test the OTA feature. This is where I ran into trouble and reported a bug. I have a work around, I will leave the update dongle at v2.1.0 so this isn't a show stopper for me. My other than this my product works great with Zephyr v2.2.0. Thanks to the entire Zephyr team for a great product.

However it seems to me that if the hci_usb sample is truly a "Generic Bluetooth Dongle" it should work under Windows, not just Linux. I may well change over to VMWare, but this is just a different workaround for the underlying problem.

@carlescufi
Copy link
Member

@lawrence-king

However it seems to me that if the hci_usb sample is truly a "Generic Bluetooth Dongle" it should work under Windows, not just Linux. I may well change over to VMWare, but this is just a different workaround for the underlying problem.

hci_usb really is not a "Generic Bluetooth Dongle" because Generic Bluetooth dongles always support dual-mode (BR/EDR + BLE), whereas hci_usb only supports BLE.

The whole point is that I see no issue with VMWare doing exactly what you are doing: virtualizing the dongle and using it from the VM, so the fact that it works with another virtualization solution makes me think this is actually an issue with VirtualBox and not with hci_usb. The fact that it works for you with VB on 2.1.0 might be due to some circumstances that cannot be replicated by us (as I said, I tried VB today with no success on both 2.1.0 and 2.2.0).
To sum up: there is no guarantee that hci_usb will work on Windows and we have never treated it as a sample that should work there, because Windows has its own requirements for dongles that are not publicly documented.

@carlescufi
Copy link
Member

Reverting 281c7cb seems to fix the problem according to @lawrence-king, but that is very confusing because CONFIG_USB_DEVICE_BOS is not enabled in the hci_usb sample.

@carlescufi
Copy link
Member

Closing since this is currently only attributable to VirtualBox, and not Zephyr itself.

@mirko
Copy link

mirko commented Oct 11, 2020 •
edited
Loading

I'd like to add here, that I'm also experiencing strange non-working behaviour when passing-through my nrf52840 USB dongle running zephyr into a qemu/KVM virtual-machine (running linux, same debian version as hypervisor).

dmesg on hypervisor says:

[7368012.788550] usb 2-1.4: New USB device found, idVendor=2fe3, idProduct=000b, bcdDevice= 2.04
[7368012.788562] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[7368012.788567] usb 2-1.4: Product: USB-DEV
[7368012.788572] usb 2-1.4: Manufacturer: ZEPHYR
[7368012.788577] usb 2-1.4: SerialNumber: 6195E3610E0946BB

lsusb on VM says:

$ sudo lsusb -vd 2fe3:000b

Bus 002 Device 002: ID 2fe3:000b  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x2fe3 
  idProduct          0x000b 
  bcdDevice            2.04
  iManufacturer           1 ZEPHYR
  iProduct                2 USB-DEV
  iSerial                 3 6195E3610E0946BB
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               1
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

hcitool dev on VM shows no devices.

@nordicjm nordicjm mentioned this issue Apr 27, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@carlescufi carlescufi

@eobalski eobalski

Labels
area: Bluetooth area: USB Universal Serial Bus platform: nRF Nordic nRFx
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mirko @jfischer-no @carlescufi @eobalski @lawrence-king