Table of contents

RoadTest: AVNET Azure Sphere MT3620 Starter Kit

Author: david.long

Creation date: 22 Nov 2019

Evaluation Type: Development Boards & Tools

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?: Raspberry Pi, SanCloud BeagleBone Enhanced (but these do not come with the built-in security features or cloud connectivity)

What were the biggest problems encountered?: Complexity of Azure cloud and getting starter kit to send/receive data from cloud based applications

Detailed Review:

Introduction

This RoadTest is for the Avnet Azure Sphere MT3620 starter kit. The “Azure Sphere” device has been developed by Microsoft and silicon vendor partners to provide a secure, yet simple to program Internet of Things (IoT) “Edge” device that connects to the Microsoft Azure IoT cloud service. This report describes my first experiences of getting the starter kit up and running,  creating the required Azure cloud components and sending telemetry messages between the board and Azure cloud IoT services.

Overview of Board

The Avnet starter kit is a board based around the Mediatek MT3620AN SoC. The main processor in this device is an Arm Cortex-A7 with a 500MHz clock. This runs Microsoft’s Azure Sphere Secure OS Linux-based operating system. In addition, the MT3620 includes 2 Cortex M4F co-processors that are intended to provide support for real-time applications, under the control of the main A7 processor (at present, it is not possible to program these independently, e.g. to run a Real-Time Operating System). A Microsoft Pluton security subsystem on the MT3620 (based on a third M4F core) manages secure boot, key storage and remote attestation (proves the Azure Sphere and booted software are genuine). The MT3620 also has an integrated IEEE 802.11 a/b/g/n dual-band WiFi subsystem, real-time clock, FLASH, RAM and standard peripherals such as GPIO, UART, ADC, etc. A block diagram (taken from the online documentation) is given below:

The Avnet Azure Sphere MT3260 Starter Kit board also includes 2 user switches, status LEDs, a multi-coloured user LED, a 3-axis accelerometer and sensors for temperature, etc. There are also mikroBUS, Pmod and Gove connectors to support additional sensors, actuators, displays, etc required for typical IoT applications. These are shown below (taken from the starter kit User Guide).

Software Development Environment Requirements

There are strict software requirements for the development environment. In particular:

Windows 10, version 1607 or later

Microsoft Visual Studio 2017 or later

Microsoft Azure Sphere SDK for Visual Studio Preview, version 19.02 or later

Windows FTDI USB Drivers

I used a laptop with Windows 10 Pro, version 1903, Visual Studio Community 2019 (version 16.3.5) and Azure Sphere SDK version 19.09.  I already had the FTDI driver installed (version 2.12.0.0) since I use an FTDI USB-to-Serial device to connect to other development boards (such as Raspberry Pi and BeagleBone Black).

Setting up Azure Sphere MT3620 Starter Kit

The Azure Sphere is intended to be used in conjunction with the Microsoft’s Azure cloud: it has little use as a stand-alone device. The first step is therefore to create an Azure account to connect the board to. I already had an Azure account associated with my work email but since this roadtest was being done in my own time, I decided to create a new account specifically for the roadtest. To create the Azure account, you need to use the link https://account.azure.com/organization

On this page, you need to create a domain (e.g. atmozsphere), a user (e.g. sphere) and a password

Then login using e.g. sphere@atmozsphere.onmicrosoft.com/organization

The Microsoft Azure home page will open, as shown below, although there is not much to see yet!

You need to associate the Azure Sphere with the Azure account. This is done by creating an “Azure Sphere Tenant” and then “claiming” the device. Note that an Azure Sphere device can only be claimed once – after that it is forever locked to the specified tenant. Creating the tenant and claiming the device are both done using the azsphere command line application:

The azsphere application is also used to configure the Azure Sphere’s WiFi network and to update its operating system (if necessary).

The version of the operating system was initially up-to-date:

The final preparation step is to put the Azure Sphere board into “prep-debug” mode so that it can be programmed and debugged using Visual Studio – in standard operational mode, program updates are done “over-the-air” (OTA) from the Azure cloud.

The next step must be done with administrator rights

Before completing the roadtest, there was an update issued (19.09). The update was installed with the command:

azsphere device recover

After updating the OS, it was necessary to reconfigure the WiFi network settings and put the device into prep-debug mode again.

