nrf5340 how to forcefully enter into DFU mode if a buggy APP is loaded via DFU ?

[vinodsdw]

How can we forcefully enter into DFU mode in NRF5340 if for example the newly loaded application due to a bug is unable to advertise BLE?
In another words, if I press reset button, I want the device to be in DFU mode for at least 10 seconds so that I can recover the  device in case if the application crashes.

At present the DFU bootloader is a standalone bootloader with BLE capability or is jt just a switcher which jumps to the application downloaded new image partition?

[Hung Bui]

Hi Vinod,

The DFU process on NCS is a background DFU process. This means the application need to run for the device to receive the new image. 
So there is no way that you can "enter DFU mode and wait for BLE connection for 15 seconds" . The bootloader (MCUBoot) can't receive image via BLE. 

The challenge here is that if you want such feature you would need to integrate BLE into MCUboot which make the size of MCUBoot much larger. 

What we have is a "serial recovery mode" that you can integrate into MCUBoot, so that you can press and hold a button and it will enter DFU mode and wait for a new image on the UART line not BLE. You can take a look here: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery

[vinodsdw]

In that case it seems to be very bad idea to depend on existing application to update the device.

Because in future if a nasty bug prevents the BLE to work , then the device is bricked and there is no UART option in the device because it is completely closed product.

We have worked on nrf52832 and nrf52820 (not zerphyr, but old style with IAR) where we slightly customized the existing BLE bootloader to do this 15 seconds DFU mode while pressing a button and at same time plugging on charger. This is our recovery mode. 

So such features cannot be implemented as of now with this MCUboot right ? Then its a serious issue :)

--

Also from my use case point of view, two partition is not really mandatory, instead I can give even 300KB for a BLE bootloader and the firmware download to the same application area should be done inside the mcuboot so that it is safe and always there is a backdoor for a firmware update, irrespective of any future wrong update.

--

Also I would like to know if there is any non-zephyr simple BLE bootloader sample for nrf5340 ?

If so I can use that as a primary immutable  BLE bootloader and I can disable mcuboot in the application and can shift the application start with the appropriate offset somewhere in the linker. Is any such sample or anything is available similar to those older nrf52832/40 bootloaders ?

[vinodsdw]

But if I am using nrfconnect app and if I connect to the device via ble, it detects there is a DFU service inside the device. If that service is there, then definitely nrfconnect is sending data via that service for firmware udpate right ? In that case why can't I peek into that data to detect dfu is happening or not ?

[Hung Bui]

Hi Vinod, 

If in nRF Connect the user click on DFU -> select the file -> Click start DFU, then in your app you can detect that there is a DFU process started. 

If the end user doesn't click Start (or take a long time to select the file for example) then you don't have any event in the nRF52 until the end user click Start. 

[vinodsdw]

Hello,

   That is fine, I can add something like that. But if we do DFU from own custom app, then we won't be selecting it like a file. Instead it will happen automatically based on the file from server.

But still I should be able to see the data transfer in that SMP server service right ?

Or is that not possible ? 

[Hung Bui]

Hi Vinod, 

Correct, as long as the DFU process started you will be able to get an event. 
I haven't looked into the code yet, but it's not like a black box, it's integrated to application so you should be able to add some hook or something to get a notification (usually it's needed for the firmware to show end user that a DFU is in progress and maybe show the progress , % for example, with LCD or LED). 

I would suggest to take a look inside the files in \zephyr\subsys\mgmt\mcumgr\transport\src folder, smp_bt.c for example. 

[vinodsdw]

Sure, thanks for the information. I will check the smp_bt.c file.