nRF5340 bootloader with BLE transport

Hello,

I am new to Zephyr and its ecosystem which includes MCUboot and also the NCS sdk. I have a question regarding the nRF5340 bootloader.

So we already have a product with nRF52833 that uses nRF5 sdk bootloader. It works perfectly without any issues. Kudos to the team! Now we are trying to move to nRF5340 as our application got bigger. 

The nRF5 sdk bootloader has a ble transport which was very useful for our product. The main reason is that, our product depends only on BLE transport for DFU and there is no other ways to do a DFU (no serial peripheral or other means). Having a BLE transport in the bootloader ensures that our product would never get bricked. Even if the application fails (enters a boot loop), we were able to use the bootloader (using hardware checks to make the product stay in bootloader) to update the buggy application.

With nRF5340, I understand we can use either MCUboot or NCS bootloader or a combination of both.

If I understand the implementation of MCUboot, I could see that there is no BLE transport included with it. The application must include SMP server which receives the image into slot 1 when DFU is triggered. Then the MCUboot on the next reset, validates the image in the slot1 and swaps the image to slot0 and boots slot0. Then the application confirms that the image is valid and the bootloader locks this image in slot 0. If the application does not confirm, then MCUboot would revert back to previous application.

For our product this implemetation would be an issue. I do not prefer the dependency of the application for DFU. Because if the application is buggy, we would have a bricked product at user side with no means to do a DFU.

One solution for this problem is to have the SMP server with MCUboot or NCS bootloader. I would like to know if this is possible? If yes, could you please point me to any implementation that is already available?

Thanks in advance for your time!

Parents
  • Hi Regie

    We have no implementation of MCUBoot in the nRF Connect SDK that included Bluetooth Low Energy.

    Because if the application is buggy, we would have a bricked product at user side with no means to do a DFU.

    MCUBoot have functionality for testing the image before actually commiting to it.
    This way, you can run your program first, to see if it breaks, and then verify it after you know it works.
    If it breaks, a reset will revert to the previous image.
    Will this work for you?

    Regards,
    Sigurd Hellesvik

Reply
  • Hi Regie

    We have no implementation of MCUBoot in the nRF Connect SDK that included Bluetooth Low Energy.

    Because if the application is buggy, we would have a bricked product at user side with no means to do a DFU.

    MCUBoot have functionality for testing the image before actually commiting to it.
    This way, you can run your program first, to see if it breaks, and then verify it after you know it works.
    If it breaks, a reset will revert to the previous image.
    Will this work for you?

    Regards,
    Sigurd Hellesvik

Children
Related