Using BLE OTA DFU to update the Bootloader itself

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Mon, 27 Jun 2022 21:55:41 GMT

When I read with nrfjprog instead of J-flash I still get 9B01601A at 0xFF8. I didn't think we were calling err_code = sd_power_gpregret_clr(0, 0xffffffff); from an elevated interrupt priority. It appears to be from a normal thread within FreeRTOS using FreeRTOS task priority 1, which in FreeRTOS context is the lowest priority task. I don't know how to look up what hardware interrupt priority this corresponds to.

We will need to update the bootloader in our units in the field so we can use secure firmware updates going forward, so jumping to the bootloader from the application won't solve for our long term need of security, just the short term desire to update the end application firmware more than once. Since the private key to do this is not available from Nordic, I think we will just have to call this issue as "closed, won't fix" and we will need to send someone out to open up the cases on our thousand units in the field so we can erase the chip and start over.

RE: Using BLE OTA DFU to update the Bootloader itself

Sigurd — Mon, 27 Jun 2022 08:38:31 GMT

Hi,

[quote user="idavenport"]I get a hard fault in nrf_soc.h at line 621:
SVCALL(SD_POWER_GPREGRET_CLR, uint32_t, sd_power_gpregret_clr(uint32_t gpregret_id, uint32_t gpregret_msk));

which is an expansion from my new TestForDfuButtonReboot(void)
line:
err_code = sd_power_gpregret_clr(0, 0xffffffff);[/quote]

Are you calling it from a interrupt handler? Note that you can only call the SoftDevice API from application interrupt priority 5 and lower: https://infocenter.nordicsemi.com/topic/sds_s113/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html

[quote user="idavenport"]the address in the MBR at 0FF8 appears to be 9B01601A which doesn't seem to be a valid address.[/quote]

Do you seem the same if you do read it out using nrfjprog ?

nrfjprog --memrd 0xFF8

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Sat, 25 Jun 2022 22:02:21 GMT

I get a hard fault in nrf_soc.h at line 621:
SVCALL(SD_POWER_GPREGRET_CLR, uint32_t, sd_power_gpregret_clr(uint32_t gpregret_id, uint32_t gpregret_msk));

which is an expansion from my new TestForDfuButtonReboot(void)
line:
err_code = sd_power_gpregret_clr(0, 0xffffffff);

Although in the hex readout of the device I am debugging, the address in the MBR at 0FF8 appears to be 9B01601A which doesn't seem to be a valid address.

:200FE00004FB00B583B00190019B002B0ED0019B00225A60019B00221A60019B0022DA602C

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Sat, 25 Jun 2022 02:46:20 GMT

We updated that in the bootloader thinking we could update the bootloader. The sdk_config.h used to create the bootloader that is in the field is here since I can't seem to upload more files after opening a ticket:

drive.google.com/.../view

That sdk_config.h had:

//==========================================================
// <e> NRF_BL_DFU_ENTER_METHOD_BUTTON - Enter DFU mode on button press.
//==========================================================
#ifndef NRF_BL_DFU_ENTER_METHOD_BUTTON
#define NRF_BL_DFU_ENTER_METHOD_BUTTON 1
#endif

...and...
#ifndef NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN
#define NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 25
#endif

We did have:

// <q> NRF_BL_DFU_ENTER_METHOD_GPREGRET - Enter DFU mode when bit 0 is set in the NRF_POWER_GPREGRET register.

#ifndef NRF_BL_DFU_ENTER_METHOD_GPREGRET
#define NRF_BL_DFU_ENTER_METHOD_GPREGRET 1
#endif

// <q> NRF_BL_DFU_ENTER_METHOD_BUTTONLESS - Enter DFU mode when the Boolean enter_buttonless_dfu in DFU settings is true.

#ifndef NRF_BL_DFU_ENTER_METHOD_BUTTONLESS
#define NRF_BL_DFU_ENTER_METHOD_BUTTONLESS 0
#endif

I tried adding your suggested code. It build and runs, I have to look up how to debug into a bootloader plus application again without the settings flash sectors getting out of synch. It seems to go right back into the application and I fear that the old bootloader is being vectored to from inside the app and then that the bootloader may just be jumping right back into the app.

void
TestForDfuButtonReboot(void)
{
uint32_t err_code;
if ((nrf_gpio_pin_read(8) == 0)) {

err_code = sd_power_gpregret_clr(0, 0xffffffff);
APP_ERROR_CHECK(err_code);

err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
APP_ERROR_CHECK(err_code);
//now reboot to send the CPU into the bootloader which is a
//separately compiled application
sd_nvic_SystemReset();
}
}

RE: Using BLE OTA DFU to update the Bootloader itself

Sigurd — Fri, 24 Jun 2022 13:32:29 GMT

Hi,

[quote user=""]I have attached a link to our zipped repo of the modified DFU example.
The modified DFU example code is here: [/quote]

Looking at your code, you seem to have changed NRF_DFU_REQUIRE_SIGNED_APP_UPDATES from default 1, to 0, this means that Application update may come from an unsigned package. Bootloader update must come from signed packages.

[quote user="idavenport"]Is the private key available for experimentation with the default example? [/quote]

As far as I can see, this key is not provided.

How does the bootloader's sdk_config.h file look like for the devices you have in field? You might not need to update the bootloader to do this. You seem to have NRF_BL_DFU_ENTER_METHOD_BUTTON set to 1, with button 8 being used to enter DFU mode. Snippet:

#ifndef NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN
// Original pin for the dev kit:
// #define NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 25
//
// This is the 'PANIC' switch on HDT_NG, P0.08. It is active low when button
// pressed.
//
// We have not implemented the full-on multi-platform support here as we did
// in the HDT_NG code.
#define NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 8
#else
#warning "NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN already defined!"
#endif

So that is one method.

You also have:

// <q> NRF_BL_DFU_ENTER_METHOD_GPREGRET  - Enter DFU mode when bit 0 is set in the NRF_POWER_GPREGRET register.
#ifndef NRF_BL_DFU_ENTER_METHOD_GPREGRET
#define NRF_BL_DFU_ENTER_METHOD_GPREGRET 1
#endif

So you can call this in the application code:

    uint32_t err_code;

    err_code = sd_power_gpregret_clr(0, 0xffffffff);
    APP_ERROR_CHECK(err_code);

    err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
    APP_ERROR_CHECK(err_code);

And call sd_nvic_SystemReset(), and on reset it will then enter DFU mode. This is the same mechanism that the Butonless DFU service uses.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Thu, 23 Jun 2022 06:09:20 GMT

Where can I find the documentation on the difference between using --application vs. --bootloader in nrfutil? The user's guide for nrfutil https://infocenter.nordicsemi.com/pdf/nrfutil_v6.1.0.pdf only mentions the switch in the context of generating bootloader settings pages. I do see a sentence here:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Flib_bootloader.html

"Note that bootloaders are always checked when they are updated."

That suggests even if I have signature check turned off for the application the bootloader will still be checked.

Or perhaps you just have to dive into the code for nrfutil in https://github.com/NordicSemiconductor/pc-nrfutil to know how -bootloader and --application are different?

The only documentation I can find on --bootloader for nrfutil is the paragraph that says it exists in:

infocenter.nordicsemi.com/index.jsp

You can add the following firmware images in binary or hexadecimal format to the zip file:

--application image: an image of an application
--bootloader image: an image of a bootloader
--softdevice image: an image of a SoftDevice

Is it correct to assume that in sdk_config.h #define NRF_BL_APP_SIGNATURE_CHECK_REQUIRED 0 does not apply when updating the bootloader itself?

We used the default public key in our bootloader because we thought we had signing turned off. It sounds like we do for the application, which is why --application allows us to upload (albeit to the wrong memory location) and --bootloader does not. In order for us to try --key-file key.pem signing, it sounds like we would need the key.pem that Nordic used to generate the dfu_public_key.c that is compiled into our bootloader that we thought had signing turned off for applications and bootloader images.

The public key in the example dfu_public+_key.c we used starts with: 0x35, 0x7f, 0x66, 0xa3, 0x96, 0xf2,

I don't see that "throwaway key" as it is called in the sdk.

/* This file was generated with a throwaway private key, that is only inteded for a debug version of the DFU project.
Please see github.com/.../README.md to generate a valid public key. */

Is the private key available for experimentation with the default example?

