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

[Einar Thorsrud]

Dominik Eugster said:

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

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

Dominik Eugster said:

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)

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.

[Dominik Eugster]

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

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

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.

[Einar Thorsrud]

Hi,

Dominik Eugster said:

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.

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.

Dominik Eugster said:

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?

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.

[Dominik Eugster]

great, thanks

[Dominik Eugster]

Einar Thorsrud said:

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.

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?

[Einar Thorsrud]

I did not get this. Can you elaborate?

Dominik Eugster said:

The bootloader will be updated with the zip packet aswell, but the SDK config settings not?

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

[Dominik Eugster]

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