RoadTest: Enroll to Review the Infineon AIROC™ Cloud Connectivity Manager Eval Kit
Author: SBB
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: USB-NORA-W256AWS
What were the biggest problems encountered?: Nothing major but minor hiccups in Setting up AWS cloud.
Detailed Review:
To readers/reviewers/developers: I tried to keep this review simple and yet provide the crisp essence that makes this review complete without duplicating much of the stuff that are already well explained in product supporting documents. I have provided appropriate links for the supporting documents, but they can become dangling links over time, and I am not in control of them.
My intention with providing the direct links is to encourage curious developers to visit the Infineon's (community) website to dig in for more details and they might find something interesting outside of this review. Maybe a new product or a feature or an idea that suits their interests/requirements.
Feel free to comment if somethings have to be corrected or if you have any doubts.
Have fun!
Product description
AIROC IFW56810-00 CCM is a Turnkey solution that provides a reliable and secure cloud connectivity to IoT applications (connected factories/buildings, sensors, consumer products, telematics) by hiding all network and security complexities within the CCM module. AIROC CCM is an ExpressLink module that comes with a pre-provisioned hardware root of trust which provides the necessary credentials to connect to a default AWS IoT ExpressLink staging account. These credentials include a unique identifier (UID) of the module, a key pair (public and private), and certificate signed by a Certificate Authority shared with AWS.
The host implementing IoT application can interface with CCM module via UART interface that enable easy AWS cloud connectivity.
Refer Infineon’s CCM Product Description: AIROC IFW56810-00-CCM
Unboxing
The AIROC IFW56810-00 CCM kit shipped with an elegant antistatic package!
Kit contents
Setting up and working with CCM
Pre-Requisites:
1. Register the CCM kit
Register as explained in AIROC-QuickStartGuide
Note: While registering the CCM module either use the QR code or use the complete URL printed on the CCM module itself. Don’t use the URL (https://ifxcloud.io/) that is mentioned in Getting Started guide and suffix the ModuleID of the CCM module as it will not work (“ifxcloud.io” will not be resolved).
After registration you can find your device here (use your Infineon account that you used for registration): https://osts.infineon.com/login
Click on Cirrent Cloud ID.
2. Connecting CCM to host
Refer section 3 of AIROC-Getting-Started
The below pictures and table summarize my experiments with CCM connections to host.
Options |
Usage |
My usage/comments |
Option-1 |
Directly plugin CCM to USB Type-C port of laptop |
Initially to get familiarize with the CCM kit, I connected as per option 1 and tried AT commands listed in AIROC-AT-Commands over a serial connection using putty tool on my laptop
|
Option-2 |
Plugin CCM to USB Type-A port of laptop with the help of Type-A male to Type-C female cable |
You can connect like this if your laptop does not have a Type-C port. |
Option-3 |
This is similar to Option-2 but used Pi5 instead of laptop and connected MSG and INT PINS of CCM to GPIO PINS of RSP-Pi5 |
I connected MSG and INT PINS of CCM kit to GPIO PINS of Pi-5 to make use of messaging event instead of polling via AT commands (refer section 6 of ExpressLink-ProgrammersGuide ) and providing an external INT to CCM to wake up from deep sleep mode (refer section 7 of AIROC-Getting-Started). One can evaluate all features with Option-3 which is quite easy, and I recommend this. |
Option-4 |
Here you connect CCM directly to the UART PINS of host as you do in a real product integration. |
This is out of curiosity I did as I wanted to enable GPIO UART PINS of Pi-5 and experiment. I did struggle a bit on Pi-5 side but succeeded!!! Note: remove all jumpers J60 of CCM module Refer: figure-1 and figure- 2 of “ How to connect the AIROC
|
3. Configure serial port: Refer section 4 of AIROC-Getting-Started
4. Working with basic AT commands without setting up AWS account
After configuring serial port but without setting up AWS account, I could try out following AT commands over the serial console (used putty) and I did not face any issues. This is quite straight forward.
AT
AT+CONF? About
AT+CONF? Version
AT+CONF? ThingName
AT+CONF? Certificate pem
AT+CONF SSID=<your router ssid>
AT+CONF Passphrase=<your router passphrase>
AT+CONNECT
AT+DIAG LOG X (X being 0 to 9)
AT+DIAG PING 8.8.8.8
AT+DIAG SCAN 30
AT+DISCONNECT
It throws the right errors if wrong AT commands or wrong parameters are used.
AT+XYZ? ABC -> ERR3 COMMAND NOT FOUND
AT+CONF? XYZ -->ERR11 UNKNOWN KEY
Without AWS account setup, I tried to run AT commands which needs right AWS account + configurations and as expected the CCM throws right errors.
(i)
AT+CONF Topic1=/MyPubTopic
AT+SEND1 hello world ------------> ERR6 NO CONNECTIONld
(ii)
AT+CONF Topic2=/MySubTopic
AT+SUBSCRIBE2
AT+GET2 ------------> ERR6 NO CONNECTIONld
(iii)
AT+OTA? --->ERR1 Invalid cmd
(iv)
AT+OTA ACCEPT--->ERR21 INVALID OTA UPDATE
(v)
AT+OTA APPLY --->ERR19 HOST IMAGE NOT AVAILABLE
5. Getting started with AWS account and binding
AIROC CCM module is compliant with AWS IoT ExpressLink. The Infineon’s AIROC-Getting-Started document covers the minimum required details assuming that the developer knows the rest. The following AWS documents might be helpful for those who are new to this domain:
(One can have a glance and refer as and when needed. No need to go in detail.)
Getting-Started-with-AWS-IoT-ExpressLink
AWS IoT ExpressLink Onboarding-by-Claim Customer/OEM Guide
Note: One can evaluate the CCM (only physical device working status) without Amazon AWS account as described in https://documentation.infineon.com/airoc-ccm/docs/quick-evaluation-flow.
Manual provisioning of CCM device on AWS
As per the instructions of section 5 of AIROC-Getting-Started, I bound the device and AWS account by adding right credentials like adding ThingName and certificate of the CCM on to AWS account and configuring AWS’ account Endpoint name on to CCM device.
This manual provisioning of device on to AWS cloud has to be done for each device. If you want to automate this process for all devices as and when devices are registered with Cirrent cloud (Step 1 above : Register CCM Kit) then follow the below section "Triggering the Cloud Formation template".
Triggering the Cloud Formation template
CloudFormation is an AWS service that helps in setting up the required resources in AWS through a template. Executing a CloudFormation template creates a stack in your AWS account. A stack is a collection of AWS resources.
The template for creating AWS resources required for connecting your CCM devices to the AWS IoT Core is already created by INFINEON and stored in Amazon S3 storage. The stack created by this template provides some outputs that can be used to establish a channel of back-end cloud communication between your CIRRENT Cloud ID account and your AWS Product Cloud.
Note: This one-time template approach establishes an ecosystem between Cirrent and the AWS cloud so that all future registered devices on Cirrent will be automatically provisioned on AWS cloud. If you have a fleet of devices, I recommend this approach.
Instructions for running the CloudFormation template are here:
https://documentation.infineon.com/cirrent/docs/cid/getting-started-with-cloud-id
6. AT commands to publish and subscribe
For detailed understanding refer section 4 of ExpressLink-ProgrammersGuide
6.1 Publish a topic
(i) Subscribe to a topic with wildcard on AWS cloud. It throws an error about using wildcard but ignore that.
(refer 5.3 of AIROC-Getting-Started)
(ii) Enter the following commands in sequence on the CCM’s serial terminal
(Refer section 6 of AIROC-Getting-Started)
AT+CONF Topic1=/MyPubTopic
OK ->Response from CCM
AT+SEND1 hello world
OK ->Response from CCM
The Hello world message gets displayed on the AWS IoT console.
6.2 Subscribe to a topic
(refer 6.2 of AIROC-Getting-Started)
(i) Enter the following commands in sequence on the CCM’s serial terminal
AT+CONF Topic2=/MySubTopic
OK->Response from CCM
AT+SUBSCRIBE2
OK->Response from CCM
(ii) Below snapshots shows the steps done on AWS console as per bullet 2 of section 6.2 of AIROC-Getting-Started
(iii) Receive the message at CCM serial console
Whenever a message is available from AWS cloud that will be notified to CCM module via an event. So, check for an event and if it is meant for the subscribed message then read and take an action by the corresponding agent.
AT+EVENT? /*Read event if any*/
OK 1 2 MSG-> Response from CCM indicating message for TOPIC 2. So, use the AT+GET2 command to read the message. To understand the response of CCM for an EVENT command refer section 6.1.1 of ExpressLink-ProgrammersGuide
AT+GET2 /*Read message of TOPIC2*/
OK {\A "message": "Hello from AWS IoT console"\A} ->Response from CCM containing message text
7. Event polling
Events can be polled periodically by the host processor using the “AT+EVENT?” command. Alternatively, if the MSG PIN of CCM is connected to the host, then following an interrupt (low to high) on the MSG pin, read the events with “AT+EVENT?” command and then take an appropriate action, for example, reading the subscribed message (AT+GET2) if the event response from CCM is “OK 1 2 MSG” (refer to example in 5.2- III above). It is important to note that the MSG pin is automatically deactivated (high to low) as soon as the host processor has emptied all the pending events from the queue. For more details, refer to section 6 of ExpressLink-ProgrammersGuide.
My test code to test event polling through MSG PIN: I connected the MSG PIN of CCM to the GPIO PIN 16 (physical PIN number=36) of Pi-5. Using below Python code and gpiozero library, I programmed GPIO 16 as input Button device and registered two call back functions. The function “msg_rcvd_cbk” is called when MSG PIN status changes from low to high and “msg_cleared_cbk” is called when MSG PIN status changes from high to low. Note that this is a crude way to verify this feature, which enters infinite pause after registering callbacks and can be ended by pressing ctrl+c.
As a part of “msg_rcvd_cbk” the application has to handle all events one by one in a loop and empty the events queue. In my below Python code, I have just put the print statements indicating the actions to be taken. But I am manually reading the events and emptying the CCM’s events queue through serial terminal (putty) to show the behaviour. Please refer the attached video.
Below is the python code for reference
---------------------------------------------------------------------------------------------------------------------------------------------
import signal
import sys
from gpiozero import Button
from signal import pause
#MSG PIN of CCM is connected to GPIO 16 (physical PIN num 36 on board) of Pi-5
MSG_GPIO=16
#Call back for an event that goes from low to high
def msg_rcvd_cbk():
print("EVENT Msg rcvd. Read all events in a loop and empty the Q")
#Call back for an event that goes from high to low
def msg_cleared_cbk():
print("All EVENTs are cleared ")
#Signal handler to end this program gracefully when ctrl+c is pressed
def signal_handler(sig, frame):
button.close()
sys.exit(0)
if __name__ == '__main__':
#Set default PIN state to 0
button=Button(MSG_GPIO,pull_up=False)
#register Call back for an event that goes from low to high
button.when_pressed = msg_rcvd_cbk
#register Call back for an event that goes from high to low
button.when_released = msg_cleared_cbk
#Regsiter signal handler to clean up
signal.signal(signal.SIGINT, signal_handler)
pause()
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
“The recorded video shows the execution of the above Python code from Pi-5 terminal (polling on MSG PIN for message event), publishing messages from AWS cloud, and reading CCM events and messages through the host’s (Pi-5) serial terminal - “Putty”.
In my experiment, at first, I published the same message three times from AWS cloud and actually CCM got 3 events but “msg_rcvd_cbk” is called only once since this callback is registered for the event when the PIN status changes from low to high, and the PIN remains high as long as all (in my test case now it is 3) events are read using the “AT+EVENT?” command (not when messages are read using AT+GET2 as this the action taken corresponding to the event received in our experiment case). When I manually read these 3 events through putty, the events queue gets emptied, the MSG PIN status changes from high to low and then the call back function “msg_cleared_cbk” is called indicating events queue is empty.
Second time, I publish just one message from AWS, the “msg_rcvd_cbk” is called and when I read the event manually again through putty “msg_cleared_cbk” is called.
Note that there are some events that just indicate the status, for example, when the network disconnects and no corresponding messages are to be read (like “AT+GET2” as in our experiment case), but the corresponding right actions to be taken by the application depending on the design implementation.
8. CCM in sleep and deep sleep mode and waking up the CCM from host
To save power the CCM has an option for host to trigger different sleeping modes during idle state. Refer section 7 of AIROC-Getting-Started
I connected the INT PIN of CCM to the GPIO PIN 26 (physical PIN number=37) of Pi-5 and configured that as output pin. In order to wake up the CCM from system sleep or deep sleep mode, I generated an external INT (falling edge) by writing “1” and “0” to that GPIO PIN of Pi5 using a small python script that uses “gpiozero” library. Note that this is a crude way done to verify this feature. Below is the code and the video for the reference.
Note: Initially I used GPIO PIN 12 (physical PIN number=32) which also worked (refer CCM connection to host Option-3 picture). But later for safer side (on Pi documentation GPIO PIN 12 is mentioned as PWM0) I changed to GPIO PIN 26.
Below is the python code for reference:
--------------------------------------------------------------------------
from time import sleep
from gpiozero import OutputDevice
wakepin=26
out_device=OutputDevice(wakepin)
out_device.on()
print("Writting 1 to wake PIN")
sleep(0.1)
out_device.off()
print("Writting 0 to wake PIN")
----------------------------------------------------------------------------------------------
9. Setting up for the Over The Air (OTA) firmware update
Basically this feature is about to get a secure and authenticated firmware update of CCM module under the control of host. Note here that the CCM firmware is not being passed to host but it is kept within the CCM itself, but host can instruct when CCM can update its own firmware. Refer section 7 of ExpressLink-ProgrammersGuide for more details on OTA and follow the steps described in section 8 of AIROC-Getting-Started to setup firmware update OTA for CCM module. It works smoothly as described.
For Airoc CCM module, Infineon will provide the new firmware signed by it’s private key and vendor has to manage this update using his own AWS cloud.
Note:The Infineon CCM firmware version "1.0.1 &1.0.3" do not authenticate the OTA/HOTA firmware properly. Refer "ISSUES" section below.
Hiccups: On AWS cloud, I faced issues while creating OTA jobs. I used to get below error whenever I create an OTA job in the end.
"Access denied when trying to get object. (Service: AWSIot; Status Code: 401; Error Code: UnauthorizedException; Request ID: 893fb664-bd98-4274-9099-5b4bcfa90936; Proxy: null)
Provide Feedback on your experience - optional"
This issue was fixed when I created Amazon S3 bucket name beginning with “afr-ota”. For eg. “afr-ota-ccm-update1” or “afr-ota-update” etc. I think the AWS managed policy “AmazonFreeRTOSOTAUpdate” includes the required permissions by default for those S3 buckets created with those prefixes.
Just for the reference, below are the changed inline policies which worked for me and is slightly different than that is described. Not sure how it matters.
ota-inline-policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::999977788810:role/ota"
}
]
}
ota-s3permission-inlinepolicy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"s3:GetObjectVersion",
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::afr-ota-ccm/*"
]
}
]
}
10. Setting up for the Host Over The Air (HOTA) firmware update
This is same as OTA but in this case the firmware being downloaded is for the host. If the host vendor needs the feature of authenticated firmware update, then vendor has to upload/configure his signed certificate on to CCM and also sign the firmware with his private key and host the HOTA job on AWS cloud with his signature that is used for signing the host firmware. Follow the steps described in section 9 of AIROC-Getting-Started to setup HOTA firmware update for CCM module and it works smoothly as described.
The CCM, in similar to OTA process downloads, authenticates the firmware and notifies the host. In the HOTA case the host has to get the firmware from CCM chunk by chunk via AT commands and then has to gets updated by itself with the new firmware which is specific to host's implementation.
Note: The Infineon CCM firmware version "1.0.1 &1.0.3" do not authenticate the OTA/HOTA firmware properly. Refer "ISSUES" section below.
Issues
1.The Infineon CCM firmware version "1.0.1 &1.0.3" do not authenticate the OTA/HOTA firmware properly.
I used the CCM firmware and the signature file from the link: "GitHub - Infineon/ccm-ota-image-update: The Following repository contains firmware updates for the IFW56810-00 Module " but I corrupted the signature file for testing purpose.I uploaded the firmware and the corrupted signature file on my AWS cloud for OTA. CCM module downloaded and upadated to this new firmware (from 1.0.1 to 1.0.3). Downloading to CCM is OK but it should not have updated to new firmware due to wrong signature that I uploaded on AWS.
I also setup HOTA as per instrunctions (section 9 of AIROC-Getting-Started ) but used wrong signature file on AWS. But CCM still downloaded the firmware and notified the host about new firmware availability.
(Refer 2nd bullet in section "What could have been improved?" for ideal expected behaviour of OTA and HOTA .)
I have reported these issues to Infineon and Infineon has agreed to fix these issues in their upcoming release.
What could not be tested?
1. I could not test the Anti Roll Back (ARB) feature of CCM module as I do not have an old firmware with the right signature file. May be I will check with new CCM firmware when it is released with the current firmware V1.0.3 .
2. WiFi provisioning with Blue Tooth Cirrent App from an Android mobile:
Refer section "Connect the CCM module to Wi-Fi" : Getting Started With the CCM Development Kit | CCM Documentation (infineon.com)
Note that Infineon did not publish this android/apple mobile app for their latest CCM module but I tried out of curiocity as I found the above related document. But it seems the Cirrent app is not compatible with my latest Android version 14.
I contacted Infineon on this feature and the android app compatibility issue but it seems that Infineon does not have any plans to continue this BT Cirrent app going ahead. So I dropped the idea of testing this CCM WiFi provision through BT.
Anyways it is not an issue with CCM module.
What could have been improved?
1. The CCM FW version 1.0.3 supports TLS 1.2. But it could have been good to support TLS 1.3 as "NIST SP 800-52 Rev. 2" recommends this.
I disabled encryption of my WiFi router and captured the packets. I could see TLS session packets before TLS gets encrypted. It's not a problem but client (CCM) certificates shows up some private CCM details which is unique to this module and that may be privacy concern for some. But anyhow in the end TLS application data is encrypted which is more sensitive!
2. Regarding OTA and HOTA:
The right way would be as below:
OTA case: The firmware has to be downloaded and then authenticated by CCM by its own certificate. If the firmware is valid then only CCM should notify the host about OTA availability so that the host application can apply and reboot to get CCM upgraded to new firmware. In case of invalid firmware, CCM should notify an error to host so that host application can reset it's OTA state and avoid reboot. CCM should remove the invalid firmware and clear the memory by its own without the host intervention and should be able to handle such flush request coming from host as well.
HOTA case: The firmware has to be downloaded and then authenticated by CCM with Host's configured certificate. If valid then only CCM should notify the host about HOTA availability so that host application can start downloading the firmware from CCM (via AT commands). In case of invalid firmware, CCM should notify an error to host so that host application can reset it's HOTA state and avoid reboot. CCM should remove the invalid firmware and clear the memory by its own without the host intervention and should be able to handle such flush request coming from host as well.
3.I guess/hope that CCM provides WiFi provisioning through BT feature even though the support for an external mobile app is discontinued so that OEM/vendor can develop their own mobile app to support that feature which is very useful to an end user.
Conclusion
The AIROC IFW56810-00 Single-band Wi-Fi 4 Cloud Connectivity Manager Module (CCM) offers a seamless and secure solution tailored for IoT development. Powered by AWS IoT ExpressLink, this turnkey module simplifies the integration process, allowing IoT vendors to focus primarily on their core application. With built-in features like secure cloud connectivity, over-the-air (OTA) updates, and more, it accelerates time-to-market while ensuring reliable performance.
In summary, I wholeheartedly recommend this product, which significantly streamlines the lives of IoT vendors.