RoadTest: AVNET Azure Sphere MT3620 Starter Kit
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?:
What were the biggest problems encountered?: n/a
Goals of this RoadTest
There were two goals for this Roadtest:
This RoadTest review is Part 1, Getting Started
The AVNET Azure Sphere Starter kit includes a Carrier board with the Azure Sphere MT3620 module, a USB Cable, and a Quick Start Card, which contains links to the latest documentation and Azure Sphere Software Development kit.
Avnet Azure Sphere MT3620 Starter Kit
The Avnet Azure Sphere MT3620 Starter Kit supports rapid prototyping of highly secure, end-to-end IoT implementations using Microsoft’s Azure Sphere--a solution for creating highly-secured, connected Microcontroller (MCU) devices,
The kit includes a small form-factor carrier board, featuring a production-ready MT3620 Sphere module, based on the MT3620 SoC, which has built-in Microsoft security, Wi-Fi connectivity, and the combined versatility and power of an Arm® Cortex™-A7 processor with the low overhead and real-time guarantees of two Arm Cortex-M4F microcontrollers.
The carrier board connects the Sphere module I/Os to two MikroE Click sockets, an I2C Grove connector, a connector supporting the addition of a 128 x 64 OLED graphical display, a 3D accelerometer, 3D Gyro, temperature sensor, and an ambient light sensor. Debugging is accomplished through a USB-to-UART interface, which also provides the necessary 5V power for the board.
User applications for the embedded Sphere controller are developed in C using Microsoft’s Visual Studio IDE and the Azure Sphere SDK. The combination of Visual Studio, the versatile carrier card, and the production ready Sphere module delivers a powerful starting point for IoT developers interested in learning, prototyping, and deploying Azure Sphere based solutions.
The first step to get the module up and running is to install the Microsoft Azure Sphere SDK from http://aka.ms/AzureSphereSDK
The installation of the module requires connecting it to the Windows 10 PC via the USB-C cable so that the required drivers can be installed automatically.
The next step is setting up the development environment called the Azure Sphere SDK Preview, which includes
All of this is carefully documented at https://docs.microsoft.com/en-us/azure-sphere/
Installing the Visual Studio extensions can be a lengthy affair depending on the version of Visual Studio you have installed. I had to upgrade my version first before I was able to install the extensions. This process took an unexpectedly long 3 hours.
The next step was to create a Microsoft Azure account. This also caused some grief as I have several Microsoft Azure accounts, and opaque page caching in the browser continued to get in the way to create a working new account. After a couple of tries of creating, logging out, and logging back in, success was had. One troubling assumption that the web application made is to create a domain name out of your company name. Our company name is "Stillwater Supercomputing Inc.", and the Microsoft Azure wizard constructed a domain, stillwatersupercomputing.onmicrosoft.com, which is too long to fit within the Azure portal fields.
When successful, the Microsoft Azure portal will appear with your new Azure account:
Device registration needs to take place via the azsphere CLI. Here the documentation was not consistent, as it asked to check the version of the OS before the device was registered. Once I figured out to ignore the documentation here, and create an Azure tenant and claim the device for that tenant, life became easier:
The nitpick here is that the command 'azsphere' is difficult to type: the first three characters all typed with the left pinky and ring finger: cramping up just thinking about it.
Once claimed, we can proceed to update the OS:
At this point, we were finally able to compile and deploy our first application: the blinking LED.
The Microsoft Azure Sphere MT3620 starter kit is a secure end-to-end IoT device .The MT3620 is a highly integrated, high performance IoT MCU with the high level of security necessary for modern, robust internet-connected devices. The MT3620 targets a wide range of IoT applications including smart home, commercial, industrial and many other domains thanks to its extensive I/O peripheral subsystem that allows device design flexibility and freedom. The MT3620 was designed in close cooperation with Microsoft and is compatible with the Microsoft Azure Sphere solution.
MT3620 features an Arm Cortex-A7 application processor operates up to 500MHz and includes large L1 cache and L2 cache and integrated SRAM for highly efficient operation over a wide range of potential applications. Two general purpose Arm Cortex-M4F I/O subsystems running at up to 200MHz support the requirements of the many on-chip peripherals including 5x UART/I2C/SPI, 2x I2S, 8x ADC, up to 12 PWM counters and up to 72x GPIO, allowing a diverse range of potential applications. These two Cortex-M4F I/O subsystems are primarily intended to support real-time I/O processing but can also be used for general purpose computation and control. The Cortex-M4F cores may run any end-user-provided operating system or run a ‘bare metal app’ with no operating system. Flash memory to support the Cortex-A7 and both Cortex-M4F processors is integrated in the MT3620 package.
The Microsoft Pluton Security Subsystem and Dedicated Wi-Fi Subsystem
Outside of these three end-user accessible cores, MT3620 contains an isolated security subsystem with its own Arm Cortex-M4F core that handles secure boot and secure system operation. In addition, a 1x1 dual-band 802.11a/b/g/n Wi-Fi radio subsystem is controlled by a dedicated Andes N9 32-bit RISC core. This subsystem contains radio, baseband and MAC that is designed to allow high throughput applications with great power efficiency.
Operation of the MT3620 security features and Wi-Fi networking are isolated from, and run independently of, end user applications. Only hardware features supported by Azure Sphere are directly accessible to MT3620 end-users. As such, security features and Wi-Fi are only accessible via defined Azure Sphere APIs and are robust to programming errors in end-user applications regardless of whether these applications run on the Cortex-A7 or the user-accessible Cortex-M4F cores.
Microsoft provides a powerful development environment based on Visual Studio which leverages the gcc compiler, allowing customer applications to be developed in C. Please refer to documentation from Microsoft for information about which hardware features are available to end-user applications.
Microsoft Azure Sphere
MT3620 leverages Microsoft Azure Sphere to provide an unprecedented level of security for connected devices. The secure solution provides device authentication and attestation, supports remote over-the-air software updates to maintain security in the face of evolving attacks, and also automates error logging and reporting.
In the next installment of the RoadTest, we will report on building a simple application that reads the on-board sensors, as a first step towards building a remote IoT device that records its samples in a cloud-based service.
I am still wondering if anyone has taken a closer look at the Pluton security system to find out how "secure" it really is? For instance, it appears that the "firewalls" that control…
My comments below apply when the Azure Sphere Device is in field-prep mode and the only way to load an application onto the device is through the Azure Sphere Security Service and Over the Air…
My comments below apply when the Azure Sphere Device is in field-prep mode and the only way to load an application onto the device is through the Azure Sphere Security Service and Over the Air updates. This is how devices and applications are deployed in a production environment.
The app_manifest.json file is included in the *.imagepackage file that contains the user application. On boot, the secure boot process validates that all application and OS components have been signed by Microsoft and that they are the current authorized applications to run. At that time the firewalls are set using the information in the app_manifest.json file. This is the only time that the firewalls can be set, on boot.
If you were able to somehow replace the app_manifest.json file on the device, the settings would not be used until the next boot. At that time the secure boot process would determine that the *.imagepackage had been modified and should not run. The OS services would then go into what I call recovery mode. That is the device would re-download the authorized *.imagepackage file (application binary + app_manifest.json files) from the Azure Sphere Security Service, reboot with the authorized app_manifest.json file and you're attempt to work around the process would be negated.
I'm sure that there are some details in that I did not communicate, but you get the idea.
I am still wondering if anyone has taken a closer look at the Pluton security system to find out how "secure" it really is? For instance, it appears that the "firewalls" that control access to peripheral addresses are set by simple JSON format strings - Is there any way that an attack could modifiy these???