Bootloader settings backup in SDK 15.1.0

RE: Bootloader settings backup in SDK 15.1.0

Adrian Eggenberger — Mon, 03 Sep 2018 22:05:38 GMT

Hi Aaron

Thanks for the detailed analyzation. I totally agree with your findings and your conclution that the backup needs to be invalidated or written with the download. I adapted your recommendation in my solution and it works perfectly.

Maybe a short addition concerning the halt of the CPU. I don't use this normally, but in this test i used it to stop the cpu to prevent that it starts after programming before i could setup the RTT viewer. It seems to work, but wouldn't use it normally.

Regards Adrian

RE: Bootloader settings backup in SDK 15.1.0

Aaron Nabil — Mon, 03 Sep 2018 18:49:04 GMT

The problem seems to be here:

    
    
    bool settings_valid        = settings_crc_ok();
    bool settings_backup_valid = settings_backup_crc_ok();

    if (settings_valid &&
        settings_backup_valid &&
        !settings_forbidden_parts_equal_to_backup(m_dfu_settings_buffer))
    {
        NRF_LOG_WARNING("Restoring settings from backup since the app has tampered with the "
                        "off-limit parts of the settings page.");
        memcpy(&s_dfu_settings,
               mp_dfu_settings_backup_buffer,
               sizeof(nrf_dfu_settings_t));
    }

IE, you have a valid backup that doesn't match the current settings file. You either need to invalidate it by erasing it or program it at the same time. This seems to work for me, please try it:

    REM program new application and the coresponsing bootloader settings
    .\nrfutil settings generate --application nrf52832_xxaa.hex --family NRF52 --application-version 0 --bootloader-version 0 --bl-settings-version 1 "settings.hex"
    .\nrfutil settings generate  --start-address 0x7E000 --application nrf52832_xxaa.hex --family NRF52 --application-version 0 --bootloader-version 0 --bl-settings-version 1 "settings_backup.hex"
    nrfjprog --sectorerase --program nrf52832_xxaa.hex
    nrfjprog --sectorerase --program settings.hex
    nrfjprog --sectorerase --program settings_backup.hex

RE: Bootloader settings backup in SDK 15.1.0

Aaron Nabil — Mon, 03 Sep 2018 18:24:15 GMT

Note the undocumented change in NRF_DFU_DEBUG in 15.1, it used to just mean "honor debug flag in init packet", now it also means ignore CRC. I reverted it back to the original behavior in my code base.

RE: Bootloader settings backup in SDK 15.1.0

Aaron Nabil — Mon, 03 Sep 2018 18:12:22 GMT

Hi Adrian,

I've just started looking at this, but my first question would be to wonder if it is valid to halt the cpu, reflash the application and then simply resume it again as you do at the end of your batch file. At this point in my flashing routine I restart, not run, the device.

Note that you can avoid the initial backup by flashing a copy of the bootloader settings into the MBR parameter storage area (which is the bootloader settings backup area) at the same time you load the initial image. Apparently the MBR has some kind of magic that distinguishes between bootloader settings backups and MBR commands.

RE: Bootloader settings backup in SDK 15.1.0

Adrian Eggenberger — Mon, 03 Sep 2018 12:49:12 GMT

I've prepared a little test that can reproduce the issue. You can find the required test files an the attached test.zip file. The difference between this reproduced case and my problem case is the NRF_DFU_DEBUG setting. Here in this example it is activated and in my case it's not as I'm not a fan of developing with different settings than the end user will have. Setting NRF_DFU_DEBUG would fix my problem, but if possible I'm looking for a good way to solve it without that.

The test executes the following sequence:
1) Program a bootloader, softdevice and application to a recovered nRF52 DK that has to be connected to the PC
2) At this point a RTT viewer is attached. The attached log_1.txt file shows the output of the RTT viewer. In the log we can see that the bootloader settings are backed up to 0x7E000.
3) Afterwards the nRF52 DK is halted and a new application with the generated correct bootloader settings is programmed.
4) The next restart of the device shows in the log the output of the file log_2.txt. We can see that at the beginning the written new bootloader settings are overwritten by the restore of the backup. A few lines later we come to the place where the application is checked for validity. The output "CRC check of app failed. Return 1" shows that the restored bootloader settings are now surely not matching the written application. The "Return 1" is a result of the activated NRF_DFU_DEBUG that cases in this case that the application is started even if it is invalid. If NRF_DFU_DEBUG is not set it will return 0 and the application is not started (as it is in my case).

I see different options to solve this, but which one is the best. As others may struggle over the same behavior I think the problem should be fixed somehow as it is a new unwanted behavior that may confuse a lot of users.

Regards Adrian

devzone.nordicsemi.com/.../log_5F00_2.txt

devzone.nordicsemi.com/.../2604.test.zip devzone.nordicsemi.com/.../log_5F00_1.txt

RE: Bootloader settings backup in SDK 15.1.0

Aaron Nabil — Sun, 02 Sep 2018 03:15:19 GMT

Can you cut and paste what you are seeing in the log output to this thread and highlight the area of concern?