nrf52 dfu crc check

RE: nrf52 dfu crc check

Sigurd — Wed, 06 Dec 2017 10:08:06 GMT

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.

RE: nrf52 dfu crc check

Stas — Tue, 05 Dec 2017 14:01:23 GMT

But I did all steps from infocenter There're not any problem besides crc checking after I changed app a lot. and there are not example how to update bootloader OTA

RE: nrf52 dfu crc check

Sigurd — Tue, 05 Dec 2017 13:46:04 GMT

We have the guide I linked to here. Please try to get that working, before we skip the crc checking.

Also take a look at the nrfutil user guide here.

RE: nrf52 dfu crc check

Stas — Tue, 05 Dec 2017 13:41:38 GMT

I'm a little confused about how to do it. What I'm have:

nrf52832 chip.
smartphone with installed nrftoolbox app (but later develop own app used dfu library)
sdk14.2, sd5.1, initially app.

Could you explain me step by step what I must to do for update changed app skipping crc checking by bootloader that in the chip.

RE: nrf52 dfu crc check

Sigurd — Tue, 05 Dec 2017 13:20:42 GMT

You can update the application alone, without updating the bootloader.

At the start of the DFU process, the CRC inside the initpacket is stored in the bootloader settings page. The CRC check is done at the end of the DFU process, where we calculate the CRC of the received FW image, and compare it to the CRC stored in the bootloader settings page at the beginning of the DFU process. This is to ensure the integrity of the image.

RE: nrf52 dfu crc check

Stas — Tue, 05 Dec 2017 02:04:04 GMT

Thanks for so detail answer. I don't have an experience of production products on nrf52832. But I have a fitness watch based on nrf52832 and it's updates app OTA often enough,. As I understand they can do it only with BL update at the same time. If it's true, could you give an example of raw for Bootloader update.

RE: nrf52 dfu crc check

Sigurd — Mon, 04 Dec 2017 13:32:53 GMT

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.