This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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?

Parents
  • 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 ?

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

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

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

  • It seems that the SD+BL zip doesn't seem to update due to a FW version failure.
    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.

  • 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?

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

Reply
  • 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. 

Children
Related