• State Verified Answer
  • Replies 27 replies
  • Subscribers 68 subscribers
  • Views 5791 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 237131
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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

  • 0 in reply to Øyvind

    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.

  • 0 in reply to Yusuke

    Hi, it's possible to use the AWS FOTA and HTTP application update sample with any server that can respond with the content-range header. To be more precise, it needs to support this formatting of the content-range.

    Content-Range: <unit> <range-start>-<range-end>/<size>

    It is the Download Client library that sets this limitation.  

    AWS S3 buckets do respond with this, but the file has to be accessible for the device. To find out if it is, I recommend turning on CONFIG_LOG=y and CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y to see what the header response is.

    I guess that you get either a 403 forbidden or 301 permanent redirects response in the header.

    If you want to test downloading from an S3 bucket, it is easiest to make the files in the bucket public. This can be done by going to the S3 Console, then go bucket>permissions>block public access and deselect the two options which regard blocking public access through policy. 

    Then you can attach the following policy to your bucket by going to bucket>permissions>bucket policy

    {    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<bucket name>/*"
        }
    ]
}

    Then press save. It should be noted that this makes you file publicly available to anyone who has the link.

    After you have done this the format of your job file should be 

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

    The Download client library now appends the / between host and path. It should also be noted that this will use HTTP to download the file(this is possible with the S3 bucket) in a standard configuration, so no change is needed.

  • 0 in reply to sigvartmh

    Hi, sigvartmh

    Thank you for your advice. Unfortunately, I can't solve the issue yet.

    I got the same result. I added to these two lines to prj.conf and check the log on LTE Link Monitor.

    When I added CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y to prj.conf, an error was caused so I fixed Kconfig.

    <prj.conf>

    CONFIG_LOG=y
CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y

    <Kconfig>

    config DOWNLOAD_CLIENT_LOG_LEVEL_DBG
	bool "debug level"

    <LTE Link monitor>

    ***** Booting Zephyr OS v1.14.99-ncs2 *****
The MQTT AWS Jobs FOTA Sample
LTE Link Connecting ...
LTE Link Connected!
IPv4 Address 0x1f39d522
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: 24675

    <AWS S3 access setting>

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

    Any help?

  • 0 in reply to Yusuke

    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.

  • 0 in reply to sigvartmh

    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?

  • 0 in reply to Yusuke

    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.

Reply
  • 0 in reply to Yusuke

    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.

Children
Related