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

How to install and activate nrf52 DFU bootloader?

Hello,

Im working on a project that will require us to be able to update the nrf52 (which is providing BLE services to a host MCU) via a custom over-the-air update mechanism. We already have PCBs being produced with the nrf52 on them (so this is not a dedicated development kit). I am wondering how we can do the following:

1) Install the DFU bootloader onto the nrf52

2) Activate the bootloader so that we can begin the DFU process. I would prefer if we could trigger this externally so the host MCU can start an upgrade without having to rely on software on the nrf52.

Thank you very much for any help.

Parents
  • Hi,

    Are you using the nRF5 SDK or the nRF Connect SDK? I will assume the nRF5 SDK for now. Which transport do you want for DFU? I will assume BLE for now.

    1) Install the DFU bootloader onto the nrf52

    First you need to generate your own key pair, and build the example bootloader project with your own public key. Depending on your needs, you may also need other changes. Once you have that in place, you just flash the bootloader and SoftDevice to the nRF using SWD. Typically you also want to program the initial application at the same time, and then you also need to generate and program a bootloader settings hex so that the bootloader will know that the application is present and valid. All of this is described in the bootloader example documentation I linked to earlier.

    2) Activate the bootloader so that we can begin the DFU process. I would prefer if we could trigger this externally so the host MCU can start an upgrade without having to rely on software on the nrf52.

    There are several options to start the DFU process. As you want to control this from an external MCU, then one option could be to perform a pin reset on the nRF, and configure the bootloader to enter DFU mode on pin reset. If you also use the pin reset for other tings, you could use a separate GPIO so that you would both trigger pin reset and assert another GPIO while the bootloader starts, so that it can check that. For entering DFU via pin reset, you want to set NRF_BL_DFU_ENTER_METHOD_PINRESET to 1 in the bootloader's sdk_config.h. For using a normal GPIO pin (which is checked during boot by the bootloader), should set NRF_BL_DFU_ENTER_METHOD_BUTTON to 1 and NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN to the GPIO pin number.

  • Thank you very much for the help. I apologize as I am still pretty new to embedded firmware development (my background is Linux kernel development).

    Are you using the nRF5 SDK or the nRF Connect SDK?

    We have a main application that was built by a consulting group. I'm not sure which API we are using for that, but we program it onto the board via a jlink -> USB connector with the desktop nrfConnect application. We are using Soft device version 7.2.0 for this

    Which transport do you want for DFU?

    I was hoping to do it over SPI, but we have UART as well. We want the update to come from the MCU, which does not have BLE capabilities. I see there are UART examples in the examples/dfu/secure_bootloader folder that is mentioned in the link you posted so maybe that would be a good place to start.

    I read through the links that you provided and downloaded the nrf5 SDK from the nordic downloads page. Here are some new questions I have now:

    3) Does the bootloader need to be built with the same SDK for it to work? How can I find out what SDK the main application was built against? Where would I start looking if I need to use the nrfConnect SDK instead? In the code built by the consulting group, I noticed the following directory (see attached image). I have no idea where it came from and I'm not sure how to find out

    4) Our MCU is a STM322L452, which is does not have a directory. There don't seem to be any .c files and I'm not really sure what the files that are in there do. Is there a document anywhere that details what I need to do to support a different MCU?

    5) As I mentioned we would prefer it if we could communicate with the bootloader over SPI. Is there a document that details what I need to do to support that?

    6) For our purposes I'm not sure we really need a secure bootloader. Would it simplify things to use a non-secure bootloader? If I do need to use the secure bootloader how do I sign my binaries?

    Sorry for having so many questions. Thanks again for any help.

