USB DFU implementation does not work with WinUSB because of missing device reset API #49821
Comments
|
Issue also observed on nrf52833-based module and stm32f103-based module. Some old discussions on github mentioning this issue from 2+ years ago |
henrikbrixandersen
added
area: USB
jfischer-no
added
priority: low
You can reproduce it on nRF52833DK? |
|
@Light411 Since you opened it here, can you reproduce the issue using Zephyr's sample |
BL653 DVK which is the same hardware/interface wise as nRF52833dk. After having more of a play with it, it seems to be the winusb driver, I tried installing the libusbK drivers using zadig instead, and after installing the libusbK package with system drivers, suddenly dfu-util can communicate with the device on windows. So it's a far cry faff from the ability to do a mcuboot serial recovery update with just a single executable and no drivers to needing the libusbK driver, libusbK system drivers and an executable for this. Perhaps this should be added to the documentation. |
I agree that "mcuboot serial recovery update" is much easier to use for Windows OS users. I have no measurements regarding throughput but remember that USB DFU was faster. |
|
I tried using libusbK this afternoon, and I managed to download the image sucessfully on Windows ! IMO the best fix here would be to include the windows descriptor in ucb_dfu.c file so that Windows natively load libusbK driver for the given run-time and dfu mode VID:PID. I've seen that windows descriptors are already in tree. I tried implementing them to try my luck implementing a WCID feature for my device but I was not able to make it work. |
If it is about Microsoft OS * Descriptors, please take a look at samples/subsys/usb/webusb (for example msos1_compatid_descriptor). |
|
I found two implementation of MS OS descriptors available in Zephyr I was thinking that the first one was more suitable for the task as usb_dfu.c only need to provide the descriptors needed for the WCID feature. Also from what I read, WCID has been deployed in 2012 while BOS v2 is more recent and would let older versions of windows aside of the support. At the moment My main question here is : Would this fix the problem for windows users ? PS I found this great documentation on WCID: https://github.com/pbatard/libwdi/wiki/WCID-Devices |
This is expected due to the actual root cause of the issue. WinUSB does not support host initiated USB bus resets, while libusbK does.
I think adjusting Zephyr for WinUSB limitations is better. USB Device Firmware Upgrade Specification, Revision 1.1 specifies: Zephyr sets
It can be supported if user (application explicitly run by user) installs the libusbK drivers before the device is plugged in.
A lot of different approaches. Some use custom drivers, some use even custom vendor defined protocols. In my opinion using WCID + WinUSB together with USB DFU class is the most cost effective solution (i.e. least amount of effort required both in development and maintenance). |
That does not explain why it does not work. There is comment about it, https://github.com/libusb/libusb/wiki/Windows#Known_Restrictions, outdated explanation can be found in the source code https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L3184-L3191, below there is comment about libusbK, but still no background explanation. |
What do by mean by "background explanation"? Regarding the WinUSB limitation it is pretty hard to come up with a link to something that does not exist. The winusb.h header documentation lists the API provided by WinUSB. The API does not include host initiated USB reset function. Therefore, it is impossible for any user space application that uses WinUSB driver to issue host initiated USB reset. Because USB Device Firmware Upgrade Specification, Revision 1.1 requires host initiated resets when |
Well it would be easier if they just write that there is no API for it instead of placing dead links in the code. Anyway, limitations of WinUSB do not seem to be a bug in Zephyr to me. |
Nobody placed dead links in the code. It is just how internet works, the links do become dead over time. So will the links placed in Zephyr code/documentation, especially the ones that point to latest version and not some specific version. This is why besides just a link, there should be enough context for the future reader. If the comment you are referring to is what you linked earlier then the author did all they could do to provide enough context, that is: The "WinUSB does not support host-initiated reset port and cycle port operations" is basically saying there is no API for it. It also provides really good context for people familiar with Windows development that there is basically no hope to implement host initiated reset in user-space.
Then consider WinUSB compatibility as a feature. It is just a taxonomy. The thing is, that the end-user quite often does not make the distinction and instead reports that something does not work and considers this to be a bug. It is easy to notice that something does not work as expected, but it is hard to tell what is the root cause (because otherwise the reporter would just fix the root cause in the first place instead of going through the trouble of reporting). The average user that buys any peripheral that runs Zephyr and uses USB DFU is likely to use Windows to update the firmware, as Windows currently has about 74% desktop market share. The end user expects the manufacturer to provide working software package that can update the firmware. The lowest maintenance solution is USB DFU with WinUSB WCID descriptors, as it eliminates the driver development, signing and installation problem completely. |
jfischer-no
added
Feature Request
jfischer-no
changed the title
DFU on Windows with WinUSB driver failed with "Lost device after RESET?" error because WinUSB does not support host initiated resets. USB Device Firmware Upgrade Specification Revision 1.1 attribute bitWillDetach can be used to overcome WinUSB reset limitation. When bitWillDetach is set, it is the device responsibility to detach and reattach itself to the bus after receiving DFU_DETACH request. Add and enable by default USB_DFU_WILL_DETACH configuration option, because it is the only way to support WinUSB driver. WinUSB driver is preferable because it can be automatically installed on Windows 8 and later if USB device implements WCID descriptors. Fixes: zephyrproject-rtos#49821 Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
|
I agree with @desowin. Microsoft has its flaws for sure, but non-expert users will be mostly working on this OS. Figuring out what's causing download issue with dfu-util is out of reach for these people. |
Again, it is not a bug in Zephyr and therefore not a fix and has to wait until release is finished. |
DFU on Windows with WinUSB driver failed with "Lost device after RESET?" error because WinUSB does not support host initiated resets. USB Device Firmware Upgrade Specification Revision 1.1 attribute bitWillDetach can be used to overcome WinUSB reset limitation. When bitWillDetach is set, it is the device responsibility to detach and reattach itself to the bus after receiving DFU_DETACH request. Add and enable by default USB_DFU_WILL_DETACH configuration option, because it is the only way to support WinUSB driver. WinUSB driver is preferable because it can be automatically installed on Windows 8 and later if USB device implements WCID descriptors. Fixes: #49821 Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
stephanosio
changed the title
Describe the bug
When uploading a signed image using dfu-util on windows, the transfers fails and output "Lost device after RESET ?".
From what I understood I'm not the only one facing this issue, It has been discussed on Discord both on the general channel but also on the MCUBOOT one.
The SoC I'm using is stm32g474re, but it seems to also affect other vendors.
USB DFU works flawlessly on Linux I'm only experiencing the issue on Windows.
What I tried :
To Reproduce
Prj.conf relevant configuration is
I used Zadig v2.7 to load WinUSB v6.1 driver on MCUBOOT run-time dfu (2fe3:0101).
Expected behavior
Dfu-util is supposed to be able to reset the USB from run-time to transfer mode.
Impact
The project we are working on aims at having end users able to download binaries to the board using dfu-util. Most users are using Windows and this issue is a showstopper for us.
Logs and console output
When listing the DFU capable USB device, we already see that it fails at enumerating correctly.
When flashing it gives
In triple verbosity I get the following :
Environment (please complete the following information):
Additional context
Not much more to add AFAIK
The text was updated successfully, but these errors were encountered: