Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bootloader no-transport dual-bank DFU and dependencies

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?

Parents Reply Children
No Data
Related