Reply
  • Thank you very much for the help. I apologize as I am still pretty new to embedded firmware development (my background is Linux kernel development).

    Are you using the nRF5 SDK or the nRF Connect SDK?

    We have a main application that was built by a consulting group. I'm not sure which API we are using for that, but we program it onto the board via a jlink -> USB connector with the desktop nrfConnect application. We are using Soft device version 7.2.0 for this

    Which transport do you want for DFU?

    I was hoping to do it over SPI, but we have UART as well. We want the update to come from the MCU, which does not have BLE capabilities. I see there are UART examples in the examples/dfu/secure_bootloader folder that is mentioned in the link you posted so maybe that would be a good place to start.

    I read through the links that you provided and downloaded the nrf5 SDK from the nordic downloads page. Here are some new questions I have now:

    3) Does the bootloader need to be built with the same SDK for it to work? How can I find out what SDK the main application was built against? Where would I start looking if I need to use the nrfConnect SDK instead? In the code built by the consulting group, I noticed the following directory (see attached image). I have no idea where it came from and I'm not sure how to find out

    4) Our MCU is a STM322L452, which is does not have a directory. There don't seem to be any .c files and I'm not really sure what the files that are in there do. Is there a document anywhere that details what I need to do to support a different MCU?

    5) As I mentioned we would prefer it if we could communicate with the bootloader over SPI. Is there a document that details what I need to do to support that?

    6) For our purposes I'm not sure we really need a secure bootloader. Would it simplify things to use a non-secure bootloader? If I do need to use the secure bootloader how do I sign my binaries?

    Sorry for having so many questions. Thanks again for any help.

Children
  • Hi,

    tcaputi said:
    We are using Soft device version 7.2.0 for this

    I understand you are using a SoftDevice, so then probably also the nRF5 SDK. Looking at your screenshot, that shows the nRF5 SDK directory structure.

    tcaputi said:
    Does the bootloader need to be built with the same SDK for it to work?

    Not necessarily. If the bootloader would use BLE as transport, then it must use the same SoftDevice as the application (as that is the BLE stack, and the BLE transport for DFU would be implemented in the bootloader). As you want to use a serial bootloader, that is not important, as the serial bootloader from recent SDK versions is standalone and has no dependencies on the SoftDevice.

    tcaputi said:
    Where would I start looking if I need to use the nrfConnect SDK instead?

    You are using the nRF5 SDK for the application, and that is also more mature, so Iit does not seem sensible to start looking at the nRF Connect SDK at this point.

    tcaputi said:
    4) Our MCU is a STM322L452, which is does not have a directory. There don't seem to be any .c files and I'm not really sure what the files that are in there do. Is there a document anywhere that details what I need to do to support a different MCU?

    The nRF5 SDK can only be used with nRF5 devices. How you have integrated the other MCU is up to you. Regarding DFU, there are no official serial DFU master DFU implementations in C, but there are some that may be relevant to look at. For instance this unofficial implementation. It would need adaptations though, as porting it to the STM would be up to you, also for using SPI instead of UART.

    tcaputi said:
    5) As I mentioned we would prefer it if we could communicate with the bootloader over SPI. Is there a document that details what I need to do to support that?

    The nRF5 SDK bootloader does not have an SPI transport. However, is designed so that the transport layer can be fairly easily replaced. I suggest you look at the existing implementation in the SDK, as well as the bootloader modules documentation. There are also some threads about this allready. It makes sense to start off with the UART transport and modify that to use SPI instead.

    tcaputi said:
    6) For our purposes I'm not sure we really need a secure bootloader. Would it simplify things to use a non-secure bootloader? If I do need to use the secure bootloader how do I sign my binaries?

    There is no need to use a secure bootloader (with signature verification) if you do not want it. The only example that do not use it is the USB bootloader, so you can refer to that to see which code you can remove/skip. Regarding how to sign, that is handled by nrfutil, which is the same command line tool you use to generate the upgrade images. You can refer to nrfutil documentation for how to use it.

    In general the bootloader is a bit complex, but the SDK has a lot of documentation and examples. It might be worth while going through a DFU bootloader example to get a basic overall understanding before digging deeper.

Related