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?

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.

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
  • 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

  • Thank you for your help!

    I'm using Oregon region.

    This is a job file

    .bin file is located in S3 in Oregon region.

  • 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.

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

  • 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.

  • 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.

  • 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 QueuedIn 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.

Reply
  • 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 QueuedIn 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.

Children
  • >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.

  • 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?

  • I use the same name as thing name.

    <Kconfig>

    >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.

  • You have to select CONFIG_USE_CLOUD_CLIENT_ID=y in prj.conf if not it will default to a combination of nrf- and your modem IMEI as you can see by the client_id: nrf-352656100218455 output in the log. Also, you should probably set CONFIG_CLOUD_CLIENT_ID="device01" in prj.conf instead of editing the default in Kconfig.

    So your device is using the nrf-352656100218455 as client ID which explains why it won't connect. The reason it worked before is the permissive policy allows anyone with a valid certificate to connect and subscribe.

  • >You have to select CONFIG_USE_CLOUD_CLIENT_ID=y in prj.conf

    This solved the issue. Thank you.
    Nordic may explain this on github or originally enable it.
    https://github.com/NordicPlayground/fw-nrfconnect-nrf/tree/master/samples/nrf9160/aws_fota

    >you should probably set CONFIG_CLOUD_CLIENT_ID="device01" in prj.conf 

    I agree with you. Client ID is configured in Kconfig in the original aws_fota. I didn't want to change the original code.

    However, I got  a next error. Could you give me any advice?