DFU failing with nRF Secure Immutable Bootloader(NSIB) as the first stage bootloader

Hi,

We are using the nRF Secure Immutable Bootloader(NSIB) as the first stage bootloader along with MCUboot as the second stage bootloader in our nrf5340 project. We have observed that the BLE (SMP based) DFU fails when we add the immutable bootloader to the project. The firmware get's downloaded to the device, but after reset it doesn't boot into the new application and gets stuck somewhere. There are no logs that get printed to indicate any issue. I am using the 'nRF Connect' mobile application in Android for our testing. The SDK is  NCSv2.1.0.

I have made the bare minimum changes needed to reproduce this in the example projects(machine learning and matter lock) provided by Nordic. I have added the CONFIG_SECURE_BOOT=y in the prj.conf of both examples and made sure to use the same memory partitions in both the the projects(pm_static.yml). Below are the zip files of the two projects:

1. Machine learning

  machine_learning.zip

2. Matter lock:

lock.zip

Please try performing the DFU from the first project to the second project or vice-a-versa on nrf5340DK board. It is failing for us.

This same upgrade works fine if we don't use the first stage immutable bootloader(NSIB) in the project.

Please help us in resolving this issue.

Also, I would like to know how we could upgrade the MCUboot image. Which is the binary that needs to be used? Is it the 'signed_by_b0_s0_image.bin'? Can we use the 'nRF Connect' mobile application itself for updating the MCUboot image?

Regards,

Devanshu Agarwal

Parents
  • Hello,

    Which is the binary that needs to be used? Is it the 'signed_by_b0_s0_image.bin'? Can we use the 'nRF Connect' mobile application itself for updating the MCUboot image?

    Yes that's right. You can either use our nRF connect mobile Application or our Dedicated DFU application for doing the update. Take a look at this guide created by my colleague where you can see,  how to do the same via our nRF connect Application.

    I am looking into your main issue, I need some more time to check this.

    Kind Regards,

    Abhijith

  • Hello,

    Which is the binary that needs to be used?

    Hello,

    Is there any update on this? When I looked at my first response,  it's confusing because I haven't commented anything on binary image you need to transfer and I have included that part of your question. 

    The binary file you need to update depends on your active MCUboot(which boot up the application). If s0 is the active mcuboot you need to update the image with s1 and vice versa. For eg: if s0 is active you need to update s1 with image signed_by_mcuboot_and_b0_s1_image_update.bin, the binary file you are pointing is not the one need to be transferred.

    Kind Regards,

    Abhijith

Reply
  • Hello,

    Which is the binary that needs to be used?

    Hello,

    Is there any update on this? When I looked at my first response,  it's confusing because I haven't commented anything on binary image you need to transfer and I have included that part of your question. 

    The binary file you need to update depends on your active MCUboot(which boot up the application). If s0 is the active mcuboot you need to update the image with s1 and vice versa. For eg: if s0 is active you need to update s1 with image signed_by_mcuboot_and_b0_s1_image_update.bin, the binary file you are pointing is not the one need to be transferred.

    Kind Regards,

    Abhijith

Children
Related