• State Verified Answer
  • Replies 5 replies
  • Subscribers 71 subscribers
  • Views 2284 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301589
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

One bootloader to rule them all

PB

Hello. I have a question about which I can't seem to find an easy answer to. It's related to DFU and nRF5 SDK vs Zephyr vs nRF-Connect SDK.

I am looking for one bootloader for nRF chips which would fit all needs, that is: UART/native-USB, BLE DFU.

Right now I know or have used:
1. DFU bootloader from nRF5 SDK as base for own project along with pc-nrfutil which seems to be archived as of yesterday which is not very fortunate 
2. MCUBoot from Zephyr 
3. MCUmgr which I haven't used yet because there's so much to do ;) But IIRC it worked only in dual bank configuration which is not an option because the firmware wouldn't fit in.
4. Probably something in nRF Connect SDK which I know the least yet because unfortunately I don't have the luxury to explore more SDKs for the fun of it. I would expect MCUBoot and MCUmgr as it's based on Zephyr.

So we've been using 1 since been working with nRF chips for a while and that was the only option available at that time (nRF52840 wasn't even in sampling back then). It has it's pros and cons but over time we've adapted it to work ok. pc-nrfutil caused us some pains because we had to do an insane amount of sourcery to make it (especially python3) work on a 32MB RAM MIPS OpenWRT device with all the libs but it worked eventually. Porting pc-nrfconnect to C or Go wasn't really anything we had time to do yet unfortunately. But in general this works... but. Now comes Zephyr and nRF Connect SDK and that leads to point 2.

MCUBoot is great, works with native USB, even UART sometimes. BLE DFU is not there though so it's a dead end for us. While we really appreciate the speed it takes to do DFU which is <1min on MIPS mentioned before vs 5-10minutes running pc-nrfutil on it. Another great thing is the fallback feature - when new firmware gets corrupted MCUBoot will still be functional. nRF5 SDK just boots to invalid firmware and that's pretty much game over.

This long introduction brings me to a few questions, quite relevant for all the work we've put with nRF5 SDK projects and want to move forward to either Zephyr or nRF Connect SDK.

1. Is there a single bootloader which would support USB/UART and BLE DFU? Looking for 1 application slot, no external flash available.
2. Is there any way to have nRF5 SDK based bootloader to be able to flash Zephyr based builds? We have so much done with nRF5 SDK that migrating to new SDK defeats the purpose
3. How could we swap between Zephyr/nRF-Connect-SDK and nRF5 SDK AP+SD builds?

What is an intended way for this migration to happen when nRF5 SDK was discontinued and Zephyr/nRF-Connect-SDK came to be the leading SDK? Just having one simple bootloader to change between Zephyr/nRF Connect SDK and nRF5 SDK base images would be an amazing thing to work with. Is this somehow achievable?

  • 0

    Hi,

    I will look into your questions and return with more information on Monday.

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi,

    It seems like it takes some more time than planned to find good answers for your questions.

    I hope to answer in 1 or 2 days.

    Here is what I have so far:

    1. Is there a single bootloader which would support USB/UART and BLE DFU? Looking for 1 application slot, no external flash available.

    As far as I know, there is no such solution for MCUboot.
    MCUboot does not have any support for BLE DFU.
    MCUboot also have a requirement of same-size slots.

    It seems that you need to make quite large changes to MCUboot if you want to change either of these two things.

    I discussed something similar with another customer in  BLE Recovery Image 
     
    Keep in mind that this was more regarding stability than space.

    2. Is there any way to have nRF5 SDK based bootloader to be able to flash Zephyr based builds? We have so much done with nRF5 SDK that migrating to new SDK defeats the purpose

    I am mostly experienced with the NRF Connect SDK. And my colleague who is most likely to know this have been out of office last week.
    I will discuss this with him tomorrow, to figure out if it is possible or not.

    If it works, I am inclined to think that the old bootloader would be the best solution for you.

    3. How could we swap between Zephyr/nRF-Connect-SDK and nRF5 SDK AP+SD builds?

    We have a script for converting devices from the nRF5 Bootloader to MCUboot.
    I will find this tomorrow.

    Regards,
    Sigurd Hellesvik

  • +1 in reply to Sigurd Hellesvik

    nRF5 Bootloader with nRF Connect SDK application

    Yes, you can do this.
    The application does not care which bootloader runs it.

    For BLE, the nRF5 bootloader used the Softdevice.
    So if you want DFU over BLE, you need to include an extra Softdevice into your device.
    This extra softdevice will require less flash space than the application, so it may solve your flash-space issues.

    To make sure that you have unused flash-space for the nRF5 bootloader+softdevice before the application, you can use "CONFIG_FLASH_LOAD_OFFSET".

    Any nRF5 communication between the application and Softdevice might become problematic. Such as buttonless DFU.
    I have not tested this though.
    It will likely be easier to use some other mechanism to trigger DFU, such as pulling a pin.

    Update the nRF5 Bootloader to MCUboot

    If you decide that you want to update to MCUboot, see  Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application 

    Does this answer your questions?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Thank you very much for all the invaluable information! I will be processing this slowly and let you know when I come up with anything. Indeed it seems that CONFIG_FLASH_LOAD_OFFSET is the way to go.

    Also on top of this, is there any implementation of nRF5 SDK DFU protocol in C or other language than Python available? There is quite a few cases to cover in nRF5 SDK DFU so thought that maybe you might be aware of existing implementations.

  • 0

    Headsup: If you mark a case with "Verified Answer", it no longer is in my queue.
    I sometimes check my "closed" cases, which is how I caught this one.
    So if you want to make sure that I still see your new questions after that, make sure to tag me in the comments as such  

    PB said:
    Also on top of this, is there any implementation of nRF5 SDK DFU protocol in C or other language than Python available? T

     nrf52832 serial dfu mode implementation procedure in nrfutil application

    It is 4 years old, but it is still true today.
    It is regarding the nRF5 SDK after all.

    Regards,
    Sigurd Hellesvik

Related