DFU settings page "randomly" gets zeroed --> Application cannot start

RE: DFU settings page "randomly" gets zeroed --> Application cannot start

Hung Bui — Fri, 07 Feb 2020 09:18:29 GMT

Hi Mike,
I agree that there isn't much reason the NRF_DFU_SETTINGS_VERSION should be in the preprocessor symbols. I will report this internally.
Please let me know if you have any further question.

RE: DFU settings page "randomly" gets zeroed --> Application cannot start

m.wagner — Thu, 06 Feb 2020 16:03:33 GMT

Hi Hung Bui

Thanks for the response. As mentioned in the original post, we are using SDK 15.3. We upgraded at some point and in the course did not update the preprocessor defines for the compiler where NRF_DFU_SETTINGS_VERSION is set.

I don't see why NRF_DFU_SETTINGS_VERSION is not hardcoded in the dfu settings c-file? As the implementation does not support any other version than two, there is no reason to have it "hidden" in the project settings!

The wrong NRF_DFU_SETTINGS_VERSION does indeed lead leads to these lines changing the bootloader settings upon every reboot, requiring it to be erased and rewritten.

memcpy(&s_dfu_settings.peer_data, (uint8_t *)&s_dfu_settings + DFU_SETTINGS_BOND_DATA_OFFSET_V1, NRF_DFU_PEER_DATA_LEN);
memcpy(&s_dfu_settings.adv_name,  (uint8_t *)&s_dfu_settings + DFU_SETTINGS_ADV_NAME_OFFSET_V1,  NRF_DFU_ADV_NAME_LEN);

Without the backup page this leads to irrecoverable failure when the device loses power or gets reset between the erase and the completion of the write.

Regards,

-mike

RE: DFU settings page "randomly" gets zeroed --> Application cannot start

Hung Bui — Thu, 06 Feb 2020 15:51:59 GMT

Hi Michael,

Could you let me know the SDK version you are using ? If you are using SDK v15.3 and above the NRF_DFU_SETTINGS_VERSION should be set to 2. It's by default defined in the pre-processor symbols in the project setting of the bootloader project.

You should use newer nrfutil, the current version is v6.0

The bootloader flash protect is performed via the call ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR, BOOTLOADER_SIZE, false); in main.c

RE: DFU settings page "randomly" gets zeroed --> Application cannot start

m.wagner — Thu, 06 Feb 2020 14:43:48 GMT

Upon further examination, I noticed that the bootloader executes the following lines of Code in nrf_dfu_settings.c:

if (NRF_DFU_SETTINGS_COMPATIBILITY_MODE && !NRF_DFU_IN_APP && (s_dfu_settings.settings_version == 1))
{
    NRF_LOG_INFO("Old settings page detected. Upgrading info.");

    // Old version. Translate.
    memcpy(&s_dfu_settings.peer_data, (uint8_t *)&s_dfu_settings + DFU_SETTINGS_BOND_DATA_OFFSET_V1, NRF_DFU_PEER_DATA_LEN);
    memcpy(&s_dfu_settings.adv_name,  (uint8_t *)&s_dfu_settings + DFU_SETTINGS_ADV_NAME_OFFSET_V1,  NRF_DFU_ADV_NAME_LEN);

    // Initialize with defaults.
    s_dfu_settings.boot_validation_softdevice.type = NO_VALIDATION;
    s_dfu_settings.boot_validation_app.type        = VALIDATE_CRC;
    s_dfu_settings.boot_validation_bootloader.type = NO_VALIDATION;
    memcpy(s_dfu_settings.boot_validation_app.bytes, &s_dfu_settings.bank_0.image_crc, sizeof(uint32_t));

    s_dfu_settings.settings_version = NRF_DFU_SETTINGS_VERSION;
}

but the value for NRF_DFU_SETTINGS_VERSION is actually 1. So this check seems to always be true and it looks like the bootloader settings page gets rewritten every time the device boots! Since no bootloader settings backup page is available, if the power cuts during the erase/write procedure, the application won't boot again.

I use nrfutil 3.5.1 to generate the settings page.

I assume, that I have to

use a newer nrfutil
actually generate a backup page in the original image
set NRF_DFU_SETTINGS_VERSION to the value that the bootloader should actually use (for sure not to 1!)

EDIT:

Additionally, I found out that the check in settings_write() in nrf_dfu_settings.c which should prevent the bootloader settings page from being rewritten if not necessary, will get rewritten nonetheless because for whatever reason, some values change between reboots.

The following screenshot shows on the left side the bootloader settings page as it is in flash and on the right side the s_dfu settings struct as it is in rame when settings_write is executed. There is only one reboot inbetween and there was no DFU activity whatsoever. As you can see. peer_data.crc and peer_data.irk as well as the adv_name values changed. Why? To me, it looks like there is some strange memory corruption bug here, but I can't pinpoint where and why it happens.