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,

I think there are mainly two options to consider for this: 1 create a custom transport layer with your proprietary bus protocol and integrate it with the existing bootloader (create custom transport). 2. Let the application handle the DFU transfer and storing of image to bank 1, then make a custom bootloader that's responsible for validation and activation of the new image. The current bootloader implementation does not support background DFU (ie. app handled dfu transfer).

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?

BLE is only required if you use the BLE transport layer. The serial bootloaders in SDK 15.x.x do not require a Softdevice to be present.    

[Kenzi]

Thanks for the reply.

By "custom bootloader," you mean we would have to implement our own validation of the received image, perform the direct FLASH writes to copy Bank 1 to Bank 0, and figure out our own way to reboot from the bootloader to the application?

The serial bootloaders I assume still require a (serial?) transport - does this imply that they can't be leveraged for at least some of the above steps?

If I were to completely hand-write a bootloader as described above, I think the only unknown at this point is how to get back to the application.

[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.

[lxjc]

Thanks for your reply.

A mobile application can only send bin file, but not.bat file. Can you use this method for DFU

Now I know the DFU process, but I don't know how to implement it.

Application Scenario:
The application part：
Transferring the new firmware to flash memory（.bin）

The rest is done in BootLoader.(I'm not so sure)

[Vidar Berg]

Hello,

We provide DFU libraries for Android and iOS to help integrate DFU support in mobile apps. These are available on our github page here:

https://github.com/NordicSemiconductor/Android-DFU-Library

https://github.com/NordicSemiconductor/IOS-Pods-DFU-Library

Please create a new thread if you have further questions to this.

[Allen_]

Hi,Berg:

Do not continue to execute after starting serial transmission, sure that the serial port on the hardware is through and has been verified, any good troubleshooting suggestions, thank you