How to generate a Bootloader + Softdevice + Application zip for OTA updates/DFU.

[Mr Sunshine]

Hello,

For OTA updates or DFU I want to create a zip file that contains the Bootloader, Softdevice, and Application into one, But when I generate this through nrfutil.exe and update it with the nRF Toolbox I only see that the application is updating. When updating the screen of the application starts at 2/2, so I assume that the bootloader and softdevice are skipped.

For more information I use the nRF52832 chip and I use the SDK 15.0.0. version (which uses the s132_nrf52_6.0.0_softdevice). The code I use to generate the zip is:

nrfutil pkg generate new_DFU.zip --hw-version 52 --sd-req 0xA8 --sd-id 0xA8 --softdevice softdevice.hex --bootloader-version 0 --bootloader bootloader.hex --key-file key_node.pem --application-version 0 --application application.hex

What am I missing? What am I doing wrong?

[Hung Bui]

Hi, 

Which softdevice do you have on the device before the DFU update ? 

After the DFU update do you have the application running as it should and do you have the new softdevice be updated ? 

I am not aware of that the nRF Toolbox would skip DFU update for softdevice and bootloader. 

If you only create the SD+BL .zip package would the DFU update succeed ?

[Mr Sunshine]

Both softdevices are the same (s132_nrf52_6.0.0_softdevice.hex), the reason why I re-update it is to have use one zip that contains de bootloader and the application. 

After the DFU I only notice that the application is changed, while the bootloader stays on the old one. I can't say anything about the softdevice as I update it to the same version.

I don't see it updating on the screen, and I assume that the (1/2) indicator is for the bootloader/softdevice update. Unless the update is really fast in which I cannot see it.

haven't tested SD+BL.zip jet, I'll try that one.

[Mr Sunshine]

sorry for my late response, I was gone due to holiday.

For case 1: Are there guides or examples for this modification. I followed the getting started guide on the DFU which doesn't help my situation.

For case 2: The NRF52832 is connected with Bluetooth to a tablet with or own application and requires a specific command to go into DFU mode. This means that after one update the device is out of the DFU mode and is disconnected from the tablet, thus a whole procedure needs to occur that reconnects the NRF52832 with the tablet for the second update. This reconnecting procedure can cause quite a confusion for some clients which we want to avoid, that is why I want to combine both the BL + APP into one zip to make the whole update proces streamlined. 

For case 3: In my experience the bootloader needs to be updated first after the application or else the application will brick itself. In addition we designed our application with flutter and it uses the flutter-nordic-dfu library, I don't believe that this library is that flexible and that altering it wil cause issues in the long term.

So to my understanding there is currently no easy way combine the BL + APP into one zip for the DFU update.

[mrono]

Mr Sunshine said:

It seems that the SD+BL zip doesn't seem to update due to a FW version failure.

Mr Sunshine said:

Can I only update the SD if I have a newer version?

If you are using the bootloader provided by Nordic, I believe it is the bootloader that rejects attempts to update to the same version. Unless you specifically configured it to allow downgrading.

[Mr Sunshine]

mrono said:

Unless you specifically configured it to allow downgrading.

Does downgrading also mean same version update? And how can I prevent this rejection, are there examples?

[Hung Bui]

Hi Sunshine, 

Case 1: You would need to dig deep into the bootloader to know how it works and modify it. It would require some work load but I think it's the best option for you if you want to have good user experience. We unfortunately don't have a guide for this task yet. But I believe it's not a blocker. 

Case 2: If you want better user experience Case 1 should be better. But can you make the disconnect and reconnect transparent to the customer ? Considering that it would happens very quickly and require no action from end customer, no indication that the device reset ? 

Case 3: It's very similar to Case 2. Same user experience so Case 1 should be better. I'm not very familiar with the flutter library so I can't really comment. 

All in all, to be able to achieve what you want, you may need to modify the bootloader and the DFU protocol to allow BL+APP update (even if you do SD+BL+APP there will still be 2 phases).

But please consider that normally it's not very often that you need to update the bootloader unless there is something special with your application that you need to update the bootloader often. If it doesn't happen so often I would think that end customer would be OK with a 2-phases update. 

[Mr Sunshine]

Hi Hung,

Hung Bui said:

But please consider that normally it's not very often that you need to update the bootloader unless there is something special with your application that you need to update the bootloader often.

Normally I only need to update the Application, but due to a issue in the writing space I had to alter something in the Bootloader. So in theory the bootlader only needs to be updated once.

About case 1 I'm not that experienced in altering the code in letting it allow the BL + APP zip update. I don't have the full grasp on how the DFU update proces works. So a guide or example would help.

Case 2 should be a better approach because the bootlader only need one update. I should communicate this with the application designer to see if the UI can guide the user in reconnecting with the nrf52832. If the bootloader is updated the user shouldn't have to undergo this proces again.

[Hung Bui]

If you are planning to do it only once I don't see the point of modifying the bootloader to support APP+BL. I would suggest to send 2 files or to modify the app to do 2 files in the background. 

[Mr Sunshine]

thank you for your time. I'll see what I can do.