nordicjm
commented
2 years ago Issue also observed on nrf52833-based module and stm32f103-based module. Some old discussions on github mentioning this issue from 2+ years ago
Closed jalinei closed 2 years ago
nordicjm
commented
2 years ago Issue also observed on nrf52833-based module and stm32f103-based module. Some old discussions on github mentioning this issue from 2+ years ago
jfischer-no
commented
2 years ago Issue also observed on nrf52833-based module and stm32f103-based module.
You can reproduce it on nRF52833DK?
jfischer-no
commented
2 years ago @Light411 Since you opened it here, can you reproduce the issue using Zephyr's sample samples/subsys/usb/dfu?
nordicjm
commented
2 years ago Issue also observed on nrf52833-based module and stm32f103-based module.
You can reproduce it on nRF52833DK?
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.
jfischer-no
commented
2 years ago 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 do not get to test it until week 38.
jalinei
commented
2 years ago 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. More specifically, I was able to populate my descriptors, but I wasn't able to understand how to handle these descriptors to the usb enabling function. Do you think it could work ?
jfischer-no
commented
2 years ago 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. More specifically, I was able to populate my descriptors, but I wasn't able to understand how to handle these descriptors to the usb enabling function. Do you think it could work ?
If it is about Microsoft OS * Descriptors, please take a look at samples/subsys/usb/webusb (for example msos1_compatid_descriptor).
jalinei
commented
2 years ago I found two implementation of MS OS descriptors available in Zephyr
CONFIG_USB_DEVICE_OS_DESC which from my understanding is only capable of MS OS descriptor V1 and is focused on WCID feature.
CONFIG_USB_DEVICE_BOS which from my understanding is capable of the extended features offered by MS OS descriptor V2 that I indeed found in the very useful webusb sample.
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 CONFIG_USB_DEVICE_OS_DESC seems to be used only by subsys/usb/device/class/netusb and by a test tests/subsys/usb/os_desc.
I tried to implement it to check the feasibility but I didn't manage, I was not able to pass the descriptor to my usb_enable() function.
My main question here is : Would this fix the problem for windows users ? Second one : Is LibusbK supported by WCID ? Last one : How do vendor bootloaders and dfu compatible boards / device supports Windows in a plug and play fashion ? Using WCID + WinUsb or any other driver ? Or implementing custom drivers and linking them to their VID:PID ?
PS I found this great documentation on WCID: https://github.com/pbatard/libwdi/wiki/WCID-Devices
desowin
commented
2 years ago I tried using libusbK this afternoon, and I managed to download the image sucessfully on Windows !
This is expected due to the actual root cause of the issue. WinUSB does not support host initiated USB bus resets, while libusbK does.
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 think adjusting Zephyr for WinUSB limitations is better. USB Device Firmware Upgrade Specification, Revision 1.1 specifies:
Bit 3: device will perform a bus detach-attach sequence when it receives a DFU_DETACH request. The host must not issue a USB Reset. (bitWillDetach) 0 = no 1 = yes
Zephyr sets bitWillDetach to 0 and hence DFU does not work with WinUSB, but does with libusbK. To have WinUSB compatible DFU implementation, device have to set bitWillDetach to 1 and perform the bus detach-attach sequence.
Second one : Is LibusbK supported by WCID ?
It can be supported if user (application explicitly run by user) installs the libusbK drivers before the device is plugged in.
Last one : How do vendor bootloaders and dfu compatible boards / device supports Windows in a plug and play fashion ? Using WCID + WinUsb or any other driver ? Or implementing custom drivers and linking them to their VID:PID ?
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).
jfischer-no
commented
2 years ago Zephyr sets
bitWillDetachto 0 and hence DFU does not work with WinUSB, but does with libusbK.
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.
desowin
commented
2 years ago Zephyr sets
bitWillDetachto 0 and hence DFU does not work with WinUSB, but does with libusbK.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 bitWillDetach is 0, it is impossible to write host user-space software (dfu-util or equivalent) that would handle the device (with bitWillDetach set to 0) when WinUSB driver is used (the only possibility for DFU with WinUSB driver is when bitWillDetach is set to 1, as host initiates resets are not required). DFU can implemented regardless bitWillDetach state with libusbK driver as libusbK provides necessary API.
jfischer-no
commented
2 years ago 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.
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.
desowin
commented
2 years ago 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.
Well it would be easier if they just write that there is no API for it instead of placing dead links in the code.
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:
/*
* 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)
*/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.
Anyway, limitations of WinUSB do not seem to be a bug in Zephyr to me.
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.
jalinei
commented
2 years ago 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. Dfu-util is quite standard, it should be working on windows as well, no matter if the flaw is in WinUsb.. WCID and this fix will provide the ergonomics expected and needed for most.
jfischer-no
commented
2 years ago WCID and this fix will provide the ergonomics expected and needed for most.
Again, it is not a bug in Zephyr and therefore not a fix and has to wait until release is finished.
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