how to re-enumerate USB device
Vladimir Beker
will issue IOCTL_INTERNAL_USB_RESET_PORT? How it should affect other
drivers? Note, that the device may return another set of interfaces in
configuration descriptor after the reset.
For now, I am experimenting with single driver. When I issue
IOCTL_INTERNAL_USB_RESET_PORT, I see that device is really re-enumerated,
but I see no IRP sent to my driver as result. Should I?
My final purpose is to implement DFU class, which should be able to reset
device twice during operation.
Thanks
Vladimir
Walter Oney
> What if I will several class drivers dealing with one device and one of them
> will issue IOCTL_INTERNAL_USB_RESET_PORT? How it should affect other
> drivers? Note, that the device may return another set of interfaces in
> configuration descriptor after the reset.
>
> For now, I am experimenting with single driver. When I issue
> IOCTL_INTERNAL_USB_RESET_PORT, I see that device is really re-enumerated,
> but I see no IRP sent to my driver as result. Should I?
Your device firmware needs to simulate an actual bus disconnect, so that
all the function drivers get surprise removal notifications. This will
also unload your DFU driver. When the device reenumerates, it exposes
just the DFU interface. That brings the DFU driver back into memory.
When you're done with the download, the device will disconnect again.
When it comes back, it has the runtime descriptor set again.
I was part-way down the path of building a DFU driver once upon a time.
I had planned to rely on a user-mode app that wouldn't keep its handle
to the DFU driver open so that this unloading and reloading stuff could
happen.
BTW, I don't know of any devices that actually follow the DFU spec.
That's probably why Microsoft never built a standard driver and why you
don't hear a big clamor out in the world.
--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
Michael Hetherington
"Walter Oney" <walt...@oneysoft.com> wrote in message
news:3F3F608C...@oneysoft.com...
Enjoy reading your book, man. But I think you are missing the point here.
Vladimir does not ask about DFU interface. What he is asking probably looks
like this:
There is a composite USB device with 2 interfaces (A & B for example).
Individual drivers support both interfaces. Now, some of driver B
functionality is done using vendor requests via default control endpoint. At
some point of time the USB device times out on the vendor request, and
driver B resets the port with IOCTL_INTERNAL_USB_RESET_PORT. So is there any
mechanism in Windows to inform driver A about the reset?
>Your device firmware needs to simulate an actual bus disconnect.
Will not work nice, as Windows AFAIK unlike Linux, for example, forces its
own reset during enumeration. (Does it mean that the device has to track its
state and know what type of reset it is?)
Windows enumeration:
1) Device reset -> Read device descriptor -> Windows reset -> Read
device descriptor -> Read configuration descriptor -> work .
Walter proposal on Windows:
1) Device reset -> Read descriptor -> Windows (device) reset -> Device
reset -> Read descriptor -> Windows reset -> Device reset -> death .
Michael.
Alexander Grigoriev
the child drivers asked for it within some time window.
If the device times out on some URB, you better just cancel the IRP instead
of resetting the device. And USB reset is not equal the device reset. If the
device firmware is hung, USB reset may not help.
The USB device should not rely on any particular sequence of SETUP commands,
be it LINUX or Windows enumeration procedure. It should conform to the state
transition diagram in the USB standard (DEFAULT, ADDRESSED, CONFIGURED,
SUSPENDED, etc). USB reset always puts the device to DEFAULT state.
"(Does it mean that the device has to track its state and know what type of
reset it is?)"
Yes, the device should know in which of the standard states it is.
"Michael Hetherington" <chin...@MOVEpacific.net.sg> wrote in message
news:bhpg6r$vap$1...@nobel2.pacific.net.sg...
Michael Hetherington
question through. I was actually contemplating using USB reset as a general
MCU reset in my design (Interface driver acts as a watchdog) Not what
Vladimir means.
Michael.
Walter Oney
And would both of you kindly read the DFU specification at usb.org so
you understand what the OP is trying to do?
Ilya Faenson
fully support the DFU spec, and a consultancy of mine happened to
have developed the USB DFU driver (and an accompanying app employing
the idea you talk about below) a couple of years ago. It is widely
used in the Bluetooth community.
Thanks,
Ilya Faenson
ifae...@hotmail.com
Walter Oney <walt...@oneysoft.com> wrote in message news:<3F3F608C...@oneysoft.com>...
> ...
Vladimir Beker
Actually, the answer of Walter Oney is the closest one to my problem. I do
speak about DFU, i.e. about returning differnt configuration in normal and
downloading mode. And I do understand how to do it from the side of device.
The question was side of driver. If I understand DFU spec correctly, it is
responsibility of HOST to issue USB Reset on device (without powering off)
so that it will return other sets of descriptors on next enumeration. BTW,
particulary to Win2000 I succeed to do it with IOCTL_INTERNAL_USB_CYCLE_PORT
but I am not sure how will it work on other platforms. Unlike RESET PORT it
really forces device objects to be destroyed and re-created. The reason I
chosen DFU was simple: I need downloading feature for my device. If there is
no standard driver I will have write my own. But if there is any standard
that applies my needs - I prefer to use it: probably one day there will be
standard drivers too.
But one of you reminded other porblem I have. My device may have 2
vendor-specific interfaces (let's say A and B) and 1-2 standard interfaces.
Due to lack of endpoints it may be configured to report in configuration
descriptor only part of them. Without vendor specific interfaces there would
be no problem - Composite device will connect all corresponding class
drivers. With vendor-specific interfaces I have a problem, since the drivers
are associated with interfaces by their numbers in the configuration
descriptor. But number may change due to configuration. I cannot use
multiple configuration descriptors since Composite Device of Microsoft will
use only one. I cannot put vendor-descriptor first (since I want two such
interfaces). I cannot define multiple product ID since there will be too
many combinations (and even more in the future).
Any ideas?
Thanks
Vladimir