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, 

Unfortunately there isn't a solution for now. 
There is some discussion here that cover the topic: nRF5340 bootloader with BLE transport 

In short, it's possible to make some modification to MCUBoot to make it does BLE recovery but it's not something we have and you will have to implement it on your own. 

[vinodsdw]

Got it, so we will have to develop it ourselves.

Okay, a simple example bug:

 Say, the application is working fine for now and we are writing some data or configuration to an external eeprom. Due a wrong data written into eeprom, the configuration gone wrong and the chip is getting restarted in a loop. In this case, since we are dependent on the existing running application for future firmware update, the device can be considered as bricked or unrecoverable. So there are possibilities for future bugs depending on the data saved in eeprom, runtime configuration modification etc.

So a FOOLPROOF DFU can only be considered as 100% safe and recoverable 

So Nordic  should seriously consider something like this for the nrf5340.

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