Implement nRF-SDK BLE DFU transport layer in nRF connect

[Andreas3T]

Hi,

We have developed a product that is using nrf sdk and are moving towards replacing the nrf-SDK with the new connect SDK and one of the main features we have is to perform a DFU of the nRF firmware as well as performing a DFU of an external STM32 microcontroller. We achieve this by performing the DFU as the buttonless_dfu example for nRF and for the external device we mark it as "external" when we create a .zip dfu packet so the bootloader will only place it in the bank and then in our application we perform the DFU of the external STM32.

We have our own developed APP in both IOS and Android for performing the OTA dfu using nRF API's.

What we want to achieve is to move over to nrf connect without modifying our APP and retain all the OTA DFU funcionality.

It is my understanding that the BLE transport layer is new for nRF connect (using the SMP protocol) so to achieve this we need to implement the old BLE transport layer in nRF connect and then use Zephyrs "Flash Image" API's to write the firmware to the bank/slot.

A couple of questions:

1. I have a hard time finding exhaustive documentation for implementing the transport layer, i.e. documentation of the BLE service and commands. What I have found is the following:

A higher level flow chart of the DFU process:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_bootloader_dfu_process.html

Documentation (from nRF sdk 11, so quite old) of the characteristics from the "sender" of the firmware:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v11.0.0%2Fbledfu_transport_bleservice.html

Is there exhaustive documentation somewhere we can use to implement the transport layer ble service on the nRF side?

2. Can the old transport layer be "paused" or data be put on hold for a while to perform incremental DFU writes to the external microcontroller? I.e. receive X number of bytes, wait until they been written to the external device and the receive another X bytes and repeat until DFU is finished. It seems possible looking at the documentation as the "receive firmware" operation in the transport layer requires a response and my guess is that we could delay the response until we have written the bytes to the external microcontroller.

Note: Re-writing/changing the app is currently not an option unless it would require a minimal effort but we'd really prefer not to.

Best Regards and thanks in advance,
Andreas

[Sigurd Hellesvik]

Hi Andreas,

The standard bootloader for nRF Connect SDK is MCUboot.
For upgradable bootloaders, NSIB is added as well.
See Bootloaders and Device Firmware Updates.

I have an unofficial explanation of how these work in my Bootloader Samples, in case that is useful. I will also refer to this in my explanation below.

The nRF5 Bootloader generally did not use the application to do DFU. The only exception was for Buttonless DFU, where the application sent a signal to the bootloader, telling it to enter DFU mode.

MCUboot, on the other hand, will, by default, receive images using an SMP server.
This SMP Server can be inside the application or inside the bootloader.

When the SMP Server is inside MCUboot, it is called Serial Recovery.
This mode only supports serial communication and not Bluetooth LE.

If you need DFU over Bluetooth LE (OTA), MCUboot has an SMP Server running in the application.

How how did the nRF5 Bootloader manage to do OTA  from the bootloader?
This is because the SoftDevice is saved outside the application. Then the bootloader can access the SoftDevice for OTA.

If you want OTA for MCUboot, you must have functionality for this running in the application.
You will also get less space available for your application, as you need two slots for this.
MCUboot, as a bootloader, does not care about the application running, so you can technically add functionality to the nRF5 SDK application for receiving MCUboot images, but I do not recommend this.

For a similar case, I have seen a customer wanting to run nRF Connect SDK applications with the nRF5 bootloader. This is possible, see  One bootloader to rule them all.

In conclusion:

I do not see a lot of good reasons for updating only the bootloader to nRF Connect SDK. There might, of course, be good reasons for this, but I suggest you think about it once again before going for this choice.

While I did not answer your question directly, I hope I were able to help.
Let me know if you got more questions.

Regards,
Sigurd Hellesvik

[Andreas3T]

Sorry, I think I was a bit unclear then.

What i meant by APP is our iOS/Android app which is using the transport layer used in nRF5-SDK. We don't want to change this.

So in short, we want to re-develop our nRF firmware with the connect SDK but use the old transport protocol to transfer the DFU packets.

[Sigurd Hellesvik]

Aha, that makes more sense.

In that case, I think the easiest solution would be to use the nRF5 Bootloader and an nRF Connect SDK application.

However, MCUboot does not care how DFU images are inserted into its partitions. => You can place them there however you want, for example, using the nRF5 method.
You will have to do most of the work on how to move this yourself.
But if you want, I can look into what we got on resources and try to give you some places to start for this ?

Regards,
Sigurd Hellesvik

[Andreas3T]

Sigurd Hellesvik said:

In that case, I think the easiest solution would be to use the nRF5 Bootloader and an nRF Connect SDK application.

We need BLE connection in our application as well so this would require both the softdevice and nrf connects BLE stack, right? I don't think that would leave us with enough FLASH for the DFU of our external microcontroller and we don't have an external memory unit.

Sigurd Hellesvik said:

However, MCUboot does not care how DFU images are inserted into its partitions. => You can place them there however you want, for example, using the nRF5 method.

Yes, this was our plan. To re-use the transport layer/stack used in the nRF52-SDK DFU protocol.

Sigurd Hellesvik said:

But if you want, I can look into what we got on resources and try to give you some places to start for this ?

That would be very helpful, thanks!

[Sigurd Hellesvik]

Andreas3T said:

We need BLE connection in our application as well so this would require both the softdevice and nrf connects BLE stack, right?

Yes.

Andreas3T said:

I don't think that would leave us with enough FLASH for the DFU of our external microcontroller and we don't have an external memory unit.

If you need OTA for MCUboot, you will have less space available for the application, as the SoftDevice Controller + Host is a part of the application and therefore have to be in each slot. See the image below for an illustration:

\

For some tips on how to do Legacy DFU for the nRF Connect SDK:

Have a look at the DFU Transport protocol.

And for the BLE-specific DFU, see DFU->BLE. For the service, see DFU BLE Service.

For source code, look at "nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/dfu".
For BLE-specific DFU, see "nRF5_SDK_17.1.0_ddde560/components/libraries/bootloader/ble_dfu/"

I found that our Serial LTE Modem example has this file named dfu_host_legacy.c.

Maybe MCUboot Design can give some insight into MCUboot.
For more nRF Connect SDK-specific MCUboot details, see Using MCUboot in nRF Connect SDK.
And specifically, check out MCUboot output build files for an explanation of how our build system automatically generates files for DFU.
If you want to see the exact commands that generate these files, you can build from the command line with "west -vvv build ..."

The official MCUboot example we have is the SMP Server sample. However, I have a collection of my unofficial bootloader samples on my GitHub. These are, of course, not as thoroughly tested as the official ones.

If you are new to the nRF Connect SDK, I can recommend our https://academy.nordicsemi.com/.

If you have to handle the received image manually, have a look at the DFU Target library.

I hope that this was helpful.

Regards,
Sigurd Hellesvik