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]

The time is ok. I had the default time of 120s on my old bootloader. This is working correctly. Then I flash with the nrf connect app the new zip file with the new bootloader merged with 30s.

Now If I do a DFU OTA with a corrupted (wrong private key) zip file, the DFU is starting, dects the wrong key and disconnect BLE. all correct. Then the bootloder start the inactive delay and switch back to application after time x. But this time is still 120s instead of 30s. An Update to 30s is only happening if I flash the nRF over the cable with nrfjprog.

Or do I have to do a power on Reset after OTA manually (which is happening with the nrfjprog of course)

[Einar Thorsrud]

Hm, that does not make sense to me. The timer is all handled in SW, so if the new bootloader with 30 s timeout is what is running, the timeout should be 30 s. Did you successfully update to the new bootloader with 30s timeout (via DFU) before you tested updating to an image with invalid key that should fail? Or is it still the old bootloader that is running on the device? If it is the old, this is as expected. As this seems really odd, I suggest you verify that the new bootloader is running when this happens. For instance by adding different log string in the two versions, or toggling different GPIO's, or some other method you can use to easily see which bootloader version is actually running on the device.

Dominik Eugster said:

Or do I have to do a power on Reset after OTA manually (which is happening with the nrfjprog of course)

Power-on reset is not needed. (A bootloader-update involves a soft reset reset as the MBR is responsible for copying the bootloader and that runs first, but this is part of the update procedure, and as long as it is successful all is good).

[Dominik Eugster]

I will test again, yes t really sounds strange but I will check this again. Thanks

[Dominik Eugster]

Hi Einar Thorsrud 

Coming back to this topic. I found the "Bug". The generated zip package with the line:

nrfutil pkg generate --hw-version 52 ...

only contained the hex file from the application. If I do the same for the bootloader, I can update only the bootloader over OTA:

nrfutil pkg generate --hw-version 52 --sd-req 0x0100 --bootloader-version 1 --bootloader boot_test.hex --key-file private.key G3_bootloader.zip

and its working.

Is there a possibility to create a zip package which includes the app and bootloader?

Here they are discussing the same "Problem" and is the only solution 2 zip packages? is there no other solution?

https://devzone.nordicsemi.com/f/nordic-q-a/63895/how-to-generate-a-bootloader-softdevice-application-zip-for-ota-updates-dfu/261014

Thanks for any inputs

[Einar Thorsrud]

Hi,

You are right, an update zip consisting of application and bootloader is not supported. Generally, all combinations except for that is supported (see 4. Update softdevice and bootloader). Other than that, I do not have anything to add part from what is already in this post in the thread you mentioned.

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