usb: dfu: Support DFU with WinUSB on Windows

[desowin]

Fix https://github.com/zephyrproject-rtos/zephyr/issues/49821 by implementing and enabling DFU bitWillDetach by default.

Tested using nRF52840 Development Kit on Linux and Windows host with dfu-util 0.11.

[jalinei]

I tried it on Linux today. dfu-util -v -a 1 -D firmware.signed.bin returns

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2fe3:0101
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Device will detach and reattach...
dfu-util: Lost device after RESET?

[desowin]

@Light411 on what target does it fail?

[jalinei]

Sorry for the lack of infos : Test target is stm32G474 Zephyr 3.1 The problem might be that on ST platform the device does not properly re-enumerate ?

I've tried implementing the feature myself yesterday, but I was facing the same dfu-util: Lost device after RESET? issue.

[desowin]

Sorry for the lack of infos : Test target is stm32G474 Zephyr 3.1 The problem might be that on ST platform the device does not properly re-enumerate ?

The problem is that ST USB device driver does not implement usb_dc_detach() so the device does not detach at all... https://github.com/zephyrproject-rtos/zephyr/blob/b11ba9ddc8939f40a95b480220138f46efd0397d/drivers/usb/device/usb_dc_stm32.c#L996

[carlescufi]

Sorry for the lack of infos : Test target is stm32G474 Zephyr 3.1 The problem might be that on ST platform the device does not properly re-enumerate ?

The problem is that ST USB device driver does not implement usb_dc_detach() so the device does not detach at all...

https://github.com/zephyrproject-rtos/zephyr/blob/b11ba9ddc8939f40a95b480220138f46efd0397d/drivers/usb/device/usb_dc_stm32.c#L996

@erwango is this something you could take a look at?

[jalinei]

This "Not implemented" issue is about to get fixed by #36848 it is at stale because of some part of the PR that is not generic enough to cover all STM32 families. Upfront of the tests of the present PR, I've cherry-picked most of #36848 to implement the usb_dc_detach. Detach seems to work okay, but somehow it the device does not attach back properly or the host is not catching it..

[desowin]

Upfront of the tests of the present PR, I've cherry-picked most of #36848 to implement the usb_dc_detach. Detach seems to work okay, but somehow it the device does not attach back properly or the host is not catching it..

This sounds like a problem in the ST USB driver. You can try adding (very rough) k_sleep(K_MSEC(1000)); before usb_dc_attach() in dfu_timer_expired() to see if it is some timing issue.

[erwango]

This "Not implemented" issue is about to get fixed by #36848 it is at stale because of some part of the PR that is not generic enough to cover all STM32 families. Upfront of the tests of the present PR, I've cherry-picked most of #36848 to implement the usb_dc_detach. Detach seems to work okay, but somehow it the device does not attach back properly or the host is not catching it..

Please open a dedicated issue.

[desowin]

Please open a new bug report regarding usb_dc_detach() implementation and move the first commit to own PR.

Why move the nRF commit to own PR? I don't see a point in such a move. The commit ordering is quite important for bisection, so it would need to be PR dependency.

[desowin]

Why move the nRF commit to own PR? I don't see a point in such a move. The commit ordering is quite important for bisection, so it would need to be PR dependency.

The point is ongoing release. I have opened the #50475 with the nRF driver fix that is supposed to go into 3.2.0 release, whereas the DFU change (this PR) is for the next release.

[desowin]

@nandojve I just checked that this does not work as expected on sam_v71b_xult board. Could you please take a look at it?

[nandojve]

@nandojve I just checked that this does not work as expected on sam_v71b_xult board. Could you please take a look at it?

Hi @desowin, Would you mind to be more specific?

[desowin]

Would you mind to be more specific?

The device fails to re-enumerate on the bus after detach.

Opening DFU capable USB device...
Device ID 2fe3:0005
Device DFU version 0110
Claiming USB DFU (Run-Time) Interface...
Setting Alternate Interface zero...
Determining device status...
DFU state(0) = appIDLE, status(0) = No error condition is present
Device really in Run-Time Mode, send DFU detach request...
Device will detach and reattach...
dfu-util: Lost device after RESET?

With OpenVizsla, I was able to observe that sam_v71b_xult does reattach to the bus but does not reply to GET DEVICE DESCRIPTOR and SET ADDRESS control transfers. Just setting USBHS_DEVCTRL_DETACH and clearing the USBHS_DEVCTRL_ADDEN in usb_dc_detach() does not resolve the issue.