How to know when FOTA Download is interrupted

[SteveLaser]

I have been testing with the following setup:
Bundle: Full modem install.
Modem version: 1.3.4
SDK: 2.4.0
My application is based on the SLM sample.


Problem Part 1)
When I purposely disrupt my internet connection during a FOTA download (by removing my antenna) my application gives the following output, and then does nothing (I let it hang for 10 minutes to see if anything happens).
It does not try again, and it does not throw some sort of FOTA error. Obviously, I need to be able to see if a FOTA download has been interrupted by a bad internet connection, so I can handle it properly. It produces no further messages.
I was expecting some sort of timeout (there is none), or a retry (did not occur), or a cloud/FOTA callback event (also does not seem to occur), or at least some log messages



Problem Part 2)
After the above disruption, I restart my device and reconnect to the cloud with nrf_cloud_connect(), as usual.
I expected it would go and attempt to download the same FOTA image. But it did not. The cloud indicates "downloading", like this below, but the interrupted firmware update is now completely ignored. I can make a new one, and it will work, but the old one seems "dead".

[helsing]

Hi Stephen,

Thank you for the questions, we have started looking into this.

[SteveLaser]

Thanks for your help.

[helsing]

Hi Stephen, sorry for the delay. I hope to be able to get back to you soon.

[benna]

Hi there, 

I'm having a similar issue. I get the above failures, and eventually it will run out of retry counts.
When this happens, no fota_download_evt is emitted. Leaving my application to wait forever (until a watchdog finally times out).

Not sure about this, but it seems that the download_client_callback in fota_download.c is missing a call to stopped() in the error_and_close section:

error_and_close:
    atomic_clear_bit(&flags, FLAG_RESUME);
    (void)download_client_disconnect(&dlc);
    dfu_target_done(false);
    // Shouldn't we call stopped() here to transmit the error?
    return -1;

If I should open a separate issue for this, please let me know.

[helsing]

Hi Stephen, sorry for the long delay.

Here is the feedback from our developers:

Regarding part 1):

There is an automatic retry mechanism as can be seen from the screenshot of the logs (2 retries left...). However if retrying doesn't help SLM should report an error. Here is the result from a test I just performed where I put the modem to flight mode in the middle of the download:

#XFOTA: 1,0,0

 

#XFOTA: 1,0,1

 

#XFOTA: 1,0,2

 

#XFOTA: 1,0,2

 

#XFOTA: 1,0,3

 

#XFOTA: 1,0,4

 

#XFOTA: 1,0,5

 

#XFOTA: 1,0,5

 

#XFOTA: 1,0,6

 

#XFOTA: 1,0,7

 

#XFOTA: 1,1,2

The error is reported correctly with the last line of output.

This is with application FOTA, but I tested with the other types (delta modem, full modem) and just the same happens.

In your screenshot, is there no log after the last line, Connecting to [...]? A timeout is expected.

Would you be able to try the latest nRF Connect SDK release, v2.5.2, and at the same time could upgrade the MFW to v1.3.5? Our developers have recently made some small fixes that I think have been backported to the latest 2.5 release.

Regarding part 2)

There seems not to be any support for FOTA auto-restart after any kind of failure in the libraries used(and especially not after a restart). Starting over with a new FOTA operation is the way to go as of now. Also in the example case showed above. The one case where there is pause/resume functionality is when using AT#FOTA=0 during an ongoing download.

We would have to look further into the cloud related part of this. Does the 'downloading' status time out at some point?