Unable to enter bootloader after flashing new firmware with Segger Embedded Studio

[Nathan O.]

Hi,

I am working on a product based around an nRF52832 (SDK 15.3, S112 v6.1).

I am using the Secure Bootloader and I have a script that is used to merge hex files and handle bootloader settings :

:: Generate bootloader settings
nrfutil settings generate --family NRF52 --application firmware.hex --application-version 0x43 --bootloader-version 0 --bl-settings-version 2 "bootloader_setting.hex"
:: Merge bootloader and SD
mergehex.exe --merge bootloader.hex softdevice.hex --output bootloader_sd.hex
:: Merge bootloader, settings and SD
mergehex.exe --merge "bootloader_setting.hex" "bootloader_sd.hex" --output "bootloader_sd_settings.hex"
:: Merge all + firmware
mergehex.exe --merge "bootloader_sd_settings.hex" "firmware.hex" --output "firmware_with_bootloader.hex"
:: Sign firmware into zip file
nrfutil.exe pkg generate --key-file private_key.pem --hw-version 52 --sd-req 0xB8 --application firmware.hex --application-version 0x43 "firmware_signed.zip"

Currently if I flash the firmware_with_bootloader.hex with J-flash lite I get everything working on the device. I can enter Bootloader mode, flash a new firmware with the zip file : all good.

For development, I use Segger Embedded Studio.

If I flash a new version of the firmware using Segger Embedded Studio, then the Bootloader becomes unavailable : when I try entering bootloader mode, the firmware just restarts without entering Bootloader mode.

Is it possible that Segger Embedded Studio erases some flash section on the nRF52 that is needed to get into bootloader mode and stay there ?

EDIT: After investigation, it seems that the bootloader address, stored at 0xFF8 is erased to 0xFFFFFFFF when I flash with Segger Embedded Studio. Probably something to dig into.

Regards.

[Vidar Berg]

Hi,

In SDK 15.3.0 we started to store the bootloader start address inside the MBR section at 0xFF8+0xFFC instead of using the UICR as we had done before. The motivation was to have the parameters placed in the main flash region that can be protected by the BPROT/ACL peripheral (ACL is not available on 52832). Unfortunately, this change made it very easy to inadvertently erase the address settings. E.g., if you re-programmed the Softdevice after programming the bootloader. And this is actually what happens when you use SES. It automatically loads the Softdevice hex along with the application hex so the bootloader start address gets erased when you program the app project.

One way to avoid this is to disable the automatic programming of the Softdevice as shown in the screenshot below.

We did fix this in SDK 16.0.0 by letting the bootloader store the settings inside the MBR at runtime. The change described in the SDK release notes:

Bootloader start address is now placed in UICR at compile time, and the MBR page is
populated at runtime. This is to mitigate problems with flashing
where the MBR was erased.

[Nathan O.]

Thanks for the response.

I have tried your proposition :

I erased all flash on my device, flashed again the hex file containing everything (Bootloader, settings, softdevice and firmware). After that I used SES to flash my device with the firmware only (after removing the softdevice from the Loader settings). The device then restart into bootloader mode and stays there.

It seems the bootloader is not able to detect the new firmware flashed with SES. Is there anything I have missed ?

Should I also re-regenerate a bootloader settings page everytime I update my firmware from SES ?

EDIT : I confirm that this restart in bootloader mode and getting stuck only occurs if the firmware I am trying to flash with SES is different than the one from the merge hex file. Maybe there is a checksum stored somewhere ?

EDIT2: Ok so it seems that's it : When starting, the bootloader computes a CRC over the firmware stored in bank 0. After I flash a new version with SES, the checksum fails (obviously).

If I modify the crc_on_valid_app_required function like this, the firmware starts without problem and I can flash new firmwares with SES without any problem :

static bool crc_on_valid_app_required(void)
{
    bool ret = true;
    if (NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET &&
        (nrf_power_resetreas_get() & NRF_POWER_RESETREAS_OFF_MASK))
    {
        nrf_power_resetreas_clear(NRF_POWER_RESETREAS_OFF_MASK);
        ret = false;
    }
    else if (NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 &&
            ((nrf_power_gpregret2_get() & BOOTLOADER_DFU_GPREGRET2_MASK) == BOOTLOADER_DFU_GPREGRET2)
            && (nrf_power_gpregret2_get() & BOOTLOADER_DFU_SKIP_CRC_BIT_MASK))
    {
        nrf_power_gpregret2_set(nrf_power_gpregret2_get() & ~BOOTLOADER_DFU_SKIP_CRC);
        ret = false;
    }
    else
    {
        // Change here
        ret = false;
    }

    return ret;
}

I have looked at the bootloader settings and there does not seem to be any option to skip entirely the CRC check on boot. NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET and NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 do not seem to be what I want. Any recommendations ? How are people usually doing it ?

Without the code change in the bootloader, I am able to load a new firmware if I generate (with nrfutil) a new bootloader settings page and flash it after the firmware. with J-flash Lite. Not very practical. Maybe I could automate the generation of the settings page and load it as part of the SES flash process ?

[Vidar Berg]

SES lets you add custom post-build steps that you can use to automate the generation of the settings page. However, there is also an option to select no boot validation when you generate the settings page. So another easier option could be to create a settings page to use during development which has boot validation of the application disabled. This settings page can be loaded automatically like we do with the Softdevice.

[Nathan O.]

Thank you.

I have setup post-build command to generate and load the bootloader settings page (see https://devzone.nordicsemi.com/f/nordic-q-a/34212/howto-flash-bootloader-settings-for-dfu-using-ses-at-debug-time).

The ability to disable the checksum validation in the settings page is actually quite interesting. I might switch to this solution instead of the post-build commands then.