How to re-enter USB DFU mode after a firmware update?

[Kemalele]

Hello,

I am using Zephyr with MCUboot to manage firmware updates on my device, utilizing the Zephyr USB DFU application for the update process. After a firmware update, I need to re-enter DFU mode so that I can continue using dfu-util to apply further updates or perform recovery actions.

My question is: How can I configure MCUboot or Zephyr to trigger USB DFU mode after a firmware update, especially after the device has booted into the updated application? I am looking for guidance on how to achieve this flow for future updates, where the device needs to return to DFU mode post-update.

Are there any built-in mechanisms or best practices within MCUboot or Zephyr that facilitate re-entering USB DFU mode for subsequent updates or recovery scenarios?

Any pointers or solutions would be greatly appreciated!

[de-nordic]

This is not a topic for an issue. Converting to discussion.

[JPHutchins]

I've found that USB DFU is not well supported, including by Windows. Therefore, I've moved on to depending on SMP for DFU, including over USB, from either MCUBoot or the application.

I'm assuming that you only have a single application slot if you are doing DFU from within MCUBoot instead of the application, correct me if I'm wrong.

To answer your question, it sounds like you want to have a software mechanism to enter MCUBoot from the application? If that is the case, then I would recommend looking at using bootmode_set(), sys_reboot(SYS_REBOOT_WARM), and these kconfigs:

CONFIG_RETAINED_MEM=y
CONFIG_RETENTION=y
CONFIG_RETENTION_BOOT_MODE=y
CONFIG_REBOOT=y

https://docs.zephyrproject.org/latest/services/retention/index.html

[Kemalele]

Thank you so much for your response! I just wanted to clarify my situation. I’m currently following the Zephyr USB DFU 1.1 application example using dfu-util as described in the Zephyr documentation.

My goal is to replicate exactly what is shown in the example, but after uploading an application (for now, I’m using a Zephyr-based application for simplicity), I’m unable to return to USB DFU app.

I’ve been thinking about the issue, and I wonder if I might need to move to the address of the USB DFU application in my app. Additionally, I came across the multi-application mechanism described in the MCUboot documentation, which involves adding new slots in the DTS file.

Would it be necessary to use this mechanism for my setup, or would it be sufficient to stick with the standard approach for handling the USB DFU 1.1 application?

I would greatly appreciate any insights you might have on this matter.

[JPHutchins]

Thanks for the clarifications!

Sounds like you're using bootloader + dual application slot, correct me if I'm wrong.

If I am understanding that sample correctly, it performs the DFU from the present application slot, not from the bootloader. Therefore, when you follow the instructions to flash the hello_world app, USB DFU will no longer be available because that app does not have USB DFU.

Instead of flashing an entirely different app, flash some variant of your USB DFU app wherein you can confirm that the app is different. I would suggest changing the PID by one, as we do for testing smpclient USB FW updates.

I don't recommend using USB DFU.

[JPHutchins]

Another clarification: your apps must contain the USB DFU functionality.

[Kemalele]

Thank you for detailed response! It made the behavior much clearer to me now