nrf52 dfu crc check

[Stas]

I use buttonless_dfu_app as template. SDK 14.2

Q1. Could someone help me.. After I updated my app I have changed crc (if more than just few changes), so bootloader installed into board from first dfu doesn't allow me to update app (can't accept crc). I've only found hard way to skip it

I'm sorry I don't learn bootloader routine a lot, so my question is how much risks to get the brick from my chip after some updates at end user by OTA DFU.

Q2. I understand that we can update app + sd + bl every update. But I can't find any manuals how to update BL + SD by OTA. I found some short info on GITHUB

but there're are not any of example of raw containes BL+SD (and separately) update OTA Should we generate package for pack sd+bl to there. Or should we pick just sd.hex, bl.hex from our app on smartphone? Could someone write me example raw for DFU softdevice 5.1.0, bootloader.

Q3. We can read firmware by execute command "nrfjprog --readcode flash_dump.hex" How can I protect my app by turning this ability off?

Thanks

[Sigurd]

Hi,

Q1 )

You can make nrf_dfu_app_is_valid() always return true for some testing, but this is dangerous and should not be used in an end product. I recommend you to go back and debug this issue so that there is no chance of accidentally forgetting to fix this before going into production. The reason is that in case there is no valid application, and the nrf_dfu_app_is_valid() still returns true, the bootloader will branch to the start address of the faulty or non-existing application. This would effectively brick the device in a buttonless configuration, where there is no way to force a DFU upgrade by pushing a button during reset. In this case, the only way to recover is by means of a debugger.

The bootloader uses the bootloader settings page for checking if the application is present and to check if the application is the correct one. You can generate a bootloader settings page using nrfutil, but the bootloader settings page will also be written if you perform DFU. For debugging purposes only, you can (in addition to the bootloader settings page) use a bootloader that does not check the CRC of the application. The CRC changes every time you change the application, which is happening a lot while debugging. The bootloader CRC check is in nrf_dfu_utils.c, in the function nrf_dfu_app_is_valid(), and looks like this:

if (s_dfu_settings.bank_0.image_crc != 0)
{
    uint32_t crc = crc32_compute((uint8_t*) CODE_REGION_1_START,
                                 s_dfu_settings.bank_0.image_size,
                                 NULL);

    if (crc != s_dfu_settings.bank_0.image_crc)
    {
        // CRC does not match with what is stored.
        NRF_LOG_DEBUG("Return false in CRC");
        return  false;
    }
}

I suggest adding the lines "#ifndef DISABLE_CRC_CHECK" before and "#endif" after the above section of code, and set a DISABLE_CRC_CHECK preprocessor define in order to disable CRC checking. Then use the bootloader with disabled CRC checking when debugging the application. (You can of course choose another name for the define, in order to make it perfectly clear that the define is intended for development builds only. For instance you can combine it with DEBUG so that it only can be omitted for debug builds.)

Q2)

Take a look at this DFU guide. At the end of the guide we have the following:

The following code will generate a softdevice + application combination:

nrfutil pkg generate --hw-version 52 --application-version 1 --application application.hex --sd-req 0x98 --softdevice softdevice.hex --key-file private.key app_dfu_package_softdevice.zip

Q3)

In the nRF52832 we have something called readback protection that prevents a someone to use a debugger to read the flash and RAM. You can enable readback protection of the device by writing '00' to the APPROTECT register. You can also do this with our tool nrfjprog:

nrfjprog -f nrf52 --rbp ALL && nrfjprog --pinreset -f nrf52

Setting APPROTECT "disconnects" the ability to connect with a programmer/debugger, but it still allows the microcontroller to access its own flash and RAM area. See this whitepaper.

The only way to 'reopen/unlock' the device after APPROTECT is set, is to issue an ERASEALL command through the CTRL-AP access port, and then issue a reset through the CTRL-AP. (nrfjprog --recover). This will erase the entire code flash and UICR area of the device, in addition to the entire RAM.

[Sigurd]

Are you just flashing you application with a programmer, or are you sending the new application with OTA-DFU ?

When you are flashing your new application to the nRF5x with a debugger/programmer, the current bootloader settings page is not updated automatically. So the CRC will not match, and the bootloader will not start the new application. In that case, you need to generate new bootloader settings page based on the new application every time you build a new application. Then merge this new settings page with your new application, and then flash over the new merged hex to the nRF5x. See this page and this page. If you don’t want to create a new bootloader settings page +merge it every time you flash a new application, you can bypass this(skip crc check), with the workaround I suggested in Q1.

If you are not flashing the new application with a programmer(SWD), but doing OTA-DFU, then the bootloader settings page CRC field should be updated automatically with the CRC of the new application that is received.