• State Not Answered
  • Replies 9 replies
  • Subscribers 76 subscribers
  • Views 3408 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285343
Options

nRF5340 bootloader with BLE transport

Regie Roshan Magendiran

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!

  • 0

    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

  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd

    Thanks for the quick response!

    Yes I understand that the MCUBoot has this functionality where it can boot a test image, and let the application confirm it. But in my opinion, this idea is not fail proof. An application with an unknown bug could end up confirming the image 'accidentally' and the product could end up bricked. Especially products that does not have means for recovery through serial port.

    Also one other reason a bootloader with BLE transport makes sense is the capability to have single bank upgrade. The bootloader with BLE can erase the single bank and flash it with new image. It could provide us more flash space for our application (reason why we wanted to move to nRF5340).

    But I understand that currently there is no implementation with MCUboot and BLE in NRF Connect SDK. What about NSIB?(I am not familiar with NSIB yet). Also do you think MCUboot with BLE transport is possible? I am planning to try it out, but would like to know your opinion.

    Thanks again!

  • 0 in reply to Regie Roshan Magendiran
    Regie Roshan Magendiran said:
    What about NSIB?

    NSIB can not contain SMP over Bluetooth Low energy. From our nRF Secure Immutable Bootloader sample:
    "Currently, this immutable bootloader does not support firmware updates over the SMP transport for either an upgradable bootloader or an application. If the application using this bootloader requires SMP-based firmware updates, such as BluetoothRegistered LE DFU, include MCUboot as a second-stage bootloader."

    I think that you should be able to make MCUBoot run Bluetooth Low Energy. In this case however, I believe you will have to add the SoftDevice Controller once for the application and once for MCUBoot. This will use up more flash, so that might be a problem.
    I am not aware of any method for interfacing between MCUBoot and the applications Softdevice controller.

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik
    Sigurd Hellesvik said:
    In this case however, I believe you will have to add the SoftDevice Controller once for the application and once for MCUBoot. This will use up more flash, so that might be a problem.

    BLE controller is available in the network core for nRF5340 right? Shouldn't MCUboot (with SMP server) be able to communicate with the network core? Why should it be added to the application core separately for MCUboot? Am I missing something here?

  • 0 in reply to Regie Roshan Magendiran

    That is a good point, I was thinking single-core here.

    I will investigate if/how this works tomorrow.

    Regards,
    Sigurd Hellesvik

Related
Terms of service