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 ?

[Hung Bui]

Hi Vinod, 
I understand your concern. Unfortunately that's the situation we have now. 

You may consider setting a special mode in your application that does exactly what you want with the DFU failsafe mode. It will boot up and do nothing but advertise and wait for DFU connection. After 15 seconds it would start doing the normal routine to read eeprom and other normal function. 

This way you can do some intensive test on the application to make sure it will manage to do the DFU basic task and avoid accessing any other function/peripheral. 
I agree that this is still not as robust as having a separate application (bootloader) , but other than that and the serial recovery mode, I don't find any better solution. 

[vinodsdw]

Yes,

   I was also thinking about the same idea to not initialize any other task for 15 to 20 seconds other than the BLE task. Then no matter what ever happens, if that initial part of code logic is not changed, it should technically work at least for the first 20 seconds on a button reset.

Anyways thanks for your comments and suggestion. 

[vinodsdw]

Hello Hung,

  I have one more question regarding this,

I am now keeping the BLE task  as the first code in my main.

After that I will wait for a semaphore for 20 seconds, if mobile app is connected and started the SMP firmware download, then I will get semaphore before 20 seconds and if semaphore timeout, then I will continue my application code below that.

But how can I know if the BLE connection is really for DFU or normal app connection?

Means if someone press the DFU button in nrfconnect app and select the zip, can I get a callback in my application regarding that ? If so then I can release a semaphore to the indicate that DFU started. Then I can keep a very high delay before entering into application code assuming that the DFU itselft will reset the MCU before that happens.

[Hung Bui]

Hi Vinod, 

No, I don't think nRFConnect would send any Ping. 

But if you use nRF Device Manager  you can send an Echo command. You can use that to tell your application that it's entering DFU mode. I assume that you will write your own app to do DFU ? 

Another option is to make your own characteristic that handles the "enter DFU - don't do anything else" command. 

[vinodsdw]

Another approach can be to go inside the attribute modified callback of the SMP characteristics to see if any communication or sync word exchange is happening, if so then that triggers an OTA. What do you say?

[Hung Bui]

Hi Vinod, 
I don't think nRF Connect would do anything except for doing service discovery which cause no call back.  If you are making your own app to do DFU, then you can do that, enable notification and send a "Ping"/echo package. 

[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.