OFF CHIP OTA UPDATE using external flash

[Priyesh Shahi]

I am working on this project off chip ota update on nRF5_SDK  using ecample/thread/dfu

by now, i have done changes in these functions on_data_obj_create_request() and on_data_obj_write_request(). initially these functions were erasing and writing data in internal flash which I changed to qspi functions like nrf_drv_qspi_erase() and nrf_drv_qspi_write(). and it works perfectly.

Later i changed functions for hash verification which is also working but i am not sure about what should be the next step so that bootloader changes the earlier application with the new firmware image.

[Vidar Berg]

Hello,

Does your bootloader not fall back to the old application when the CRCs don't match?

[Priyesh Shahi]

Yes, it does. However, The firmware version changes, and when I attempt to restart my device, it fails within the app_is_valid() function while executing the boot_validate() function. I've been investigating the cause and noticed that during the execution of this code segment:

// Postvalidate if DFU has signaled that update is ready.
if (s_dfu_settings.bank_current == NRF_DFU_CURRENT_BANK_1)
{
postvalidate();
}
#endif

The firmware version and s_dfu_settings.boot_validation_app are updated within the postvalidate_app() function.

memcpy(&s_dfu_settings.boot_validation_app, &boot_validation, sizeof(boot_validation));

s_dfu_settings.app_version = p_init->fw_version;

// The is_trusted argument specifies whether the function should have side effects.
static bool postvalidate_app(dfu_init_command_t const * p_init, uint32_t src_addr, uint32_t data_len, bool is_trusted)
{
    boot_validation_t boot_validation;

    ASSERT(p_init->type == DFU_FW_TYPE_APPLICATION);

    if (!boot_validation_extract(&boot_validation, p_init, 0, src_addr, data_len, VALIDATE_CRC))
    {
        return false;
    }
#if !NRF_DFU_IN_APP
    else if (NRF_BL_APP_SIGNATURE_CHECK_REQUIRED &&
             (boot_validation.type != VALIDATE_ECDSA_P256_SHA256))
    {
        NRF_LOG_WARNING("The boot validation of the app must be a signature check.");
        return false;
    }
#endif

    if (!is_trusted)
    {
        return true;
    }

    memcpy(&s_dfu_settings.boot_validation_app, &boot_validation, sizeof(boot_validation));

    s_dfu_settings.bank_1.bank_code = NRF_DFU_BANK_VALID_APP;

    NRF_LOG_DEBUG("Invalidating old application in bank 0.");
    s_dfu_settings.bank_0.bank_code = NRF_DFU_BANK_INVALID;

    if (!DFU_REQUIRES_SOFTDEVICE && !update_requires_softdevice(p_init))
    {
         // App does not need SD, so it should be placed where SD is.
         nrf_dfu_softdevice_invalidate();
    }

    if (!NRF_DFU_DEBUG ||
                (NRF_DFU_DEBUG && (p_init->has_is_debug == false || p_init->is_debug == false)))
    {
        s_dfu_settings.app_version = p_init->fw_version;
    }

    return true;
}

[Vidar Berg]

This suggests that the bank0.crc value in bt settings may have been updated (assuming you're using CRC validation (default)). The bootloader will verify the compute the CRC of the application to verify the integrity of the app image before booting. You also need to revert the app version number.

[Priyesh Shahi]

Should I save these values in external flash and reset them when encountering the same error? Or is there another method to retrieve the previous settings?

[Vidar Berg]

It seems it would be easier to back up the original settings to RAM. However, it's a bit surprising that you encounter occasional CRC errors in your copy routine. The image in bank 1 is validated by the post-validate function before the activation takes place.