Customizing the bootloader to perform DFU using UART (and not BLE)

[Sir Oswald Mosley]

Hello, I am working on a nRF52840 based SoC (RAK4631) and it is using Adafruit's Arduino nRF core (Adafruit nRF52 Arduino). The DFU is being performed by BLE in that core. Instead of using the BLE layer, I am developing a process to do the DFU using UART.

My approach would be to store the new image file on my modem’s (RAK2011 - BG96) storage and then to mimic whatever process BLE layer is doing to write to the memory of NRF chip (RAK4631).

However, I have been told by the developer at RAK that the BLE OTA DFU functions in use are being handled directly in the bootloader and softdevice of the nRF52 (in case of Adafruit core bootloader) and there's little possibility of changing anything. Is this the case with the original nRF SDK bootloader as well ? or is it possible to isolate the BLE functions in the bootloader and perform DFU by UART ? 

Please keep that in view that I cannot use the NRF SDK on RAK4631 (codebase and platform limitations).

(here is the reference to the RAK query : BLE/UART OTA DFU on RAK4631).

[Einar Thorsrud]

Hi,

Focusing on the nRF, the point here is that it should be updated via UART from another MCU, is that correct?

I see the module is based on a nRF52840. You write that you cannot use the nRF5 DSK, but then I assume you mean for your application? Are you using the nRF Connect SDK, or something completely different?

There is no need to mimic BLE, as we provide serial bootloaders as well, which can be used more or less out of the box.. If you don't use either SDK in your application, and want a stand alone bootloader that has no dependency on the applicating or other way around, then both MCUboot’s serial recovery (from the nRF Connect SDK) and the nRF5 SDK bootloader with the UART transport can be used. In both cases this is provided by the respective SDKs, and can be used without any significant adjustments of the application itself.

Note that you will have to implement the DFU master for your host MCU yourself.

[Sir Oswald Mosley]

1. The nRF SoC will be updated from a modem using AT commands (modem is connected to SoC via UART). The modem's local storage will contain the new image. Supposedly, nRF will read the image data from the modem serially. 

2. I am using Adafruit's nRF52 core (Arduino based). It contains a modified form of the nRF SDK (mostly nrfx drivers). Reference : nRF SDK files in the Adafruit nRF52 core . So it's different from the regular SDK.

3. The codebase is based on Arduino C/C++ code and some libraries provided by Adafruit nRF core are being used for BLE, BLE based OTA DFU, file system etc. Reference : Adafruit nRF core Libraries .

4. Regarding the bootloader support mentioned by you. The bootloader being used by the RAK4631 SoC is from the Adafruit nRF core which in turn is itself a modified version of the original nRF SDK bootloader (source code : Adafruit nRF52 core bootloader) .

So I am not confident how the standalone bootloaders that you pointed to would be able to function on RAK4631 SoC. But anyway could you provide a sample binary of those standalone bootloaders , or point me to the steps to build one so that I may confirm it on my SoC.

5. Yes, I agree with you on the master/host implementation part.

[Einar Thorsrud]

Hi,

Sir Oswald Mosley said:

So I am not confident how the standalone bootloaders that you pointed to would be able to function on RAK4631 SoC. But anyway could you provide a sample binary of those standalone bootloaders , or point me to the steps to build one so that I may confirm it on my SoC.

I cannot comment on any modifications Adafruit has done as I am not familiar with those, but regarding 4, the RAK4631 this is a nRF52840 based module, and what we provide in the SDK is intended to work with any nRF52 based device with minor modifications. So using the SDK bootloader with RAK4631 should not be any problem.

I can point you to binaries for the bootloader, which you find in the nRF5 SDK distribution (under <SDK>\examples\dfu\secure_bootloader\). However, you typically need to make a few changes yourself, so it will most likely not work on your board / this module out of the box. You at least need to do the following changes to the bootloader:

• Use you own public key
• Change the pin configuration for UART to match your use case
• Adjust clock configuration if the module does not have a 32.768 kHz crystal oscillator

The build and test.

See Bootloader examples documentation and Bootloader and DFU modules documentation for more details.