USB Reset for DFU with WINUSB

I am working on an implementation of DFU Download/upload to a device using
WINUSB (as an application).

Reading the DFU Spec, I noticed that DFU requires a USB Reset between
operations. Reading a bit about it and I noticed WINUSB does not support
USB Reset.

How can I develop DFU without a USB Reset support ? Or am I missing
something with WINUSB ?

Thanks,
Jim

Jim wrote:

I am working on an implementation of DFU Download/upload to a device
using WINUSB (as an application).

Reading the DFU Spec, I noticed that DFU requires a USB Reset between
operations. Reading a bit about it and I noticed WINUSB does not
support USB Reset.

How can I develop DFU without a USB Reset support ? Or am I missing
something with WINUSB ?

The reset should come from the device. Add a vendor command that you
can trigger with WinUSB. After a firmware reload, you are going to
re-enumerate anyway, so your WinUSB instance will no longer be valid.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I am not responsible for the hardware and may not be able to add this
feature. In addition, the DFU spec explains that a USB reset should come
after a DFU_DETACH which then put the device itself into DFU state and
after firmware upload.

libusb support it by a call to libusb_reset_device. but I cant find any
WinUSB support for it. If I remember correctly, libusb uses WINUsb in
windows ?

On Mon, Jan 6, 2014 at 7:42 PM, Tim Roberts wrote:

> Jim wrote:
> > I am working on an implementation of DFU Download/upload to a device
> > using WINUSB (as an application).
> >
> > Reading the DFU Spec, I noticed that DFU requires a USB Reset between
> > operations. Reading a bit about it and I noticed WINUSB does not
> > support USB Reset.
> >
> > How can I develop DFU without a USB Reset support ? Or am I missing
> > something with WINUSB ?
>
> The reset should come from the device. Add a vendor command that you
> can trigger with WinUSB. After a firmware reload, you are going to
> re-enumerate anyway, so your WinUSB instance will no longer be valid.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Jim wrote:

I am not responsible for the hardware and may not be able to add this
feature. In addition, the DFU spec explains that a USB reset should
come after a DFU_DETACH which then put the device itself into DFU
state and after firmware upload.

libusb support it by a call to libusb_reset_device. but I cant find
any WinUSB support for it. If I remember correctly, libusb uses
WINUsb in windows ?

That’s one of the back-ends, yes. And, because you have the source
code, you can go look up what it does. For a WinUSB back-end,
libusb_reset_device calls WinUsb_AbortPipe, WinUsb_FlushPipe, and
WinUsb_ResetPipe. None of those will actually cause a re-enumeration.
Quoting from the source code:

