Saving a fota progress is in case the device resets mid-process,

Hi

I am working on FOTA on the nrf9160dk board with ncs2.2.0 and started with the application_update example then I also tried it on the AT2 app. I tested some cases and noticed that a fota process can continue downloading after lte connection break down and recover also it seems any case unless the device is not restarted.  But in a case, if the device is restarted, the fota process does not continue downloading where it left off. I need the application to skip the blocks that are already downloaded

So Can you please shed some light on how I can implement this feature in the application_update or the at2 app.

As I learned from my investigations, 

DFU Library is responsible to write downloaded image data to flash memory, right? image data written in flash memory cannot vanish after reboot, right? 

if so,

according to dfu app flow, I need to invoke this API   dfu_target_offset_get() allows me to ask for the offset of already downloaded blocks. But I do not know what kind of parameters I need to store to start downloading where the app left off after booting. Basically,  I stored an offset data value of 14336 bytes and set it in the code block below in the fota_download.c after booting. So I expected to start downloading at an offset value of 14336 but it did not work.

err = dfu_target_offset_get(&offset);
			if (err != 0) {
				LOG_DBG("unable to get dfu target offset err: "
					"%d", err);
				send_error_evt(FOTA_DOWNLOAD_ERROR_CAUSE_DOWNLOAD_FAILED);
			}
			printk("offfseett1 %d\n", offset);
			offset = 14336;
			if (offset != 0) {
				/* Abort current download procedure, and
				 * schedule new download from offset.
				 */
				(void)download_client_disconnect(&dlc);
				k_work_schedule(&dlc_with_offset_work,
						K_SECONDS(1));
				LOG_INF("Refuse fragment, restart with offset");

				return -1;
			}

Parents Reply Children
  • The fota_download library does not provide an interface to start a download at a offset.

    I am not sure about this. I think there is an inconsistency between your comment and the app's behaviour. Please correct me if I am wrong. It seems fota_lib provides an interface to start a download at an offset. here please have a look at.

    In fota_download.c. After initializing dfu_target_init, checking if there is an offset or not. So if there is an offset, the app aborts the download requests and schedules a new download from the offset.

    You could use the download_client library for this purpose, but you would need to handle writing the chunks to flash.

    Thanks for this point. I need to look at this how I can use and implement this into my app.

    this is in RAM and is lost on reset. 

    yes, I agree, I think this may reason why the device cannot continue downloading process from an offset val after rebooting. 

    I was thinking if I can find a way to store all these data which are necessary to continue from an offset into flash memory. Then after booting up, I can bring all these data for dfu_target_offset_get.

  • Please correct me if I am wrong. It seems fota_lib provides an interface to start a download at an offset. here please have a look at.

    In fota_download.c. After initializing dfu_target_init, checking if there is an offset or not. So if there is an offset, the app aborts the download requests and schedules a new download from the offset.

    Yes I think you are correct actually but that offset logic is only if the download stops and then is restarted during the same session (e.g. no reboot occurs). E.g.

    1. fota_download_init
    2. fota_download_start
    3. * You download some chunks *
    4. fota_download_cancel
    5. fota_download_start

    The way the fota_lib uses the dfu_target stuff makes it really hard to do what you are trying. It relies on metadata from the current session to know where to flash the downloaded chunk.

Related