RoadTest: AVNET Azure Sphere MT3620 Starter Kit
Author: Fred27
Creation date:
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?: The Seed MT3620 Development Kit is the only development board that's a real alternative. Other than that this is a fairly unique product, as the primary goal is to be a secure device managed over Azure. Processor-wise it's similar to the BeagleBone with one Linux core and two real time cores. However, they have very different use cases.
What were the biggest problems encountered?: Getting started is not a easy as it could be. The irrevocable tying of the device to an Azure tenant makes sense for a corporate production use case, but seems odd when developing.
Detailed Review:
Microsoft's Azure Sphere is a unique sort of device. I've kept an eye on it since it was announced about a year ago when it was first revealed. There's even a few excited comments from me on the original accouncement. It's always looked to have untapped potential and recently things have started to look more interesting. New devices came out. The secrets to the M4 real-time cores started to be revealed. And Avnet / E14 really got the ball rolling with a road test, a competition and lots of promotional devices. There are now lots of people wondering what this strange device is all about. For me at least, it's time to jump in.
I'm going to split this road test into two parts. When I originally applied, I intended to take a dive into some of the details of the MediaTek MT3620 processor. The parallels with the BeagleBone intrigued me. Both have an ARM Cortex A series core intended to run Linux. Both have a pair of 32-bit real time processors sitting beside this. They are similar in some ways, but very different in others. However, with the large influx of people trying to find their way around the device, I'm gong to save that for part 2. For this (part 1) of my road test I'm going to try to create a useful overview and a guide to feeling comfortable with the Azure Sphere - and the Avnet Azure Sphere MT3620 starter kit in particular - reasonably quickly.
Chances are, you've probably got one of the Avnet Azure Sphere MT3620 Starter KitsAvnet Azure Sphere MT3620 Starter Kits in front of you - or back ordered and on the way. It is however only one of the options for Azure Sphere hardware. It's probably by far the most popular now, but let's look at the range. Avnet and Seeed already have a few devices available, but there are a few more that may be appearing soon.
| Manufacturer | Header 2 | Device | Price | Description |
|---|---|---|---|---|
| Avnet |  | MT3620 Starter Kit | $75 | This is the equipment I'll be reviewing today. It's a smallish development board with loads of connectors - MikroBUS, Pmod (limited), Grove, and a few more. Of all the devices available, this seems to be the most flexible to get you started developing with Azure Sphere. The price seems pretty reasonable too - especially as many of us will have got the device via one promotion or another. |
| Avnet |  | WiFi Module (chip antenna) | n/a | This device may not yet be available, but it appears to be the same as the module on your MT3620 Starter Kit board. If you really need one today, you could probably desolder it. I've seen June 2019 specified as the release date but that's been and gone. Probably soon though. Maybe don't desolder one just yet! |
| Avnet |  | WiFi Module (U.FL antenna) | n/a | This is very similar to the chip antenna version above, just with a U.FL connector instead. |
| Avnet |  | Guardian Module | n/a | "Unblocks brownfield IoT by bringing Azure Sphere's security to equipment previously deemed too critical to be connected." Available soon 2019
If this picture (from Microsoft's Azure pages) is correct it's very similar to the U.FL antenna module. I love those early prototype green bodge wires. |
| Seeed |  | MT3620 Development Kit | $84.90 | This is the first board ever announced. If you want something smallish but still a development board then maybe this might suit you. Unlike the Avnet board there's not much in the way of peripherals. There's just 52 header pins arranged in a unique layout of 12 and 14-pin dual row headers. There is an Ethernet shield available if that's something you'd find useful.
When it was announced I decided not to go for it. The Azure Sphere ecosystem wasn't really there yet, the M4 cores weren't accessible and it seemed overpriced for what it was. Now that the Avnet kit is available I can't see why many people would go for this. It's $10 more and has less connectivity. Same processor of course. |
| Seeed |  | MT3620 Mini Dev Board | $34.90 | If you want a development board but you want a really small one, then this might be the one for you. I suspect that many people will want a larger dev board for development and prototyping and one of the castellated modules for a small production run. This is the only device that fits a middle ground between the two. |
| Seeed |  | MT3620 Module (AI-Link WF-M620-RSC1) | $19.90 | This appears to be the same minimal castellated module as on the Mini Dev Board. |
| USI |  | Dual Band WiFi Module | n/a | "Supports BLE and Bluetooth 5 Mesh. Can also work as an NFC tag (for non-contact Bluetooth pairing and device provisioning)." Available for prototyping
Very little information on this one too. |
| NXP |
? | i.MX 8 | n/a | "NXP announces a new energy-efficient crossover processor to bring Azure Sphere to the IoT edge"
Well, this is perhaps the most interesting although we won't see anything until Q4 2020, and by then I'd expect a lot to have changed. Apparently the stakes have been raised on the power side of things.
This is the only device not to be based on the MediaTek MT3620. An ARM Cortex A-35 with a Cortex M-33 and HiFi4 DSP? That sounds very interesting. Time will tell, and a lot may change over the next year. |
I bet you thought there was just a couple of Azure Sphere devices available, didn't you? Well, now you know! To be honest though, for most people I feel that the Avnet Starter Kit is probably the best bet. The device it's most comparable with is the Seeed development kit. Compared to that, it has more connectivity and some useful on-board sensors to get you started. There is some nice documentation and sample code provided by Avnet in addition to that by Microsoft. It's also $10 cheaper. A fairly obvious choice. However, if you have a need for a smaller module then some of the others from various manufacturers might fit the bill. The Seeed mini dev board stands out as an in-between option which may suit some scenarios.
So - enough of the options. I've chosen, and you have probably chosen this Avnet development board. It's a good choice primarily because of the myriad of connectors and ancillary devices squeezed into the small (75mm x 55mm) form factor.
The primary connectors are a pair of mikroBUS connectors, each one with 2 rows of 8-pin 0.1" headers. I must admit I've never heard of mikroBUS before. It seems to be something started by MikroElectronica and claims to be "the world fastest growing add-on board standard". There does seem to be a lot of boards available, although as I write this only 7 have been proven to work with sample MT3620 code by Avnet. I'm sure more will work and more sample code will appear as time goes on as to be honest it's all just SPI / I2C / UART so there's little to go wrong. I'm very surprised not to see the OLED-B module supported as yet as it looks like it would fit and there is sample code for a similar SSD1306 display controller available for the MT3620.
There are also an odd combination of extra connectors. There is a single Grove connector which seems to be something started by Seeed. How strange that the Seeed dev board doesn't use it? Personally I find the whole naming thing for shields, booster pack, hats, etc. very annoying so it's good to see the for grove they have dropped the whole "stem" and "twig" concept. 
| Pin | MT3620 | PmodOLED | |
|---|---|---|---|
| 1 | CS | GPIO29_CSA0_CTS0 | CS |
| 2 | MOSI | GPIO26_SCLK0_TX0 | MOSI |
| 3 | MISO | GPIO28_MISO0_RX0_DATA0 | MISO |
| 4 | SCLK | GPIO27_MOSI0_RTS0_CLK0 | SCLK |
| 5 | GND | GND | |
| 6 | VCC | VCC | |
There is a single unpopulated Pmod connector which has been described as UART and BLE only. My only single-connector Pmod is the Pmod OLED board. Once again this has the same SSD1306 display controller as another supported display Unfortunately, after purchasing and soldering the appropriate connector it turns out that two of the pins required for SPI have been swapped. I'm not sure if this was necessary to support the claimed devices or whether it's something that might later be corrected. The first row of the connector is as in the table.
This is another odd one. There is an unpopulated 4-pin connector just to support a small OLED display. The display that's supported uses the SSD1306 display controller as I've previously mentioned. It seems odd that this wasn't just rolled up into OLED-B (or OLED-W) support on the mikroBUS header. Whilst it's a cheap and easily available display, unfortunately it does seem to come with two different connector options. The placement of GND and VCC seems arbitrary. Whilst Avnet did helpfully link to the right one on Amazon I cheaped out and went eBay. You know what eBay is like. Despite ensuring the photo matched the right pinout, I got the other one. My fault entirely of course, but I can't imagine I'll be the only one. It still seems odd that this connector is even there. It's not a bad thing, it's just odd.
There seems to be quite a mish-mash of connectors. I'm not so sure if this adds flexibility or confusion. It does however give me the opportunity to illustrate my point with an XKCD cartoon, so that can only be a good thing.
In addition to the connectors there a few other ancillaries. There's a few switches and LEDs - always useful for a bit of blinky or some simple debugging. There's a 3-axis accelerometer / gyro and a MEMS pressure sensor. These are ideal for playing around with I2C and getting some simple readings to maybe report to Azure IoT Hub or IoT Central. I doubt anyone is going to make a great deal of practical use of these but they're nice t have. It saves you faffing around wiring up something simple when you want to experiment. There is an on-chip temperature sensor in the MT3620 too. However, as with all on-chip sensors it doesn't measure external temperature. It is affected by the heat generated by the processor itself, so whilst it's arguably accurate, it's not very useful.
JTAG debugging and back-channel UART is provided by an FTDI FT4232 which does the job just fine, allowing you to step through code in Visual Studio as easily as it you were coding for a desktop application.
I must admit that I use Visual Studio daily at work. It's an IDE that I'm very familiar with so that colours my perception, but I genuinely feel that it's a great IDE. Both Visual Studio 2017 and 2019 are supported and you can use the free Community Edition. What isn't supported however is any OS other than Windows for your development machine. I suspect that at some point Visual Studio Code on Mac/Linux may be brought in, especially as the device itself runs Linux, but that's probably some way off.
Microsoft provide their own sample code for the MT3620 and it's fairly good. Rather strangely the samples are for the MT3620 Reference Development Board (RDB). Take a look at the table above and it's strangely absent. That's because you can't actually get one. It's a reference design and in Microsoft's attempt to be vendor-agnostic their samples are for this unavailable board. Things aren't as strange as they seem though. I believe both the Seed and Avnet development kits are supersets of this reference design so the examples seem to work well.
Another strange thing about the samples is that as you open the first one Visual Studio will recommend that you install C++ development tools for Linux. I wish I'd taken a screenshot as I can't get it to appear again, even if I uninstall them. If Steve Ballmer had seen this he'd have had a fit. Microsoft recommending Linux tools. Who'd have thought it a decade or two ago. Times have changed!
Avnet also provide some excellent samples that are a bit more specific to their board, and in particular some of the click modules that work well with it. Note that if you're pulling down this repo you will need to include the clickmodules submodule. This is the git command you'll need:
git clone --recurse https://github.com/Avnet/clickboard_demos.git
If you've already pull then repo down and forgotten to include submodules, then this will fix it:
git submodule update --init
At the moment only 7 board are supported for the MT3620 although I'm sure this will grow. You'll find the details here and I'm sure that will be kept up to date, so I won't repeat them unnecessarily.
This is probably what you're here for. Sorry for waffling and taking so long to get round to it. Sorry. We're here now anyway. I've seen a few people struggle to get to grips with Azure Sphere, and to be honest I can see why. Microsoft documentation is usually second to none and Azure documentation is generally up there too. One thing I've found about Azure is that things move fast. New features are constantly being released and what was familiar last month has changes this month. For that reason I'd strongly suggest that this be your golden source of truth when starting out. Right now, I'd have to say it's not perfect. There are a couple of confusing things which I'll try to explain, but it is likely to improve over time and most importantly be kept up to date. I'll run through how I found it, but if it's not 2019 when you're reading this then don't be surprised if my description has aged.
https://docs.microsoft.com/en-gb/azure-sphere/
The guide begins by getting your PC ready for development. It has to be a PC I'm afraid - no Mac or Linux. In fact you need to be running a reasonably recent version of Windows 10. There's nothing too tricky here. If you're starting from Windows 10 then you'll be fine. There is also a VM available with Windows 10 and Visual Studio pre-installed if that suits you, but you will still need to install the Azure Sphere SDK.
The next step listed is "Update the OS" - i.e. the Linux OS on your MT3620 development kit. This step is fine, however it seems to be in the wrong place. You won't be able to update the device until you've claimed your device. This has been flagged to Microsoft so by the time you read this it may have been fixed. Let's put this step aside and come back to it later.
This is the first step that seems to cause some confusion. This part of the guide works as described but could be a little clearer. Most of us will be playing around with Azure Sphere in our own time, so are likely to be using a personal Azure account rather than what's described as a "work/school" one. I would guess that many people playing with a kit given out by Avnet will have only just created their first Azure account, so the distinction will be doubly confusing.
Follow the part of the guide that tells you to create an account userID@domainname.onmicrosoft.com. Firstly you'll be wondering what to put for domainname. Did you get something like this annoying error below? "'xxx' is not a verified domain name in this directory." What exactly is a verified domain name in this directory? Well, my Azure account is linked to a personal email address and that forms part of the default domain name. You can see what yours is by clicking on the "Directory and subscription" icon at the top. I named mine sphere, so it became sphere@fred27xxxxxxxxxx.onmicrosoft.com.
| {gallery} Creating a working account |
|---|
IMAGE TITLE: Trying to create an Azure AD account |
IMAGE TITLE: Checking what your default domain name is |
IMAGE TITLE: Account created |
Now this is an an area which probably seems a little strange. Your Azure Sphere device must be irrevocably tied to an Azure tenant. What? Why? That makes no sense. Well, it doesn't if you think of it as a development board, but it does when you consider the bigger picture of what Azure Sphere is all about. More on that later. For now, just trust me that you need to do this. Obviously do it carefully and don't pick some random Azure tenant where you've not written down at least the email address you used to log in! As usual, the official guide is the best one to follow, but I'll point out some potential pitfalls here.
You're initially asked to log in at the Azure Sphere command prompt using the command
azsphere login
You will need to ensure that you use the new login you just created. This is the one that is a "proper" Azure AD account and has permissions to do what you need to do. The irony that your main account has permissions to create this account but not do what that account can do is not lost on me. If you don't use the correct account you'll see an error as shown on the right. I've also shown selection of the correct account (sphere@fred27xxxxxxxxx.onmicrsoft.com).
Once you're logged in you may get this warning that there are no tenants found but that's OK - we're going to create one.
Creating the tenant and claiming the device should be fairly easy once you're logged in with an appropriate account and goes much like this:
The next steps are to configure WiFi so your device can connect to the outside world. This just involves giving it the SSID and key for your WiFi network.
Remember that earlier step where the Microsoft guide suggested updating the Linus OS on the device. Well now we're ready to do this.
| {gallery} Update the OS |
|---|
IMAGE TITLE: Show OS status |
IMAGE TITLE: Updating the OS |
IMAGE TITLE: OS update done |
Unlike most microcontrollers, Azure Sphere is setup by default to only accept encrypted and signed over-the-air updates via Azure. We need to tell it to let us load code onto the main Linux core. We also need to tell it (if required) that we want to load code to the realtime M4 cores. Do both now. Why not. Live a little. Note that if you want to put the device into a production scenario, "azsphere device prep-field" is the command to reverse this.
So, we've finally got the the interesting bit where we can start running code on the device. Why all the trouble, you might be thinking. For most microcontrollers this takes way less time. Install the IDE and off you go. Well, the reason is all down to what Azure Sphere is for. It's designed first and foremost to be a secure device running in production for a corporate entity monitoring and controlling lots of devices in the field. It's designed to make the production bit easier, not the hobbyist development bit. It's also designed with security first, not as an afterthought.
Does that make sense? Imagine a vending machine company with thousands of vending machines reporting back stock levels and asking for maintenance. These will all be linked to one corporate Azure Sphere tenant. You won't want it to be possible to deploy malicious code from else where. Locking it down make it more awkward to get started with development but secure without having to tack that on as an afterthought - or not at all.
Blinky time! The first thing you always do with a new device it spin up some sample code. Probably blinky just to test out the toolchain. Rather than repeat information about this, I'm going to point you to a number of existing well written guides. This "getting started" series is probably the best. It's written with exactly this device in mind.
Avnet's Azure Sphere Starter-Kit (Out of Box Demo) Part 1 of 3
There's also some good code provided by Microsoft here: https://github.com/Azure/azure-sphere-samples and their documentation continues on after installation .
One of the priorities I had was to get this road test out there and help those who have hit some bumps in the road getting started. I'll write more about working with the device later as I discover it myself. I intend to delve into the M4 cores. I'm going to explore the mystery of the missing datasheets. Anyone else find the lack of a MT3620 datasheet odd?
For now though, I hope this has helped get you track to using your new Azure Sphere board.
Top Comments
Well done for getting this Part 1 published quickly to help people who might be struggling.
I was interested to discover that the device can store more than one set of wireless network credentials. I took…
David
I commend you on the well researched and helpful roadtest review! A quick clarification here regarding the pinout of the Pmod interface...
There were a couple of design goals for the unpopulated …
Fred27 that’s some new information I learnt from this initial review. Thanks for sharing! Hope you uncover the remaining mysteries as well.