* from the “How to Use WinUSB to Communicate with a USB Device”
Microsoft white paper
* (http://www.microsoft.com/whdc/connect/usb/winusb_howto.mspx):
* “WinUSB does not support host-initiated reset port and cycle port
operations” and
* IOCTL_INTERNAL_USB_CYCLE_PORT is only available in kernel mode and the
* IOCTL_USB_HUB_CYCLE_PORT ioctl was removed from Vista => the best we
can do is
* cycle the pipes (and even then, the control pipe can not be reset
using WinUSB)

So, libusb can’t do it, either.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Is it safe to go with a SETUPAPI call to restart (disable/re-enable) the
device ? is there and difference then USB reset ?

On Tue, Jan 7, 2014 at 7:33 PM, Tim Roberts wrote:

> Jim wrote:
> > I am not responsible for the hardware and may not be able to add this
> > feature. In addition, the DFU spec explains that a USB reset should
> > come after a DFU_DETACH which then put the device itself into DFU
> > state and after firmware upload.
> >
> > libusb support it by a call to libusb_reset_device. but I cant find
> > any WinUSB support for it. If I remember correctly, libusb uses
> > WINUsb in windows ?
>
> That’s one of the back-ends, yes. And, because you have the source
> code, you can go look up what it does. For a WinUSB back-end,
> libusb_reset_device calls WinUsb_AbortPipe, WinUsb_FlushPipe, and
> WinUsb_ResetPipe. None of those will actually cause a re-enumeration.
> Quoting from the source code:
>
> * from the “How to Use WinUSB to Communicate with a USB Device”
> Microsoft white paper
> * (http://www.microsoft.com/whdc/connect/usb/winusb_howto.mspx):
> * “WinUSB does not support host-initiated reset port and cycle port
> operations” and
> * IOCTL_INTERNAL_USB_CYCLE_PORT is only available in kernel mode and the
> * IOCTL_USB_HUB_CYCLE_PORT ioctl was removed from Vista => the best we
> can do is
> * cycle the pipes (and even then, the control pipe can not be reset
> using WinUSB)
>
> So, libusb can’t do it, either.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Jim wrote:

Is it safe to go with a SETUPAPI call to restart (disable/re-enable)
the device ? is there and difference then USB reset ?

Absolutely. The SetupDi calls are strictly software. They will cause
the driver stack to be torn down and rebuilt, but they don’t cause
anything to happen on the wire. THAT’S the piece you’re missing, and
that has to come from the device.

Think about it. A firmware load very often causes a new VID/PID to be
exposed. To do that, the device has to present ITSELF as a new device.
The system is not going to go ask it if anything has changed.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote on Wednesday, January 08, 2014 12:40 AM

Jim wrote:
> Is it safe to go with a SETUPAPI call to restart (disable/re-enable)
> the device ? is there and difference then USB reset ?

Absolutely.

Well, if you mean “absolutely safe” - I respectfully disagree. It is
100% safe to do it once, but just do it in a loop several times - and
you’ll definitely bluescreen with some of rather common USB chips (
namely FTDI usb-to-serial ones).

Best regards,
Alex Krol

Hi,

You can reset a USB device (that uses WinUSB for driver) with e.g. the command
devcon restart ?@USB\VID_xxxx&PID_xxxx\6&7928223&0&5?

the exact device description can first be found with e.g.
devcon find USB\VID_xxxx*

This only works when the device is USB powered. You can actually see the power being cycled.
Unfortunately the command does nothing when the device is externally powered.

I have never traced devcon.exe to see which commands are actually used to reset the device.
The source code from the WinDDK is not very helpful in this regard.

Regards, Matt

That is what I refered to as SETUPAPI(SetupDi) restart. I am aware of that.
Thanks.

On Wed, Jan 8, 2014 at 1:04 PM, wrote:

> Hi,
>
> You can reset a USB device (that uses WinUSB for driver) with e.g. the
> command
> devcon restart ?@USB\VID_xxxx&PID_xxxx\6&7928223&0&5?
>
> the exact device description can first be found with e.g.
> devcon find USB\VID_xxxx*
>
> This only works when the device is USB powered. You can actually see the
> power being cycled.
> Unfortunately the command does nothing when the device is externally
> powered.
>
> I have never traced devcon.exe to see which commands are actually used to
> reset the device.
> The source code from the WinDDK is not very helpful in this regard.
>
> Regards, Matt
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

xxxxx@avantes.com wrote:

You can reset a USB device (that uses WinUSB for driver) with e.g. the command
devcon restart ?@USB\VID_xxxx&PID_xxxx\6&7928223&0&5?

the exact device description can first be found with e.g.
devcon find USB\VID_xxxx*

This only works when the device is USB powered. You can actually see the power being cycled.

You must be remembering something else, because this is not correct.
“devcon restart” simply unloads and reloads the driver. Nothing else.
No power action is taken.

I have never traced devcon.exe to see which commands are actually used to reset the device.
The source code from the WinDDK is not very helpful in this regard.

Of course it is helpful! Just because you didn’t understand it doesn’t
mean the answers aren’t there. Disable/Enable/Restart is done by
calling SetupDiSetClassInstallParams and SetupDiCallClassInstaller to
signal a DIF_PROPERTYCHANGE event with DICS_DISABLE, DICS_ENABLE, or
DICS_PROPCHANGE (respectively).

It’s wordy, but it’s not rocket science.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts, xxxxx@probo.com wrote:

You must be remembering something else, because this is not correct.
“devcon restart” simply unloads and reloads the driver.
Nothing else. No power action is taken.

I can clearly see the power led of our device going off and on again. If you measure the current in the 5V line of the USB cable, you can clearly see it dipping. The command does not work when using external power. What else to conclude from this?

I’m not a hardware guy, but I know that USB power can be controlled from the PC. I have seen in the past that from some PCs USB power was cut unexpectedly, e.g. when the screen saver cut in.

Of course it is helpful!
Just because you didn’t understand it doesn’t mean the answers aren’t there

What I meant is that you cannot deduce from the devcon source code whether USB power is being cut or not after the ‘restart’ command. But I am glad that you like this code. I especially love the ‘goto’ statements in it. And I thought that I was old school.

Regards, Matt

xxxxx@avantes.com wrote:

Tim Roberts, xxxxx@probo.com wrote:
> You must be remembering something else, because this is not correct.
> “devcon restart” simply unloads and reloads the driver.
> Nothing else. No power action is taken.
I can clearly see the power led of our device going off and on again. If you measure the current in the 5V line of the USB cable, you can clearly see it dipping. The command does not work when using external power. What else to conclude from this?

It’s coming from some place other then “devcon restart”. I do that
dozens of times a week. I KNOW it doesn’t cycle the power. I just did
it again right now, just to prove I wasn’t crazy.

Now, it’s quite possible that your DRIVER is killing the device’s power
during your unload, but there’s nothing in the kernel that will do so.

“devcon restart” does the same operation as going into Device Manager,
disabling the device, then enabling the device. Do you see the power go
away when you do that? I can’t imagine you do, because it would be
impossible to re-enable it – the device would go away once the USB
power is removed.

Do you hear the “bing bong” and “bong bing” tones that indicate a USB
device being re-enumerated?

I’m not a hardware guy, but I know that USB power can be controlled from the PC.

Oh, no question. The hub controls that. In fact, there is a ioctl you
can send to the hub driver to request cycling of power on a given port.
However, that ioctl is not sent when a USB client driver unloads. It
would be horribly inconvenient if a device lost its firmware and state
every time a driver had to reload.

What I meant is that you cannot deduce from the devcon source code whether USB power is being cut or not after the ‘restart’ command. But I am glad that you like this code. I especially love the ‘goto’ statements in it. And I thought that I was old school.

Well, devcon was written 20 years ago.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Incidentally, we specifically turn on power to a USB port when you remove the device, if the port supports D3cold and the device is turned off prior to removal, so that the port can be properly enumerated. This is also true for PCIe and SATA devices which support D3cold.

Of course, the result is the counterintuitive behavior wherein tablets running Windows use more power when you go into Device Manager and disable some devices. They can only be in D3cold when the driver is running and managing the device.

  • Jake Oshins
    (occasional power management guy)
    Windows Kernel Team

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, January 9, 2014 10:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB Reset for DFU with WINUSB

xxxxx@avantes.com wrote:

Tim Roberts, xxxxx@probo.com wrote:
> You must be remembering something else, because this is not correct.
> “devcon restart” simply unloads and reloads the driver.
> Nothing else. No power action is taken.
I can clearly see the power led of our device going off and on again. If you measure the current in the 5V line of the USB cable, you can clearly see it dipping. The command does not work when using external power. What else to conclude from this?

It’s coming from some place other then “devcon restart”. I do that
dozens of times a week. I KNOW it doesn’t cycle the power. I just did
it again right now, just to prove I wasn’t crazy.

Now, it’s quite possible that your DRIVER is killing the device’s power
during your unload, but there’s nothing in the kernel that will do so.

“devcon restart” does the same operation as going into Device Manager,
disabling the device, then enabling the device. Do you see the power go
away when you do that? I can’t imagine you do, because it would be
impossible to re-enable it – the device would go away once the USB
power is removed.

Do you hear the “bing bong” and “bong bing” tones that indicate a USB
device being re-enumerated?

I’m not a hardware guy, but I know that USB power can be controlled from the PC.

Oh, no question. The hub controls that. In fact, there is a ioctl you
can send to the hub driver to request cycling of power on a given port.
However, that ioctl is not sent when a USB client driver unloads. It
would be horribly inconvenient if a device lost its firmware and state
every time a driver had to reload.

What I meant is that you cannot deduce from the devcon source code whether USB power is being cut or not after the ‘restart’ command. But I am glad that you like this code. I especially love the ‘goto’ statements in it. And I thought that I was old school.

Well, devcon was written 20 years ago.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Jake,

What does D3Cold mean in the context of USB? Does it mean that the ClearPortFeature (PORT_POWER) command is issued to a device’s parent port? What about gang powered hubs? (I’m looking at section 10.12 of the 3.1 spec). Also, for 2.0 devices, if Vbus isn’t there, a device cannot assert its pullup resistor on D+.

On Tue, Jan 7, 2014 at 5:19 AM, Jim wrote:
> I am not responsible for the hardware and may not be able to add this
> feature. In addition, the DFU spec explains that a USB reset should come
> after a DFU_DETACH which then put the device itself into DFU state and after
> firmware upload.
>
> libusb support it by a call to libusb_reset_device. but I cant find any
> WinUSB support for it. If I remember correctly, libusb uses WINUsb in
> windows ?
>

As mentioned by Tim, you can not use WinUSB to achive your goal
with libusb.

On the other hand, libusbx (will merge with libusb soon) supports
libusbK driver along with WinUSB. So if you use libusbK driver
instead of WinUSB, you can use libusb_reset_device().
libusbK is based on KMDF.


Xiaofan

Tim Roberts, xxxxx@probo.com wrote:

Now, it’s quite possible that your DRIVER is killing the device’s power during your unload,
but there’s nothing in the kernel that will do so. “devcon restart” does the same
operation as going into Device Manager, disabling the device, then enabling the
device. Do you see the power go away when you do that?
I can’t imagine you do, because it would be impossible to re-enable it
– the device would go away once the USB power is removed.
Do you hear the “bing bong” and “bong bing” tones that indicate a USB device
being re-enumerated?

The device driver used is WinUSB and yes, if I disable and re-enable the device in the Device Manager, the power will also be cycled during the re-enabling, including the sound.
The sound is also produced with the ‘devcon restart’ command.
I find it hard to believe that WinUSB does this power cycling, where this function is not offered in the WinUSB API.
Not that I could really use it, as the application that I would need it for uses externally powered devices, and the power cycle does not work there.

Regards, Matt

This was well-answered by Vivek Gupta in a blog post, so I’ll just point you to that. The summary is that D3cold itself isn’t defined in USB. ACPI is used to lay that concept over top of USB, and thus it can only be supported on ports integrated into the machine, not external hubs, and certainly not ones which don’t have individual control over port power.

The post is the first hit in this search. (Sorry for posting search terms. I do it not because I’m didactically trying to say that you could have searched yourself, but rather because MSDN invalidates all their links so often that direct links aren’t durable for the archives.)

http://www.bing.com/search?q=Windows+8+supports+a+new+device+power+state+called+the+D3cold+state.+Adopting+D3cold+for+USB+presents+some+unique+challenges+for+USB+devices+and+drivers.+In+this+blog+post%2C+I+will+talk+about+those+challenges+and+certain+restrictions.+&qs=n&form=QBRE&pq=windows+8+supports+a+new+device+power+state+called+the+d3cold+state.+adopting+d3cold+for+usb+presents+some+unique+challenges+for+usb+devices+and+drivers.+in+this+blog+post%2C+i+will+talk+about+those+challenges+and+certain+restrictions.+&sc=0-0&sp=-1&sk=&cvid=7aed71e98bbc44fb8a16012b99e29d78

  • Jake Oshins
    Windows Kernel Team

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, January 9, 2014 8:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB Reset for DFU with WINUSB

Jake,

What does D3Cold mean in the context of USB? Does it mean that the ClearPortFeature (PORT_POWER) command is issued to a device’s parent port? What about gang powered hubs? (I’m looking at section 10.12 of the 3.1 spec). Also, for 2.0 devices, if Vbus isn’t there, a device cannot assert its pullup resistor on D+.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer