Bootloader no-transport dual-bank DFU and dependencies

RE: Bootloader no-transport dual-bank DFU and dependencies

Allen_ — Sat, 21 Sep 2024 16:07:18 GMT

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

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Mon, 12 Oct 2020 11:11:43 GMT

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.

RE: Bootloader no-transport dual-bank DFU and dependencies

lxjc — Mon, 12 Oct 2020 10:52:41 GMT

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)

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Fri, 18 Sep 2020 07:27:19 GMT

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.

RE: Bootloader no-transport dual-bank DFU and dependencies

lxjc — Fri, 18 Sep 2020 04:50:00 GMT

Hi,

Thanks for your reply.

Can SDK 16 use this example?

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Thu, 09 May 2019 12:41:31 GMT

[quote userid="78854" url="~/f/nordic-q-a/46336/bootloader-no-transport-dual-bank-dfu-and-dependencies"]We also have a "revert to factory image" button; the bootloader must copy this image from an external SPI ROM IC.[/quote]

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

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Wed, 08 May 2019 09:35:57 GMT

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.

devzone.nordicsemi.com/.../nRF5_5F00_SDK_5F00_15.3.0_5F00_background_5F00_dfu.zip

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Fri, 03 May 2019 12:16:47 GMT

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.

RE: Bootloader no-transport dual-bank DFU and dependencies

Kenzi — Thu, 02 May 2019 18:02:38 GMT

I'd love pointers to any APIs, high level architecture ideas or example projects that could help me out here. How to make my bootloader validate and load an image stored by the application, as well as how to reboot to the application from there. I'm using 15.2 with S132.

RE: Bootloader no-transport dual-bank DFU and dependencies

Kenzi — Fri, 26 Apr 2019 18:16:33 GMT

I'm using 15.2 with S132

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Fri, 26 Apr 2019 13:45:12 GMT

There are several modules from the bootloader which you can re-use in your bootloader, function to transfer execution to app and image validation for instance. So maybe not a custom bootloader, but rather a modified version of the one we provide.

I think you can get a basic overview of the bootloader by going through the nrf_bootloader_init() function in nrf_bootloader.c.

1. Checks to see if should enter DFU mode or not

2. Check if there are any new FW images to activate (could be an image that the app has stored).

3. If dfu_enter == true, initialize transport and wait for DFU master to initiate a DFU

3. if dfu_enter == false, verify CRC of app image and boot the app.

Which SDK version are you currently using? I'll try to check how you can use the validate function for an image stored by the application.

RE: Bootloader no-transport dual-bank DFU and dependencies

Kenzi — Wed, 24 Apr 2019 18:45:15 GMT

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.

RE: Bootloader no-transport dual-bank DFU and dependencies

Vidar Berg — Wed, 24 Apr 2019 15:00:38 GMT

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

[quote user=""]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?[/quote]

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.