Bootloader Update with new size over BLE DFU service

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Tue, 23 Aug 2022 06:15:09 GMT

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

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Sat, 20 Aug 2022 14:21:27 GMT

I got the reply:

Invalid combination: use two .zip packages instead.

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Sat, 20 Aug 2022 14:10:27 GMT

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

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Sat, 20 Aug 2022 11:08:07 GMT

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.

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Thu, 18 Aug 2022 08:54:05 GMT

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?

[quote userid="7377" url="~/f/nordic-q-a/89484/bootloader-update-with-new-size-over-ble-dfu-service/382105"] this post[/quote]

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Wed, 17 Aug 2022 18:57:26 GMT

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.

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Wed, 17 Aug 2022 14:12:02 GMT

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

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 12:59:38 GMT

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

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Fri, 01 Jul 2022 12:31:53 GMT

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.

[quote user="Dominik Eugster"]Or do I have to do a power on Reset after OTA manually (which is happening with the nrfjprog of course)[/quote]

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

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 10:55:20 GMT

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)

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Fri, 01 Jul 2022 10:14:35 GMT

I don't understand the use case precisely. Is the bootloader that is on the device built with a timeout enabled, and what is that timeout? Can you test with a debug bootloader with RTT logging and check the log?

A last point: If your WH is using a LFRC instead of an LFXO and WDT, then you may be seeing a bug in the bootloader where the LFCLK is not beng properly started after a soft reset, which prevents the inactivity timer from working. The fix for this is to modify this part of timer_init() in components\libraries\bootloader\nrf_bootloader_dfu_timers.c:

        if (!nrf_clock_lf_is_running())
        {
            nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);
        }

and reduce it to this:

        nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 09:16:54 GMT

checked again, not working with the new time if I choose this:

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Fri, 01 Jul 2022 08:54:39 GMT

I did not get this. Can you elaborate?

[quote user="Dominik Eugster"]The bootloader will be updated with the zip packet aswell, but the SDK config settings not?[/quote]

The sdk_config.h file for the bootloader is used when building the bootloader. That is then part of the resulting binary file. So regardless of how you update the bootloader, as long as it is successfully updated, all and any changes will be included (as you get the exact same binary bootloader file programmed in the end regardless of method being used).

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 08:15:17 GMT

[quote userid="7377" url="~/f/nordic-q-a/89484/bootloader-update-with-new-size-over-ble-dfu-service/375014"]The bootloader implements an inactivity timeout that applies in this and other cases. This is controlled by adjusting the NRF_BL_DFU_INACTIVITY_TIMEOUT_MS parameter in the bootloader's sdk_config.h. The default value in our examples are 120000 ms, so 2 minutes.[/quote]

This is working, but only after flashing the RF over SWD with the programmer.

If I update the file with nrf connect app and send the zip packet, this changing was not active. Why? The bootloader will be updated with the zip packet aswell, but the SDK config settings not?

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 07:51:42 GMT

great, thanks

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Fri, 01 Jul 2022 07:42:37 GMT

Hi,

[quote user="Dominik Eugster"]I just checked the download of a faked (wrong keys) firmware over OTA. The bootloader check the downloaded files and detect the wrong key and close the connection. The old application is still in the flash (single image bootloader setup). This is really important that nobody can "kill" the application.[/quote]

Yes, that is correct. The first step in the DFU process is to transfer the init packet and validate the signature. If the signature is not valid, the DFU procedure will be aborted before any persistent changes are made.

[quote user="Dominik Eugster"]The only problem at the moment is, that in this case the bootloader remains in the bootloader after detection a new firmware with a wrong private key. Where can I change the bootloader to do a reset and load the application (exit the bootloader). Can you tell me the function in the bootloader which is detecting the wrong key to add a nrfreset function to change to application without power reset?[/quote]

The bootloader implements an inactivity timeout that applies in this and other cases. This is controlled by adjusting the NRF_BL_DFU_INACTIVITY_TIMEOUT_MS parameter in the bootloader's sdk_config.h. The default value in our examples are 120000 ms, so 2 minutes.

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 07:17:11 GMT

I just checked the download of a faked (wrong keys) firmware over OTA. The bootloader check the downloaded files and detect the wrong key and close the connection. The old application is still in the flash (single image bootloader setup). This is really important that nobody can "kill" the application.

The only problem at the moment is, that in this case the bootloader remains in the bootloader after detection a new firmware with a wrong private key. Where can I change the bootloader to do a reset and load the application (exit the bootloader). Can you tell me the function in the bootloader which is detecting the wrong key to add a nrfreset function to change to application without power reset?

At the moment I have to do a power reset in this case.

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Fri, 01 Jul 2022 06:42:24 GMT

ok, got it, but the bootloader himself will check the binary on Startup and if the keys are not correct, don't allow the update. I will check this with my hardware. This will work to avoid the installation of corrupted (or fake) binary files, Thanks for your inputs

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Fri, 01 Jul 2022 06:21:36 GMT

[quote user="Dominik Eugster"]OTA is not possible if the start address is different, which is my case, right?[/quote]

Yes, that is correct. Update of the bootloader in general is supported and no problem, but the bootloader size cannot be changed via OTA (the exception for that is if you originally reserve more size than needed by placing the bootloader start address lower, as what really must remain the same is the bootloader start address).

[quote user="Dominik Eugster"]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)[/quote]

The DFU procedure does not do any checking of the start address, it will always assume that the new image is to be located at the same address as that is the only thing that is supported. Generally, the DFU implementation attempts to handle any issues that could happen accidentally, particularly for the end customers. But an (for any reason) non-working binary would generally not be detected by the DFU procedure, but needs to be checked by properly testing the binary beforehand.

RE: Bootloader Update with new size over BLE DFU service

Dominik Eugster — Thu, 30 Jun 2022 13:39:29 GMT

[quote userid="7377" url="~/f/nordic-q-a/89484/bootloader-update-with-new-size-over-ble-dfu-service/374895"]Yes[/quote]

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

RE: Bootloader Update with new size over BLE DFU service

Einar Thorsrud — Thu, 30 Jun 2022 11:57:27 GMT

Hi Dominik,

[quote user=""]Is there a possibility to update the bootloader himself over the BLE DFU?[/quote]

Yes.

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

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