USB DFU Usage #64767
-
|
At Intercreate, we've found that in order to use the USB DFU system, via Here's the patch: diff --git a/subsys/usb/device/class/dfu/usb_dfu.c b/subsys/usb/device/class/dfu/usb_dfu.c
index 69a912ab9d..b816accd91 100644
--- a/subsys/usb/device/class/dfu/usb_dfu.c
+++ b/subsys/usb/device/class/dfu/usb_dfu.c
@@ -119,7 +119,7 @@ USBD_CLASS_DESCR_DEFINE(primary, 0) struct usb_dfu_config dfu_cfg = {
.bNumEndpoints = 0,
.bInterfaceClass = USB_BCC_APPLICATION,
.bInterfaceSubClass = DFU_SUBCLASS,
- .bInterfaceProtocol = DFU_RT_PROTOCOL,
+ .bInterfaceProtocol = DFU_MODE_PROTOCOL,
.iInterface = 0,
},
.dfu_descr = {
@@ -336,7 +336,7 @@ struct dfu_data_t {
static struct dfu_data_t dfu_data = {
- .state = appIDLE,
+ .state = dfuIDLE,
.status = statusOK,
.flash_area_id = DOWNLOAD_FLASH_AREA_ID,
.alt_setting = 0,With this patch, We have a few other fixes to submit for USB DFU and MCUBoot, but hoping to have a good discussion about the design goals and API first. We've run this on dev kits and custom boards with parts from ST and Nordic and never had success WITHOUT this patch. I think that it comes down to usage of CONFIG_USB_DFU_WILL_DETACH What I don't understand is what "DFU_WILL_DETACH" means? Does it mean that the device will reset (wouldn't work) or something else? Open issues: Closed issues:
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 7 replies
-
|
Hi @JPHutchins! We appreciate you submitting your first issue for our open-source project. 🌟 Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙 |
Beta Was this translation helpful? Give feedback.
-
Reconfiguration, switching from runtime to DFU mode is part of "four distinct phases" described in USB DFU specification. If it does not work, there is probably a problem with your host OS driver. TBH I am not sure if starting in runtime mode is necessary requirement form the spec but behavior of DFU implementation is not limited to your specific use case.
It does what is described in the option help, for more info see USB DFU spec and discussion in #49821. |
Beta Was this translation helpful? Give feedback.
-
|
@jfischer-no thank you! From these threads I see 2 areas to investigate:
Cheers, |
Beta Was this translation helpful? Give feedback.
-
|
@jfischer-no Going to continue taking notes here for reference. Initial results from within Windows, with the patch discussed in place
Windows dfu-util run: Success! Now to test after removing the patch; that is, initialize USB DFU in Windows, dfu-util 0.11: Hangs here forever. Attaching with debugger shows that Zephyr is still running without crash. Note the lines: that were not present in the patched version. This makes sense and seems to show that the system is properly negotiating the detach/attach (AKA re-enumeration?) successfully. Before stepping through to see why it's not transferring I will test in WSL2. dfu-util 0.9 in Ubuntu 22.04: Seems to have the same problem. Building with Didn't make a difference still stalls without transferring. Running At commit: dfu-util, Ubuntu, after west update, CONFIG_USB_DFU_WILL_DETACH=n: dmesg: Going to try with CONFIG_USB_DFU_WILL_DETACH=y since that's the desired setting anyway. Now, dmesg reports nothing - probably asserted with that that Nordic mutex from interrupt bug. Progress though... Yep, it's the mutex_lock from usb_dc_detach in usb_dc_nrfx.c. Will cherry pick the fix real quick. Fix is here: #53414 OK, well the result is the same, except no assert. That is dmesg doesn't show any activity when Stepping starting at the Trying at the work schedule call. Breakpoint is hit, timeout is set to 100 as expected from KConfigs. Perhaps I am misunderstanding the state setting, checking for break at the top of the work handler. Work handler is not called... Hmm, usb_work_q.h is interesting: #ifdef CONFIG_USB_WORKQUEUE
extern struct k_work_q z_usb_work_q;
#define USB_WORK_Q z_usb_work_q
#else
#define USB_WORK_Q k_sys_work_q
#endifSo let's enable that and see if the delayable work works. dmesg does do the reset now! Since we're forwarding to WSL I'm adding dfu-util waits but still does not find the device. In dmesg we can see a problem: Device PID initially: On reattach: I will consider a PR to add a compile time assert to check that USB_DEVICE_DFU_PID != 0xffff since this is a silly time sink for engineers: Will come back to this later with more notes. |
Beta Was this translation helpful? Give feedback.
-
|
Continuing on NCS v2.5-branch with an nRF52840-DK, using this example: https://docs.zephyrproject.org/latest/samples/subsys/usb/dfu/README.html DFU sample boots: enumerates dfu capable dfu-util fails It did not re attach to WSL2 because on the detach it re enumerates as a device that had not been yet selected for forwarding. Trying again - succeeds, but was already in appIdle. Success! Device detaches and re attaches, is forwarded to WSL, and upgrade completes: I will add USB CDC ACM to the DFU sample to validate that it is working as expected. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I have modified the USB DFU sample to enable console and shell. We can see that the sample still records MCUBoot logs via the JLink serial interface: And we now have uart console on the USB CDC ACM (separate terminal window): Here's the git diff to enable that, pluse the app.overlay to add to the folder: diff --git a/samples/subsys/usb/dfu/prj.conf b/samples/subsys/usb/dfu/prj.conf
index c6a84a554b..3230ed3aa8 100644
--- a/samples/subsys/usb/dfu/prj.conf
+++ b/samples/subsys/usb/dfu/prj.conf
@@ -1,7 +1,7 @@
CONFIG_STDOUT_CONSOLE=y
CONFIG_GPIO=y
CONFIG_USB_DEVICE_STACK=y
-CONFIG_USB_DEVICE_PRODUCT="Zephyr DFU sample"
+CONFIG_USB_DEVICE_PRODUCT="Zephyr DFU CDC composite"
CONFIG_USB_DEVICE_PID=0x0005
CONFIG_USB_DFU_CLASS=y
CONFIG_USB_DFU_ENABLE_UPLOAD=y
@@ -15,3 +15,14 @@ CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n
+
+CONFIG_SERIAL=y
+CONFIG_UART_INTERRUPT_DRIVEN=y
+CONFIG_UART_LINE_CTRL=y
+
+CONFIG_USB_DEVICE_STACK=y
+CONFIG_USB_CDC_ACM_RINGBUF_SIZE=512
+
+CONFIG_SHELL=y
+CONFIG_SHELL_BACKEND_SERIAL=y
+CONFIG_SHELL_BACKENDS=y
Got device lost again, checking USB forwarding Device is there with USB: Dfu completes on 2nd try because it was already in dfuIdle Assuming that dfu-util is not waiting long enough after the detach, adding 10 second wait and we get success! Having validated that USB CDC USB DFU composite is working on nRF52840 DK I will move back to the custom HW! |
Beta Was this translation helpful? Give feedback.
-
So can this be closed? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah. We are abandoning USB DFU entirely in favor of SMP over USB for FW updates for single slot and dual slot, from app or from MCUBoot. |
Beta Was this translation helpful? Give feedback.
Yeah. We are abandoning USB DFU entirely in favor of SMP over USB for FW updates for single slot and dual slot, from app or from MCUBoot.