nrf9160 FOTA always has several reconnects during upgrade

RichSurprenant

I am using FOTA on the nrf9160 to upgrade the firmware from a file on my AWS server. Invariably, the session needs to log back in. Occasionally, it fails. Can I do any throttling or something to prevent this issue. I need to get 100% assured upgrade when I start the process.

D: Receiving up to 2048 bytes at 0x200226ec... D: Read 533 bytes from socket D: GET header size: 533 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 1024 bytes from socket D: Receiving up to 1024 bytes at 0x20022aec... D: Read 1024 bytes from socket I: Downloaded 221184/230468 bytes (95%) fota_dl_handler: prog 95 check_to_update_progress: 95, 100 LED: 0 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 552 bytes from socket D: GET header size: 552 W: Peer closed connection, will re-connect D: Receiving up to 2048 bytes at 0x200226ec... D: Read 1024 bytes from socket D: Receiving up to 1024 bytes at 0x20022aec... D: Read 1024 bytes from socket I: Downloaded 223232/230468 bytes (96%) I: Erasing page at offset 0x000be000 fota_dl_handler: prog 96 check_to_update_progress: 96, 100 LED: 1 I: Reconnecting.. download_client_connect : 1 download_client_connect AF_INET : ps-gateway-firmware.s3.us-west-1.amazonaws.com download_client_connect : 2 download_client_connect : 3 D: Protocol not specified, defaulting to HTTP(S) D: Port not specified, using default: 443 D: family: 1, type: 1, proto: 258 I: Setting up TLS credentials, tag 1 I: Connecting to ps-gateway-firmware.s3.us-west-1.amazonaws.com D: fd 2, addrlen 8, fam IPv4, port 443 D: fd 2, addrlen 8, fam IPv4, ip 52.219.220.146, port 443 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 513 bytes from socket D: GET header size: 513 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 1024 bytes from socket D: Receiving up to 1024 bytes at 0x20022aec... D: Read 1024 bytes from socket I: Downloaded 225280/230468 bytes (97%) fota_dl_handler: prog 97 check_to_update_progress: 97, 100 LED: 0 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 513 bytes from socket D: GET header size: 513 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 1024 bytes from socket D: Receiving up to 1024 bytes at 0x20022aec... D: Read 1024 bytes from socket I: Downloaded 227328/230468 bytes (98%) I: Erasing page at offset 0x000bf000 fota_dl_handler: prog 98 check_to_update_progress: 98, 100 LED: 1 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 513 bytes from socket D: GET header size: 513 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 2048 bytes from socket I: Downloaded 229376/230468 bytes (99%) fota_dl_handler: prog 99 check_to_update_progress: 99, 100 LED: 0 D: Receiving up to 2048 bytes at 0x200226ec... client_write: err 0 **** polling loop D: Read 513 bytes from socket D: GET header size: 513 D: Receiving up to 2048 bytes at 0x200226ec... D: Read 1092 bytes from socket I: Downloaded 230468/230468 bytes (100%) I: Erasing page at offset 0x000c0000 mqtt_handle_packet 208 [mqtt_evt_handler:413] mqtt_evt_handler (9)! MQTT PINGRESP **** polling loop fota_dl_handler: prog 99 check_to_update_progress: 99, 100 LED: 1 I: Download complete I: Erasing page at offset

jaredwolff

If you’re using the built-in AWS FOTA via HTTPS you can increase retries as the expense of battery. Forgive me if I’m wrong, but off the top of my memory it’s 3 retries.

Otherwise I believe it saves the progress and as long as it’s the same file, it will continue later on. It’s hard to guarantee anything to work with cellular. It’s signal dependent.