Bootloader no-transport dual-bank DFU and dependencies

[Kenzi]

I'm just a bit fuzzy on how all of the bootloader stuff comes together.

• Our application is small (100K-ish), so a dual-bank strategy seems appropriate.
• It uses a proprietary bus protocol that we'd rather not pack into the bootloader.
• We need to upgrade potentially hundreds of devices unsupervised, so BLE DFU is not practical.
• We also have a "revert to factory image" button; the bootloader must copy this image from an external SPI ROM IC.
• Our next release will use Bluetooth (but not for upgrade), so we are using the S132 SmartDevice.

I imagine the best solution goes like this:

1. Server sends upgrade image to the application during normal use
2. Upgrade image is written to the second bank
3. Device resets, maybe sending a flag to the bootloader
4. Bootloader recognizes the upgrade image, validates the image and the signature and copies the image to the application bank
5. Bootloader resets back to the application

I just don't really know what API is appropriate for the above (aside from step 1).

When I bring in even just nrf_bootloader_app_start, it seems to also depend on an overwhelming number of BLE services, so I'm not sure if I'm on the right track with that... I thought DFU doesn't necessarily require BLE?

I've also seen the experimental IoT background update API, but it seems to be exclusive to TFTP... or ANT (it's unclear - or is it both?)

I'm using VisualGDB and have configured the appropriate write to UICR.BOOTLOADERADDR and located the bootloader at 0x00078000.  The bootloader seems to start fine.

Any advice for getting started with this?

[Vidar Berg]

Hi,

We introduced support for background DFU in SDK 15.3.0, but without any examples to demonstrate how you can use it, unfortunately.

In SDK 15.3 you can compile the bootloader with NRF_BL_DFU_ALLOW_UPDATE_FROM_APP=1 to allow the bootloader to activate an image uploaded by the app, and you can compile the app with NRF_DFU_IN_APP to use certain bootloader modules in the app. nrf_dfu_settings.c for instance.

I will try to make a simple example to test "background" DFU next week if time permits, but I can't promise anything. So I'd suggest that you start with the bootloader in 15.3.0 and integrate necessary DFU modules into your app and see if you can get the bootloader to activate the image for you. It should not be necessary to modify the bootloader itself.    

Update 5/7

I expect to have the sample code ready tomorrow, took a bit longer time than I expected. 

[Vidar Berg]

Hi,

Attached an example that supports serial DFU over UART from the application. I included a readme with the project, please let me know if anything is unclear. 

nRF5_SDK_15.3.0_background_dfu.zip

[Vidar Berg]

Kenzi said:

We also have a "revert to factory image" button; the bootloader must copy this image from an external SPI ROM IC.

Forgot to address this question. I think the easiest way to implement this would be to create another transport layer in the application code to fetch the image from external flash. The init packet would need to be stored along with the FW image in that case, and the bootloader must support version downgrade (compile flag). 

[lxjc]

Hi,

Thanks for your reply.

Can SDK 16 use this example?

[Vidar Berg]

It will require a few small changes to work with SDK 16/17, but nothing major. I think I would recommend starting with 15.3.0 though to make sure it works first, then use this implementantion as a reference when integrating background DFU to your exisitng SDK 16 based app.