AWS FOTA fails when using my upload.bin file for nrf9160

[hmichel]

Previously I have been successful getting the AWS FOTA update working using the AWS FOTA example project, the example update.bin file and location provided

by Nordic for the nrf9160. I did have excellent help from Nordic to get that working.

Now I have created my own update.bin from the AWS FOTA project

1) Create update.bin by making a build (get its exact file size from Windows Explorer)

2) Create an s3 bucket for the update.bin file (it has logging turned on)

3) Create another s3 bucket for the logging of events from the bucket with update.bin

4) Upload the update.bin file to the s3 bucket

5) Create a json file to point to the update.bin file

6) Upload code to nrf9160 using Segger

7) Wait for LTE connect complete and board ready for update by observing Termite terminal 

8) Create a job to perform FOTA update using the update.bin file

9) Get MQTT disconnect error

here are related screen shots

[Øyvind]

Hello,

First of all, what version of NCS are you running and what is current modem FW?

I see that you have configured your job file for an HTTPS address. Have you configured this accordingly as described in the download client? In the original job file example shown in AWS FOTA library, the address points to a nRFCloud address using HTTP.

Error message -57 is defined as follows:

ENOTCONN 57     /* Socket is not connected */

Kind regards,

Øyvind

[hmichel]

Dear Øyvind

The NCS version is 1.0.0

The Modem Firmware is 1.0.0

[hmichel]

I will update to V1.0.1 today. Thank you for the help. Especially since you are not at the office

[hmichel]

I updated to Modem version 1.0.1

Then I ran the update using the http prefix in the json file

Then I ran the update using the https prefix in the json file

in both cases the interaction starts when I start the job but then hangs even though I wait several minutes see screen below

[hmichel]

I then followed up with trying the Nordic provided update.bin and a json file that pointed to that file.

The update started and completed within 2 minutes of initiating the job

Then the update ran on the board and the green LED turned on which indicates that the update was successful because the update.bin code will turn on that LED

[Øyvind]

hmichel said:

Thank you for the help. Especially since you are not at the office

 No problem! We are here to help 

hmichel said:

in both cases the interaction starts when I start the job but then hangs even though I wait several minutes see screen below

Getting the default: 8 would indicate that your AWS Job has triggered and download started (from what I get here as well). Not sure what causes the difference in download speed. Did you reset the board before the download was complete?

2019-09-19T09:18:02.259Z DEBUG modem << [mqtt_evt_handler:129] MQTT client connected!\x0D
2019-09-19T09:18:02.460Z DEBUG modem << [mqtt_evt_handler:194] SUBACK packet id: 2112\x0D\x0A
2019-09-19T09:18:02.588Z DEBUG modem << [mqtt_evt_handler:184] PUBACK packet id: 42170\x0D\x0A
2019-09-19T09:19:58.088Z DEBUG modem << [mqtt_evt_handler:199] default: 8\x0D
2019-09-19T09:19:58.802Z DEBUG modem << [mqtt_evt_handler:184] PUBACK packet id: 30909\x0D\x0A
2019-09-19T09:23:10.104Z DEBUG modem << [mqtt_evt_handler:184] PUBACK packet id: 59531\x0D\x0A
2019-09-19T09:23:10.650Z DEBUG modem << [mqtt_evt_handler:184] PUBACK packet id: 63819\x0D\x0A
2019-09-19T09:23:10.708Z DEBUG modem << AWS_FOTA_EVT_DONE, rebooting to apply update.\x0D\x0A
2019-09-19T09:23:10.710Z DEBUG modem << ***** Booting Zephyr OS build v1.14.99-ncs3-snapshot2-1276-g4493a423a645 *****\x0D\x0A
2019-09-19T09:23:10.712Z DEBUG modem << [00:00:00.008,056] \x1B[0m<inf> mcuboot: Starting bootloader\x1B[0m\x0D\x0A
2019-09-19T09:23:10.715Z DEBUG modem << [00:00:00.016,235] \x1B[0m<inf> mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1\x1B[0m\x0D\x0A
2019-09-19T09:23:10.719Z DEBUG modem << [00:00:00.028,808] \x1B[0m<inf> mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3\x1B[0m\x0D\x0A
2019-09-19T09:23:10.764Z DEBUG modem << [00:00:00.040,802] \x1B[0m<inf> mcuboot: Boot source: none\x1B[0m\x0D\x0A
2019-09-19T09:23:10.805Z DEBUG modem << [00:00:00.047,729] \x1B[0m<inf> mcuboot: Swap type: test\x1B[0m\x0D\x0A
2019-09-19T09:23:34.230Z DEBUG modem << [00:00:23.606,658] \x1B[0m<inf> mcuboot: Bootloader chainload address offset: 0xc000\x1B[0m\x0D\x0A
2019-09-19T09:23:34.279Z DEBUG modem << [00:00:23.614,196] \x1B[0m<inf> mcuboot: Jumping to the first image slot\x1B[0m\x0D\x0A
2019-09-19T09:23:34.322Z DEBUG modem << ***** Booting Zephyr OS build v1.14.99-ncs3-snapshot2-1276-g4493a423a645 *****\x0D\x0A

hmichel said:

I then followed up with trying the Nordic provided update.bin and a json file that pointed to that file.

 Can you please elaborate, I'm not sure what you mean with "Nordic provided update.bin". The json file example in AWS FOTA library includes a path to another nRFCloud page. You need to edit the host and path to reflect your cloud. The host and path in the example point to another nRFCloud account, which is a bug.

I've been trying with AWS S3 bucket address, without luck as well.

Tests are ongoing, and will keep you posted.

Kind regards,
Øyvind

[hmichel]

I would say there is not a change in download speed. I would say that after waiting several minutes for the download for my update.bin in my s3 bucket the download is stuck and therefore failed.

The "Nordic provided update.bin" is the one referred to in the AWS FOTA library example. I use that as a reference because I can always run that update successfully.

So when my FOTA update fails i rerun the example FOTA from Nordic to make sure there is not some other problem like a lost cell signal or something else.