ModusToolbox AWS IoT SDK

[EyLa_3227556]

Hi,

Several question regarding OTA over the AWS cloud using Amazon FreeRTOS (or Cypress' derivative of AFR):

1. I want to verify that the embedded code (or programmable binary) for ALL the devices is using a single instance of the security credentials - root certificate and private key (wiced_demo_server_cert.cer & wiced_demo_server_cert_key.key) in /resources/certificates/
   i.e. - I want to verify that all programmable image are identical.
   
   If this is not the case what is the best procedure to 'implant' security credentials during production?
2. In the AWS IoT universe, how do devices identified? Is there any UUID programmed to the device (DCT?), is it the MAC? other ?
3. After deployment, how exactly an OTA is performed (the AWS way) ?
   Can the OTA process be automated (which api?) to OTA specific devices/groups of devices (e.g. OTA certain feature to X devices of customer Y)?
4. How's each device's OTA-ed version is being tracked in the AWS environment ?
   e.g. - How can we tell which device got which OTA version and whether the OTA passed successfully
   
   
5. What are the difference between the WICED OTA/2 method and the AWS way ("OTA agent")?
   
   
6. Can my device communicate with the  AWS cloud (MQTT)  while being updated using the WICED OTA/2 way?

Thanks for any advice

[MuraliR_36]

Hi

Unfortunately there's no public release of the OTA implementation using AFR as of today, but is scheduled to be released in the future releases of MTB-AFR.

Regarding your other queries, i need to look into them as i don't have concrete answers and will get back to you ASAP.

Thanks

[EyLa_3227556]

Hi,

Per Cypress' response on my other post (link), it seems that Cypress AFR version DOES include some AFR OTA implementation for the MODUS toolbox as can be seen on the git page (link)

Cloning and importing the projects from this Cypress-AFR (CAFR) seem to have an ota sample code (see screen cap)

Now, my question relates to this OTA demo code -

As I have some makefile errors when trying to build it, I would like to better understand :

1. If it can be 'ported' and built in WICED studio for the CYW943907 ?
2. In any case, whether the question is Yes or No, can Cypress refer to the rest of the questions dealing with OTA procedures in true large-scale production and usage  scenarios.

Thanks for your prompt support on this crucial issue.

[MuraliR_36 · Accepted solution]

Hi

I want to verify that the embedded code (or programmable binary) for ALL the devices is using a single instance of the security credentials - root certificate and private key (wiced_demo_server_cert.cer & wiced_demo_server_cert_key.key) in /resources/certificates/

i.e. - I want to verify that all programmable image are identical.

--> There is no implementation for OTA as such in WICED using AFR. So it would be difficult to comment on this. For more details you can refer to : FreeRTOS Over-the-Air Updates - FreeRTOS

If this is not the case what is the best procedure to 'implant' security credentials during production?

--> You can use Code Signing for AWS IoT to sign your files, or you can sign your files with your own code-signing tools. (What Is Code Signing for AWS IoT? - Code Signing for AWS IoT )

In the AWS IoT universe, how do devices identified? Is there any UUID programmed to the device (DCT?), is it the MAC? other ?

--> The device will be identified as a "thing" which can be set up in AWS IoT console. You provide the thing details in the code. It is provided in aws_clientcredential.h and aws_clientcredentialkeys.h to be specific. Now the device will register for OTA notification with AWS using the thing name to identify itself

After deployment, how exactly an OTA is performed (the AWS way) ?

-->The OTA update can be pushed either using MQTT/HTTP using Code Signing for AWS IoT and any other code signing tools which will be used. If the image is received properly, then the device updates on reboot.

Can the OTA process be automated (which api?) to OTA specific devices/groups of devices (e.g. OTA certain feature to X devices of customer Y)?

--> There are 2 ways by which an OTA update can be pushed i.e., either CONTINUOUS or SNAPSHOT.

snapshot job

By default, a job is sent to all targets that you specify when you create the job. After those targets complete the job (or report that they are unable to do so), the job is complete.

continuous job

A continuous job is sent to all targets that you specify when you create the job. It continues to run and is sent to any new devices (things) that are added to the target group. For example, a continuous job can be used to onboard or upgrade devices as they are added to a group. You can make a job continuous by setting an optional parameter when you create the job.

For more details refer to : Jobs - AWS IoT

How's each device's OTA-ed version is being tracked in the AWS environment ?

--> Each OTA job will have an OTA update ID and an optional OTA update description.

What are the difference between the WICED OTA/2 method and the AWS way ("OTA agent")?

--> There's no AFR OTA support for 43907 and WICED OTA2 runs only on xx907 based devices. Just as a comparision at the top layer, both look the same.

Can my device communicate with the  AWS cloud (MQTT)  while being updated using the WICED OTA/2 way?

--> By update, if you mean updating the device firmware once the update is downloaded, then no. But if you want to communicate during the process of downloading an update the OTA2 way, it should be possible, but may turn out to be tricky as you will be using the same STA interface to communicate to MQTT and be downloading an update at the same time.

If it can be 'ported' and built in WICED studio for the CYW943907 ?

--> It can be done, but you have to write out the implementation as we don't support it.

Thanks