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

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

Nathan O. — Tue, 26 May 2020 12:17:24 GMT

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.

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

Vidar Berg — Tue, 26 May 2020 12:11:33 GMT

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.

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

Nathan O. — Mon, 25 May 2020 15:39:09 GMT

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 ?

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

Vidar Berg — Mon, 25 May 2020 14:07:47 GMT

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.