Bootloader Update with new size over BLE DFU service

[Dominik Eugster]

Hi

Is there a possibility to update the bootloader himself over the BLE DFU?

I have a new bootloader with a bigger size (MemoryMap changed) and I am wondering if I can upload old boards with the small bootloader over BLE DFU with the Nordic nrf Connect App, because there is under SelectFileType (Bootloader). Is this possible only if the size and memory map is equal or even if the size is bigger?

I checked if I can download te new Ditribution Packet (ZIP) on the old device with the old small bootloader, and yes, its possible. The application is new but the bootloader is still the old one. Even after Powereset the application is running wit the old bootloader, this makes me a little bit confusing, ow is this possible?

See: https://devzone.nordicsemi.com/f/nordic-q-a/89328/ota-dfu-bootloader-memory-map-increasing-size-in-pca10056_s140_ble

Regards, Dominik

[Einar Thorsrud]

Hi Dominik,

Is there a possibility to update the bootloader himself over the BLE DFU?

Yes.

I have a new bootloader with a bigger size (MemoryMap changed) and I am wondering if I can upload old boards with the small bootloader over BLE DFU with the Nordic nrf Connect App, because there is under SelectFileType (Bootloader). Is this possible only if the size and memory map is equal or even if the size is bigger?

The size of the bootloader cannot increase across the page boundary when doing DFU. Meaning: the start address must remain the same, and it cannot grow into the last two pages (MBR params and bootloader settings pages). The reason for this is that the bootloader start address is at the end of the MBR page, and that cannot be changed via DFU (it has to be done via an attached debugger as you would have to erase the MBR page and write it again).

[Dominik Eugster]

Einar Thorsrud said:

Yes

But in this case only over the SWD SWD upater with the nrfjprog?

OTA is not possible if the start address is different, which is my case, right?

The other question is, why the new build is possible to download with new start  adress, I gues because of the same keys in the building? (bootloader is still the old one after OTA (zip file), the application is new if I do a OTA on a old bootloader device with a higher start address)

Thanks

[Dominik Eugster]

Ok thanks.

But why is there written that the APP + SD + Bootloader is possible?

In this post they say this is impossible, but maybe I understand something wrong?

Einar Thorsrud said:

this post

[Einar Thorsrud]

In this case, the DFU master (like for instance nRF Connect for mobile) split the update in two automatically. First BL + SD is updated, and then the app is updated as a separate operation.

[Dominik Eugster]

But this split has to be done with a special App or the normal Nordic nRF Connect will do? If so, how to create the zip wit the BL+SD+APP? all with nrfutil pkg generate in a combined file? thanks

[Dominik Eugster]

I got the reply:

Invalid combination: use two .zip packages instead.

[Einar Thorsrud]

Hi,

Which tool and combination did you use then? nrfutil should be able to combine all three in a single update. And then it is up to the tools to handle that properly (nRF Connect for mobile does that, but nRF Connect for desktop unfortunately does not support the combination of APP + BL + DFU, and this is a limitation in that specific tool).

In any case, you would typically implement DFU in your own app, using our libraries, and there you can hide multiple zip archives from the user in several different ways. Typically the user never see any of it, as it is automatically downloaded in the background, and if the user is to provide a zip, that could be a single zip that just combines two other zips that your app extracts before (typically) using it with a DFU library provided by us (like for instance Android-DFU-Library).