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.

[Hung Bui]

If the softdevice is the same  id, most likely it will be skipped. 
But I don't see the point of updating SD+APP when the SD is not changed. If it's the case you only do APP update.

You only include the SD if it's a different Softdevice. 

[Mr Sunshine]

I want to have one zip containing the BL + APP, but this isn't possible. A zip containing BL + SD + APP is possible. So my reasoning is if I use the combined zip with BL + SD + APP to be able to update the BL and APP in one zip.

[Hung Bui]

Under the hood it will be the same that the process will need to be done in 2 phases. One is to update SD+BL (or BL) and after that is to update the Application.

But please clarify what exactly happened after  you do the update, would the new application running or not ? 

Please first try to update SD+BL in one .zip and then update APP after that in another .zip to separate the process make it easier to debug. 

[Mr Sunshine]

sorry for my late response, I couldn't do the testing due that some colleagues were on holiday.

It seems that the SD+BL zip doesn't seem to update due to a FW version failure. I am currently using this line to generate the zip:

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

Can I only update the SD if I have a newer version? Is there a way to evade this?

All I want is a way to update the BL + APP in one zip.

[Hung Bui]

Hi, 

I'm sorry for late response. When you update Softdevice if it's the same version there is no point of updating it and the bootloader will reject that. 
If you want to update BL+APP in one zip you have three option: 

- Edit the bootloader to accept BL+APP and handle them properly. This requires you to modify the bootloader. 

- Use one zip which include two DFU zip files inside one for BL and one for APP. In your DFU master app you unzip that file and then do 2 DFU update one for BL and one for APP. This doesn't require you to rewrite the DFU part of the DFU master app. I think this requires the least modification. 

- Use one zip for both BL+APP. You need to modify the DFU master app to open the zip file and then open the init packet for application and send application image, after that do the second DFU to open the init packet  for bootloader and send the bootloader. This requires you to modify the DFU part of the DFU mastar app a bit so that it will take the the init packets, images from same .zip file. 

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

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