nrf connect SDK BLE DFU

[loquat]

I am planning to migrate from nRF5 SDK to nRF connect SDK on nRF52832.

I have a question about BLE-DFU of nrf connect SDK.

1. Is nrf connect SDK support BLE-DFU?

2. Is support dual-bank DFU?

3. Is support allication based DFU?(Do DFU at the same time while running the application)

[Mike Austin (LPI)]

One of the Nordic Engineers will be able to give you a more detailed answer, but from my experience using nRF Connect SDK (I'm currently on v2.2.0) and the nRF52832:

1. Yes.  I can do this both using the nRF Connect App, as well as my custom App

2. If you mean dual image (so, the new image gets transferred into Flash and then the device reboots, and uses the new image whilst the old image remains in flash), then yes.  This is what we are currently doing

3.  Not sure.  With our application, things appear to halt whilst the DFU is in process, and then it all restarts (the DFU issues a software reset on completion) at the end

Hope that helps

Mike

[Vidar Berg]

Thanks for the answer, Mike. I do not think there is much to add to what you already said. 

1. Please see this guide for instructions on how to add DFU support to an existing application:  Add DFU support to your application 

2. In the nRF connect SDK, you cannot update the application "in-place" like you could in the nRF5 SDK as the main application needs to be running to receive the update image.

MCUBoot does not have a built-in BLE DFU transport like the old bootloader had.

3. The application will continue to run while you receive the update image, but other application tasks may be delayed or blocked by the DFU process as it is quite resource heavy if you try to upload the image as fast as possible (it involves lots of blocking flash operations). 

Best regards,

Vidar

[loquat]

Thank you

Does it mean DFU in parallel in the background of a application?

additional question.

I plan to use SoftDevice Controller.
What size applications can be created?
example: nRF52832 FLASH: 512KB Apps: 100KB + SoftDevice: 100KB + MCU: 50KB remain:512KB-250KB=262KB
Updatable Apps size is 262KB-SoftDevice:100KB=162KB?

And
Is it possible to create a DFU user transport?

[Vidar Berg]

Yes, the main app will be running when you receive the FW image.

loquat said:

I plan to use SoftDevice Controller.
What size applications can be created?
example: nRF52832 FLASH: 512KB Apps: 100KB + SoftDevice: 100KB + MCU: 50KB remain:512KB-250KB=262KB
Updatable Apps size is 262KB-SoftDevice:100KB=162KB?

The size of the SD controller varies depending on what BT features you have enabled in your application. So, the best way to estimate the size requirements is to build one of the SDK samples. 

You can try the minimal build configuration for the LBS sample (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/peripheral_lbs/README.html#minimal-build) to size the memory footprint of an optimized BLE application. 

loquat said:

And
Is it possible to create a DFU user transport?

Yes, there is not requirement to use the SMP transport. You can use the Flash image management APIs here to write your update image to the update slot: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/device_mgmt/dfu.html#api-reference 

[loquat]

OK.Thanks.

And more questions.

1.Will SoftDeviceController and apps be a single image file in the nrf connect SDK?

2.In the future, are there any plans to separate apps and enable DFU for apps only, like LegacySoftDevice?

3.Is there support for compressed DFU image files?

[Vidar Berg]

loquat said:

1.Will SoftDeviceController and apps be a single image file in the nrf connect SDK?

Yes, the Softdevice controller and application are in one FW image.

loquat said:

2.In the future, are there any plans to separate apps and enable DFU for apps only, like LegacySoftDevice?

The Bluetooth host is a part of Zephyr and relies on the OS to work. In other words, if we were to split the stack into a separate application like with the old architecture, we would end up with 2 apps with Zephyr instead of one.

loquat said:

3.Is there support for compressed DFU image files?

We do not have support for compressed DFU, unfortunately. Support for the LZ4 algorithm (https://docs.zephyrproject.org/3.2.0/samples/compression/lz4/README.html) is included with Zephyr, but it has not been evaluated for DFU as far as I know. It may be that the size requirements for the library itself is too big to make sense for this use case.

[loquat]

I think that’s disappointing.
When I do DFU, I rarely update SoftDevices.
Including the same SoftDevice in the two images before and after updating is a waste of FLASH and prevents creating highly functional apps.

my apps are
1. Highly functional apps, spending more than 150KB
2. Use the TimeSlot API
3. (Future) Use PeriodicAdvertising (send/receive)

Can you suggest a SoC that satisfies these?

And then,
Is it possible to store DFU images in external FLASH with nRF52833?
If so, is there a list of supported FLASHs?

[Vidar Berg]

Yes, this is indeed a drawback with the new architecture. The solution is often, as you suggested, to include external FLASH in the design to allow for immediate storage of new FW images.

loquat said:

my apps are
1. Highly functional apps, spending more than 150KB
2. Use the TimeSlot API
3. (Future) Use PeriodicAdvertising (send/receive)

Can you suggest a SoC that satisfies these?

All these features are available on the nRF52832. Whether it will have enough FLASH/RAM is dependent on your application. The bootloader is typically around 32kB which leaves 480kB to the application + secondary DFU slot. Note: the secondary slot can optionally be placed in external flash.

loquat said:

Is it possible to store DFU images in external FLASH with nRF52833?
If so, is there a list of supported FLASHs?

Yes, the DFU solution supports external NOR flash through the SPI NOR driver: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/zephyr/samples/drivers/spi_flash/README.html