RE: Using BLE OTA DFU to update the Bootloader itself

mrono — Thu, 23 Jun 2022 05:50:47 GMT

[quote userid="46136" url="~/f/nordic-q-a/88931/using-ble-ota-dfu-to-update-the-bootloader-itself/373792"]Is there a separate setting for removing the encryption requirement from --application updates vs. --bootloader updates?[/quote]

I had to check this. The function signature_required() looks like this:

// Function determines if init command signature is obligatory.
static bool signature_required(dfu_fw_type_t fw_type_to_be_updated)
{
    bool result = true;

    // DFU_FW_TYPE_EXTERNAL_APPLICATION and bootloader updates always require
    // signature check
    if ((!DFU_REQUIRES_SOFTDEVICE && (fw_type_to_be_updated == DFU_FW_TYPE_SOFTDEVICE)) ||
            (fw_type_to_be_updated == DFU_FW_TYPE_APPLICATION))
    {
        result = NRF_DFU_REQUIRE_SIGNED_APP_UPDATE;
    }
    return result;
}

So it looks like bootloader updates always require signing.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Wed, 22 Jun 2022 21:23:11 GMT

We were able to update/upload our main application without having to use a key file. Is there a separate setting for removing the encryption requirement from --application updates vs. --bootloader updates?

RE: Using BLE OTA DFU to update the Bootloader itself

Sigurd — Wed, 22 Jun 2022 13:34:29 GMT

Hi,

[quote user="idavenport"]When I use SES to flash the new bootloader 0.0.01, and then try to load the bootloader package I built with the --application flag, the debug output shows this loop:[/quote]

I'm not sure if this makes sense. Are you trying to update the bootloader like it was an app?

[quote user="idavenport"]

When I use SES to flash the new bootloader 0.0.01, and then try to load the bootloader package I built with the --bootloader nrfutil flag instead of the --application flag, the debug output shows:

<info> nrf_dfu_validation: Signature required. Checking signature.
<warning> nrf_dfu_validation: No signature found.
<warning> nrf_dfu_validation: Prevalidation failed.

[/quote]

Seems like you are missing the private (signing) key when generating the DFU package. Try adding this to your "nrfutil pkg generate" command:

--key-file key.pem

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Wed, 22 Jun 2022 07:13:34 GMT

When I use SES to flash the new bootloader 0.0.01, and then try to load the bootloader package I built with the --bootloader nrfutil flag instead of the --application flag, the debug output shows:

<info> nrf_dfu_validation: Signature required. Checking signature.
<warning> nrf_dfu_validation: No signature found.
<warning> nrf_dfu_validation: Prevalidation failed.

When I use SES to flash the new bootloader 0.0.01, and then try to load the bootloader package I built with the --application flag, the debug output shows this loop:

<info> app: main(): BLE DFU Version 0.0.01
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<info> app: main(): BLE DFU Version 0.0.01
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Bac
<info> app: main(): BLE DFU Version 0.0.01

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Tue, 21 Jun 2022 04:54:32 GMT

From the attached hex file In_The_Field-Production_Unit_Readback.hex. I assume that the bytes for a 32 bit absolute address are in reverse order and that the address at 0X0FF8 in hex below is our intended address of 0x00071000.

:200FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0010070000E007000B

Looking at NRF_UICR->NRFFW[0] (0x10001014) from the same in the field readback of hex file the address appears to be unwritten and all 0xFFs. I assume this doesn't matter as I saw in the documentation that the MBR jumps first to the address specified at 0x0FF8 and ignores the address in the NRFFW[0] slot if an address is held in the MBR at 0x0FF8.

:020000041000EA
:20100000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0

We lowered the bootloader start address from 0x78000 to 0x71000 to make room for uECC.

When I try to update the bootloader only, packaging using nrfutil with the following syntax

nrfutil pkg generate --debug-mode --hw-version 52 --application-version 1 --application $DFU_DBG_EXE $DFU_DBG_APP_FILE

The hex that I read out from the device, which no longer will advertise, has what I believe to be the original bootloader in its original location of 0x71000 and the new bootloader written at 0x1C000 instead of at 0x71000 as is specified in the hex file that nrfutil zipped up. The unit no longer advertises as it would if I had written the new bootloader with SES instead of doing an OTA update. The NRF_UICR->NRFFW[0] (0x10001014) location is still all 0xFFs.

