NRF52840 BLE DFU: Application settings

[Chris_Dev]

Hi,

I have a question regarding a DFU update via BLE. I am using mesh sdk v3.20 and sdk v15.30 with custom hardware (nrf52840).

I have the BLE DFU working as expected.

What I would like to know is when you create your firmware package, should you merge your application + application settings or is only the application sufficient? It makes more sense to me to include the application + application settings in your firmware package! When I include both the application and settings, while trying to do a DFU update I get the error "INSUFFICIENT RESOURCES":/ 

Please let me know if I am not being clear on this question.

Thanks in advance:)

Regards

Chris

[Hung Bui]

Hi Chris, 

Could you clarify what exactly you meant by "application setting" ?  

Did you mean "bootloader setting"? If you did then it shouldn't be included in the DFU package. 

[Chris_Dev]

Hi Hung, yes sorry, I meant the bootloader settings:) I have used this tutorial:

https://github.com/gamnes/nRF52832-buttonless-dfu-development-tutorial

So when you generate the settings, you make use of your application hex file with the following command:

nrfutil settings generate --family NRF52840 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex

These settings depend on your application right? So if your application changes, this file will change as well? Or am I wrong...

The other thing that I'm thinking about is the provisioning data. So if I want to do a DFU update with the following scenario:

1. Current version: 2 generic on/off server models on 2 different elements

2. New version to update via DFU: 4 generic on/off server models on 4 different elements

In this case I will have to reprovision the device? Am I wrong? How would you specify if the provisioned data on the node under DFU update should erase or keep it's provisioning data? If you would like me to rather open up a new ticket for this I would be happy to do so!

[Hung Bui]

Hi Chris, 

You are correct the bootloader setting contains information about the application. However, it's only for the first time programming the chip. On a DFU update where the application changes, the bootloader should be automatically generate bootloader setting that fit with the new application. Think of generating the bootloader setting manually and flashing it is a way of tricking the bootloader to think that it has just done a normal DFU. 

Regarding your question, if you change the composition data, the flash module may not work properly. It's better to erase the data and start fresh. I'm not so sure our current flash library can handle this automatically. Most likely you would need to write the code to detect the flash error and erase the flash in the application code. 

[Chris_Dev]

Hi Hung, awesome!

Thank you so much for reply, you cleared it up well:) 

[Chris_Dev]

Hi Hung, just wanted to let you know that I tested a DFU with different composition data. The composition data is reset automatically and the device is set to an un-provisioned state. So I believe that this is handled correctly.