Creating First Application

The application code can be written with and debugged from Visual Studio. As mentioned above I used the free 2019 Community edition. Brian Willess has created a really helpful series of blogs on the Azure Sphere (https://www.element14.com/community/groups/azuresphere/blog/2019/04/24/avnets-azure-sphere-starter-kit-out-of-box-demo-part-1-of-3) and a series of training videos and labs on the hackster web site: https://www.hackster.io/workshops/azure-sphere-course

I used the workshop labs to get up and running. These labs were based around an example that sampled the accelerometer values and user button states and sent these to an application running in the Azure cloud. The cloud application displayed the values as they changed and also enabled the board LEDs to be turned on and off remotely.

A screenshot of the main function in Visual Studio is shown below:

The first significant step in the Azure cloud was to set up an “IoT Hub” to receive data from the board.

The Azure cloud is a pay to use service with several different tiers available, depending how much data is to be uploaded, processed or saved. Fortunately, the IoT Hub has a free tier available that allows up to 8000 messages to be uploaded per day. You need to take care when enabling the required Azure services since the free ones are not necessarily the default settings!

The IoT Hub needs to be associated with a “Resource Group” that is in turn associated with an Azure subscription account.

The IoT Hub also needs a “provisioning service”:

The data from the Azure Sphere board is linked to a “Digital Twin” in the cloud. The idea is that the digital twin holds a copy of the values sent from the board and also the desired values that should written back to the board (such as the LED states). During a synchronization operation, the desired values are downloaded the board. The digital twin must be created in Azure and corresponding variables for synchronization created in the Visual Studio code.

Visual Studio 2017 includes a feature to automatically add the IoT Hub service to the app_manifest.json file that contains the connection settings. Unfortunately, this does not currently work in Visual Studio 2019 but it is relatively easy to copy the settings and paste into the file manually:

Open Azure DPS - ID Scope -> "CmdArgs": [ "copy here" ]

               - Global device endpoint -> "AllowedConnections": [ "copy here" ]

Open Azure IoT Hub - Hostname - > "AllowedConnections": [.., "copy here" ]

From Azure Sphere command line: azsphere tenant show-selected -> "DeviceAuthentication": "xxxxxxx-xxxxx-xxx-xxxx-xxxxxxxxx"

The IoT Hub Usage page in Azure shows the number of messages that have been sent from the device to the cloud and the number of device twin operations:

Lab 4 described how to set up and display the data in a “Time Series Insights” (TSI) environment. Unfortunately, this service is quite expensive – it is not available under the free tier. I therefore skipped this part of the lab and went on to display the data in the “IoT Central” application instead.

The instructions for lab 5 described how to create an IoT Central application using a pre-written template. The link to the template given in the instructions did not work for me so I set about creating the IoT Central application from scratch, using the lab 5 instructions, the official Azure IoT Central Documentation (https://docs.microsoft.com/en-gb/azure/iot-central/core/) and part 3 of the blog from Brian Willess for guidance.

Creating an IoT Central application initially gave errors:

To correct this error, I had to update my subscription to the pay-to-use S1 level. Fortunately, for the volume of data I will be uploading, this is still effectively free!

Once created, Azure gives you a link to a web page for your application:

The IoT Central application pages allow you to create a template to view the data/settings of your Azure Sphere board.

There is no standard template for the Azure Sphere MT3620 Starter Kit so you need to create a custom template.

Having given the template a name, you can then proceed to set up the “Measurement” fields. The field names correspond to the strings sent in the telemetry messages from the board (e.g. in i2c.c).

The buttons are associated with Measurement Events:

The LED states are controlled using the “Settings” form:

By default, a random data generator provides values for the digital twin to test the graphs:

To get the data from the actual Azure Sphere board it is necessary to use the template to create version that connects to a “real” device:

The real device requires a secure connection. To achieve this, the Azure device provisioning service needs to create a validated X.509 certificate. The first step is to download the Certificate Authority (CA) certificate for your Azure Sphere tenant using azsphere:

The certificate should then be uploaded to IoT Central

Once the certificate has been uploaded, IoT Central generates a verification code. This is copied to the clipboard and then pasted into the azsphere command to sign the device certificate:

Alternatively, there is a dps-keygen app that can generate the signed device key (download dps-keygen from https://github.com/Azure/dps-keygen).

This can be run from a Win64 cmd shell. Go to "Real" device and click Connect - brings up window with IDs and keys required for dps-keygen. Copy scope ID, device ID and primary key to dps-keygen command, e.g.

dps-keygen -di!a6e6811d-6cd9-46c6-b8e4-d2320c97e861 -dk!WfoG9h+uvE8Y6j3oOCJ0J5oE4ZgbX5FEg5Z22WovJ20= -si!0ne00098C3D

Azure IoT DPS Symetric Key Generator v0.3.3

Connection String:

HostName=iotc-06f68aa3-f2cf-40b0-9a67-f6c46e08d3dc.azure-devices.net;DeviceId=a6e6811d-6cd9-46c6-b8e4-d2320c97e861;SharedAccessKey=WfoG9h+uvE8Y6j3oOCJ0J5oE4ZgbX5FEg5Z22WovJ20=

The connection address should be copied to the “AllowedConnections” field of the app_manifest.json file.

If the dps-keygen app is used, it is necessary to copy the output from the command azsphere device show-attached to create a new IoT Central device (the output should be converted to lower case and used as the ID).

The “real” device can then be selected in IoT Central to show the data as it is uploaded and set the LED states when the remote synchronization is activated.

Alternatively, IoT Central has an “Analytics” page to display the data:

I measured the average current while sending the data to IoT Central. It was between 130 – 140 mA.

Impressions

The Azure Sphere MT3620 Start Kit has an impressive list of features and hardware interfaces. As a follow on project, I bought a mikroBus relay and a Grove humidity sensor with the aim of creating an environmental monitoring and control system for an outbuilding with mains electricity and WiFi. Unfortunately, I did not receive my board until the end of September which meant my roadtest coincided with the busiest time of the year for me at work – this additional project will now have to wait until I have more free time.

When I applied for the roadtest, I was particularly interested in the security features of the Azure Sphere. When compared to other devices used for IoT applications with similar computing resources (an Arm Cortex-A7 application processor plus 2 Arm Cortex-M4 MCUs for real-time support), the Azure Sphere is very secure: IoT security has multiple aspects and the Azure Sphere provides good solutions for many of them. Some of the key security features are:

1. The operating system is pre-installed and will be automatically updated over-the-air should Microsoft discover any vulnerabilities that require OS patches
2. The device is locked to a specified Azure account – it is not possible to connect the device to the “wrong” account
3. The identity of a device is authenticated by a “chain of trust” based on X.509 certificates, signed by the Azure root certificate authority.
4. The device uses a “secure boot” system – only the signed authorized application can start up
5. The application software can be updated OTA if security weaknesses or vulnerabilities are discovered
6. The applications manifest JSON file acts as a firewall. Only GPIO devices that have been enabled in the file are accessible (by default, there is no access in the application to GPIO).
7. Debug interfaces are disabled except when the board has been put into the prep-debug mode
8. Messages sent over WiFi always use TLS (handshaking plus encryption)

There are however some areas that do not seem to be addressed by this board:

1. Local data storage and encryption. The SDK reference manual does not describe any functions for secure storage of data (e.g. in a secure file system using on-chip RAM or Flash memory). Additionally, no mechanism for performing encryption/decryption or hashing of stored data is described.
2. The secure socket API does not allow any control over the TLS parameters, e.g. to define a minimum TLS version or encryption mode allowed for sensitive data transmission.

I did not have an opportunity to investigate the “real-time” operation of the Cortex-M MCUs. At present, it appears that the software running on these MCUs (if any) is completely controlled from the Azure Sphere OS – it is not clear if it would be possible to install a Real-Time Operating System (RTOS) on one of the MCUs or how an RTOS-based application could be used (other multi-core devices such as NXP i.MX 7 would typically run embedded Linux applications on the Cortex A7 and an RTOS on the M4 for timing-critical tasks).

This is not a device for remote, battery powered IoT applications (e.g. environmental monitoring). Although 130 mA is respectfully low current consumption for a computing platform (comparable to a Raspberry Pi Zero W) it is far higher than many Cortex-M MCUs. The other issue is that WiFi has a very limited range (<50m) compared to other wireless network technologies such as LoRaWAN (>10km).