Enabling multiple firmware/application updates on NRF5340 DK board using DFU feature

[Utsav R Shah]

Hello community,

I am trying to do an application / firmware update to the NEF5340 DK board using the DFU application 

Here are the steps that I am following:

1. First, I compile the DFU sample program given at zephyr/samples/subsys/usb/dfu.

The program compiles and then I flash the app_update.bin file generated in /build/zephyr directory onto the NRF5340DK board.

Now I build the hci_usb application present at /zephyr/samples/bluetooth/hci_usb.

What I did here is I copied the contents of the prj.conf file of the usb dfu application to the prj.conf file of the hci_usb application : 

In the above image you can see I have added the USB DFU application flags in the config files of the hic_usb application. I then build the hci_usb application.

After building the application I get the app_update.bin file in /build/zephyr folder. 

I now flash this this app_update.bin file using the dfu-util and it is successful. Yo can see the screenshot below:

Since I have enabled the USB DFU config flags in HCI_USB program as well. I can still see the device in the list of USB devices connected with the custom name that I have given. Check the screenshot below:

Now when I try to upload any firmware file using dfu-util I get the following error "cannot claim interface 1"

Essentially what I want to do is have the ability to upload another firmware using DFU when an existing firmware is running. How do I automatically bring the board back to DFU mode when an application is already running?  I don't want to reset the board manually to bring it to DFU again. 

Let's say a I flashed a blink program using dfu-util application. Now while the blink program runs, I dont have a way to get back to DFU mode if I need to flash another firmware again. How do I do this automatically? Do I need to make any changes in the MCUboot bootloader?

[Vidar Berg]

Hello,

I would consider using Serial recovery DFU for this. This appraoch would allow you to perform DFU within the bootloader. This eliminates the necessity to include the DFU USB device class in your application. The only remaining step is to enable the application to reset into the bootloader. You can likely introduce a custom vendor-specific HCI command to trigger a soft reset. To detect this command, the application core will need to intercept HCI traffic.

Best regards,

Vidar