When I take a unit that has the old production bootloader in it at 0x71000 and try to do an OTA DFU with the nrfutil syntax changed to use --bootloader $DFU_DBG_EXE instead of --application $DFU_DBG_EXE, the failure mode is different. The unit still advertises the BLE advertising name of the old bootloader (DfuTarg) and the hex that I read out is unchanged. I also see no progress bar in nrf connect for android so I assume some kind of validation on upload of the new bootloader failed.

I have not brought back the old commit for the Bootloader that is in the field, so I can debug into it to get an RTT log.

We are using SDK version 17.0.2.

RE: Using BLE OTA DFU to update the Bootloader itself

Sigurd — Mon, 20 Jun 2022 08:01:40 GMT

Hi,

1) What values do you read from 0x0FF8 and NRF_UICR->NRFFW[0] (0x10001014). These should hold the start address of the bootloader and never change.

2) Since you are using the debug version of the bootloader, which has RTT logging enabled by default. Could you get the RTT log and upload it here?

3) Which SDK version are you using?

[quote userid="46136" url="~/f/nordic-q-a/88931/using-ble-ota-dfu-to-update-the-bootloader-itself/372461"]I would assume we could leave the MBR and Softdevice in there, and just update the bootloader itself. Is that not possible?[/quote]

That is possible.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Sat, 18 Jun 2022 00:53:28 GMT

I see that back in version 14 of the sdk, you needed to specify if the hex file you were packagin into a DFU .zip was a --bootloader or --application or --softdevice.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fble_sdk_app_dfu_bootloader.html

It seems that more modern examples always use --application and I can not find documentation on how to use the --bootloader command/option.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Wed, 15 Jun 2022 04:35:57 GMT

We also have the same version for our custom bootloader. Do I need to roll the version number somewhere to get past a no-downgrade test? I don't think we have downgrade prevention turned on, but I don't know where to look to find out.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Wed, 15 Jun 2022 04:33:17 GMT

I don't think we can use buttonless Secure DFU without updating the bootloader. I assume that if we just detect the button is down as we boot into our HDT app and jump to the bootloader on that condition, the bootloader will just jump right back into our HDT app because it knows there is a valid app at the prescribed address.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Wed, 15 Jun 2022 04:29:55 GMT

The app works as expected when the bootloader is present and when the bootloader is not present. Our issues are just with getting the bootloader to update the bootloader itself.

RE: Using BLE OTA DFU to update the Bootloader itself

idavenport — Wed, 15 Jun 2022 04:23:46 GMT

We actually have the larger bootloader expanded and using uECC in the units in the field. That bootloader works. Well it will work once and then forever jump to the installed app. So we are not trying to change the size of the bootloader from what is already in the target hardware. I would assume we could leave the MBR and Softdevice in there, and just update the bootloader itself. Is that not possible?

RE: Using BLE OTA DFU to update the Bootloader itself

Sigurd — Tue, 14 Jun 2022 09:07:39 GMT

Hi,

[quote user=""]the update appears to work, but the new advertising name does not show up,[/quote]

Does the app work as expected when the bootloader is not present?

[quote user=""]Our issue is that we have a thousand units in the field with just the bootloader and no app in them. We can add the app once, but then we can never update it again because the DFU will always jump to the app after that. So we want to update the custom bootloader we put in there to our new custom bootloader that will jump to DFU if a button is held down at boot. We can make this work when programmed with a J-link, but we can't do it over the air which means we would need to open the cases of the 1000 units in the field that contain just the bootloader and use a Jlink and a cable to update the bootloader.
[/quote]

We have support for buttonless DFU as well. You can use the Buttonless Secure DFU Service to jump from the app to the bootloader. See this example: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/ble_sdk_app_buttonless_dfu.html

RE: Using BLE OTA DFU to update the Bootloader itself

mrono — Tue, 14 Jun 2022 07:53:13 GMT

You don't need to include the bootloader settings page to the DFU package. The settings page is only needed if you flash the binary to the target with a programmer.

The other issue is the bootloader start address. The one thing you can't do using DFU is to change the size of the bootloader. I'm not sure if there are workarounds to this, but I believe it is not supported.