How to use aws_fota program in nRF9160?

[Yusuke]

I'm trying to use aws_fota, but it doesn't work. Any help?

I was able to set a job on AWS IoT, but the download job doesn't start. The job status is always "in progress". I logged out and logged in and got the same result.

***** Booting Zephyr OS v1.14.99-ncs2 *****
The MQTT AWS Jobs FOTA Sample
LTE Link Connecting ...
LTE Link Connected!
IPv4 Address 0x4980a023
client_id: nrf-352656100218455
[mqtt_evt_handler:131] MQTT client connected!
[mqtt_evt_handler:196] SUBACK packet id: 2112
[mqtt_evt_handler:186] PUBACK packet id: 62996

I use the same region in AWS IoT and S3

I've already checked this thread.
https://devzone.nordicsemi.com/f/nordic-q-a/52039/aws-fota-sample/210098#210098

[Øyvind]

Hello, 

Good to see that the connection is working. 

Can you please provide your AWS Job file as well? And where is the .bin file located?

Thanks!

Kind regards,
Øyvind

[Yusuke]

Thank you for your help!

I'm using Oregon region.

This is a job file

{
  "operation": "app_fw_update",
  "fwversion": "v1.0.2",
  "size": 64300,
  "location": {
    "protocol": "https:",
    "host": "******.s3-us-west-2.amazonaws.com",
    "path": "/20190929_test_update.bin"
   }
}

.bin file is located in S3 in Oregon region.

[sigvartmh]

Is this the full LTE Link Monitor output? If so, it seems that your device did not receive a job from AWS. I recommend to cancel and delete any old jobs which may be in AWS. Before you try to create a new job, also maybe wait until the device is connected before you create it.

With regards to the S3 Bucket, I see that the Oregon configuration is a bit different and the one I used. This is how you should have configured it.

Then you should be able to update the bucket policy with the policy I posted as it will allow you to set public access to the file through a policy.

Also, I forgot to tell you to set CONFIG_DOWNLOAD_CLIENT_LOG_HEADER=y which will log out the HTTP headers so that you can ensure that you don't get a 403 or 301 response in the HTTP header.

[Yusuke]

Let me confirm one thing.

A Job must be created after MQTT connection, right? If it is created BEFORE connection, isn't it be downloaded?

[sigvartmh]

Yes,/no is my answer. If you are on the tagged version, A Job must be created after the MQTT connection. If you are on the master branch, this should no longer be the case as the device should fetch any queued jobs for the device and will take the first job queued for the device.

It could be that AWS has changed their policy configurations from when the documentation was written and the current thing policy is not seen as valid.  Could you try to attach the following policy to the certificates your device uses? See if it is then able to accept jobs.

[Yusuke]

My ncs version is v1.0.1, is this tagged version?

[sigvartmh]

As far as I know, the only tagged version is v1.0.0 for NCS could you do "git show --no-patch" in the nrf repository/folder and post the commit SHA. It's easier to check where you are at in the git history.

[Yusuke]

Yea, you're right. My version is v1.0.0. Modem fw is v1.0.1.

>In addition, now I can't update bucket>permissions>bucket policy.

I solved this issue. You must configure bucket access controls both in account level and bucket level.

However, downloading does not start yet.... The same result so far, even if I created a job after MQTT connection.

[sigvartmh]

Did you attach the policy I suggested to the certificates of the thing in AWS IoT Core? Does your job ever go from Queued to In progress if you click on it and see the status fields?

It should progress from Queued, In progress then to either Failed or Successful.

For v1.0.0 your device has to be connected and subscribed 
[mqtt_evt_handler:196] SUBACK packet id: 2112
before you create the job. Also, ensure that all your old jobs are canceled and deleted as a device can only have 1 active job at the time. So if there is a job already for the device it will block any new jobs created.

[Yusuke]

>Did you attach the policy I suggested to the certificates of the thing in AWS IoT Core?

I did it and the device doesn't subscribe and stops processing on the way.

***** Booting Zephyr OS v1.14.99-ncs2 *****
The MQTT AWS Jobs FOTA Sample
LTE Link Connecting ...
LTE Link Connected!
IPv4 Address 0x27e71934
client_id: nrf-352656100218455

[sigvartmh]

This is usually caused by client_id: nrf-352656100218455 not being the same as the clientId attached to your certificates. Have you set nrf-352656100218455 as the thing name in AWS?

What do you mean with stops processing on the way? What happens?

[Yusuke]

I use the same name as thing name.

<Kconfig>

config USE_CLOUD_CLIENT_ID
	bool "Custom MQTT Client Id"

config DOWNLOAD_CLIENT_LOG_LEVEL_DBG
	bool "degbug level"

config DOWNLOAD_CLIENT_LOG_HEADER
	bool "log header"

if USE_CLOUD_CLIENT_ID

config CLOUD_CLIENT_ID
	string "Client ID"
	default "device01"
endif

>What do you mean with stops processing on the way? What happens?

I expected "MQTT client connected!" message will show up after "client_id: nrf-352656100218455" message, but "MQTT client connected!" does not show up and process stops.