Replies: 5 comments
-
Well, having looked into this further, I can answer:
No - a firmware with just a config for a vendor interface can be recognized as a valid USB device by a USB host.
Yes. There are plenty of caveats, most important for me was this this:
So eventually libusbK worked as a driver for me (note there is a whole procedure about signing). Note that even with no endpoints, one needs to have one interface defined, otherwise the configuration descriptor strings cannot be read. Windows as a USB host will try to suspend the device, especially if there are exclamation marks for the device entry in Device Manager -- and this makes the config descriptor strings unreadable; so power management should be looked into on both driver and firmware side, to minimize chances of suspending the device. |
Beta Was this translation helpful? Give feedback.
-
glad you figure it out, most of the issue is inconsistent descriptor. Exclamation mark in device manager can be caused by several reasons, you should right click and try to find more detail on the cause. You could also want to check the windows/kernel log to see why windows decide to suspend usb device. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the feedback, @hathach :
That was a tricky one for me, because a lot of times I just got:
... and of course, it doesn't tell you which requested operation was unsuccessful
As far as I can tell, the standard "kernel" log in Windows 10 is in Event Viewer app, under Windows Logs\System. As for USB, usbpcap/Wireshark did not show all URBs I expected to see; I found instead USB3HWVerifierAnalyzer.exe - it seemingly captures everything on the USB bus in .etl format (which opens in Event Viewer); then you can also convert the log to text, but it is FULL of entries like
... which again, tell me absolutely nothing - I could (probably) determine which device it is about via PortPath, but ... which "State Machine Event" occured, is impossible to know. So, I will admit - even at this time, I cannot tell exactly why Windows suspended the device (as I cannot find an explicit record of the USB suspend reason anywhere); the only thing I can say from my limited experience is that - as soon as my firmware and driver setup got good enough so the USB device was shown in Device Manager "clean", these suspends stopped. Due to this behavior, I can speculate that if Windows has your device without a driver or with an exclamation mark, it probably thinks "Ah, nothing can use this device anyways, let me suspend it so it saves power" and issues a suspend within 5-10 seconds after such a device is attached - but who knows how correct this speculation is ... |
Beta Was this translation helpful? Give feedback.
-
can you post txt file containing the tusb log with |
Beta Was this translation helpful? Give feedback.
-
Thanks @hathach :
Ah, no worries, I did not need help - I was just inspired by your earlier comment, to complain about my experience with Windows
Indeed - unfortunately my dev hardware is attached to a Windows machine, and where it is, I do not have access to a Linux machine; otherwise that is how I too would have started development! |
Beta Was this translation helpful? Give feedback.
-
I am trying to study the USB vendor specific interface. I work on a Pico/RP2040 board, and I noticed there is a so-called "Reset" interface which is vendor specific, which is shown under 'Other devices' in Windows 10 Device Manager:
As I understand it, the "orange" exclamation mark is there because this device does not have a driver loaded - which, I assume, is OK, considering this is a "vendor" interface.
Before I proceed, let me note that I've found "Vendor Descriptor Templates" in tinyusb/usbd.h:
I read this as: the interface numbered
_itfnum
has 0 for alternative setting value, and 2 endpoints in total, is ofVENDOR_SPECIFIC
class with subclass 0x00 and protocol 0x00 and string description at index_stridx
of whatever array holds the descriptor strings; and the 2 endpoints are: output bulk endpoint, and input bulk endpoint.So, I found that the Pico Reset interface is defined in pico-sdk/reset_interface.c; so I copied that into a separate project, however I did not want any CDC - I wanted only the vendor-specific interface, so I modified the descriptor from pico-sdk/stdio_usb_descriptors.c to be just:
Note that there are no endpoints defined here anymore (as in
TUD_VENDOR_DESCRIPTOR
) - but I did not think it would be a problem, because the functionality in pico-sdk/reset_interface.c is implemented in the "vendor interface control request" callbackresetd_control_xfer_cb
.(note also that the device is not "vendor specific", but instead it is of class Miscellaneous
TUSB_CLASS_MISC
; it is only the interface that is "vendor specific", that isTUSB_CLASS_VENDOR_SPECIFIC
)I got this project to compile, and after flashing the Pico, I indeed get just a single device under 'Other devices'; however:
resetd_control_xfer_cb
- cannot open this device (fails with -5 LIBUSB_ERROR_NOT_FOUND), and so cannot read string descriptorsI'm not really sure even how to confirm the power state of a USB device in Windows, since Device Manager and usbview can give contradictory information (https://stackoverflow.com/questions/73490266/retrieve-windows-usb-device-power-status-from-the-command-line), however looking at https://stackoverflow.com/questions/51025878/how-to-get-string-descriptor-from-a-usb-device-which-is-in-low-power-state
... my guess is, seeing there are on endpoints/"open pipes", Window puts the device to sleep, which then prevents libusb to open the device and usbview to read the string descriptors.
So, in summary, my questions are:
Beta Was this translation helpful? Give feedback.
All reactions