RoadTest: AVNET Azure Sphere MT3620 Starter Kit
Author: rogersia
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?:
What were the biggest problems encountered?: Installing all of the software to get the board connected to visual studio before I could even start any development was very time consuming.
Detailed Review:
Unboxing / Installation
Some of my issues related to installation were because I decided to take this on holiday and do all of the work for this roadtest on holiday, only to find I had limited wifi (circa 2mbps).
The MT3620 starter kit comes in quite a small box, with a USB cable. Unpacking the development board and following the quick start guide takes you to the Microsoft Get Started Guide, carefully reading and following the Microsoft guides will result in various instructions that were repeated or link to a page that had been completed previously (You end up being told 3 times to install the Azure Sphere SDK for Visual Studio, 2 times to follow the process to Connect Azure Sphere Device and 2 times to claim the device)
According to the Microsoft instructions, first prerequisite is the Azure Sphere SDK for Visual Studio, actually the first prerequisite is to make sure that you had Visual Studio installed. I already had VS2019 installed which saved having to install that before continuing. Installing the Azure Sphere SDK for Visual Studio took a while to download (Slow internet connection), but is about 200MB, but then when I installed it took about 6+ hours to install and apart from Task Manager stating that the Processor/Hard Drive was actually doing work I would have believed that the application had actually crashed. The laptop I have been using for this road test isn't great (4th Generation i5, but it is generally powerful enough for 99% of my VS development needs).
I have seen that some other users have had problems linking the device to the Azure Account to be used as "Azure Sphere uses Azure Active Directory (AAD) to enforce enterprise access control. Therefore, to use Azure Sphere, you need a Microsoft work or school account (sometimes called an organizational account) that is associated with an AAD.".
The option to create a new account or link a personal account for Azure AD was provided, however this was not an issue as my user account is already associated with an on-premises AD linked to AzureAD. As a result opening the Azure Sphere Developer Command Prompt and doing the "azsphere login" command popped up the login box used with all Microsoft Azure / Office365 services and required me to pick my associated account and then just logged in.
Once the Azure Sphere Developer Command Prompt was logged in, claiming the MT3620 development board and effectively locking it to my user account was relatively simple (azsphere device claim) and then wait for it to communicate with Azure Sphere.
Interestingly, one of the Microsoft instructions after claiming the device is to update the OS (which I followed), however reading later there is a possibility that the units were shipped with OS version that would have automatically updated OTA when connected to WiFi (I wouldn't know as I updated it manually first so the OS on the MT3620 matched the version of the Azure SDK installed. This was another one line command on the Azure Sphere Developer Command Prompt (azsphere device recover) and took about 5 - 10 mins watching the updated on the screen.
The final stage of device configuration was connecting the device to the WiFi network. "azsphere device wifi add --ssid <yourSSID> --psk <yourNetworkKey>". As expected, just worked, the command "azsphere device wifi show-status" showed that everything was correct. Once wifi was connected it was possible to check for available OTA updates(there weren't any as the firmware had already been updated above)
Overall this configuration took quite a long time to complete, some of it was down to the very slow internet connection getting the original files in the first place, but then there was a long period of time trying to install the Azure SDK. It seems that other people have had this problem and others haven't.
The first demo application
Continuing using the Azure Sphere Developer Command Prompt, the devce needed to be set into debug mode with the simple command "azsphere device prep-debug". (Note the way to get this to allow application updates and not use the Visual Studio debugging interface is "azsphere device prep-field")
Once this was complete and the device was in debug mode, it was finally time to get to visual studio and create a new project based on the Azure Sphere Blink Template. This is an example high level application which specifically states it is not recomended to be used as a starting point for developing apps and points to the other projects on "https://github.com/Azure/azure-sphere-samples "
The blink template was (as expected) relatively simple, define a sleep time for the application and then switch the LED on then off waiting the time between each interval, the biggest issue with adjusting the time was calculating a number of seconds interval as nS.
This blink application did demonstrate that the communication with the MT3620 board was working, I could communicate with it and it would do what I expected.
Editing the first application
Once I had the blink example working, the first thing was to make some small modifications to prove that I was going the right direction for that device. So modifying the blink sample to use the the mt3620 header files found on the github samples was the first step as it allowed me to use the #defined descriptive names rather than the pin numbers etc:
There are 3 user LEDs (1 RGB) on the MT3620 kit, RED (Pin 8), GREEN (Pin 9), Blue (Pin 10). The first attempt was to change to using the #defined AVNET_MT3620_SK_USER_LED_RED or the AVNET_MT3620_SK_USER_LED_BLUE change the LED colour on the board, initally neither of these worked, and I realised that I was receiving the error message saying "Error opening GPIO: Permission denied (13). Check that app_manifest.json includes the GPIO used."
So, looking in the AzureSphereBlink solution I see the app_manifest.json file and open it. There are various items in there:
{
"SchemaVersion": 1,
"Name" : "AzureSphereBlink",
"ComponentId" : "6acc286d-034d-4673-a9f4-431bf08d13da",
"EntryPoint": "/bin/app",
"CmdArgs": [],
"Capabilities": {
"AllowedConnections": [],
"Gpio": [ 9 ],
"Uart": [],
"WifiConfig": false
},
"ApplicationType":"Default"
}
Admittedly, this is the first time I have used a microcontroller or system which required permissions for each pin!
A small modification to the gpio line to allow all 3 user LEDs to be accessed and hey presto we can now access the three LEDs
"Gpio": [ 8,9,10 ],
Adding the UART input
Once I had got the device working and modified, I then worked through understanding the UART functions and configuration.
As the compiled high-level code effectively runs on an OS rather than directly on the device it meant that there were a lot if differences to the normal configuration methods I have used for configuring the 8-bit/16-bit microcontrollers generally embedded deep in the products I have previously designed, where 32K flash and 1K ram is considered a luxury!
Fortunately Microsoft have provided the library for the UART as part of the SDK. Rather than configuring the uart itself (as done on a small microcontroller) this was done using a structure which was passed as a pointer to the UART_InitConfig function to configure the UART. Looking back on it now it should not have been unexpected really but it is just different to what I have previously done. I also found that the required version of the UART APP needed to be declared to the UART library. This was made clear on the Microsoft documentation for the UART library
The initialisation wasthen relatively straightforward, declare the variable of the struct UART_Config, and then assign the UART parameters required and open the UART.
Before being able to run the program the app_manifest then needed updating again, this time to include the UART into the permitted functions. I tried various permutations of $AVNET_MT3620_SK_ISU0_UART, "$AVNET_MT3620_SK_ISU0_UART", "AVNET_MT3620_SK_ISU0_UART" and AVNET_MT3620_SK_ISU0_UART with no success.
I then tried the similar options around the defined MT3620_ISU0_UART.
All of these attempts resulted in the error message: "Device would not sideload app: Application manifest specifies peripherals that use the same underlying pin (DeviceClientException)"
Looking through the example code for just used "$SAMPLE_UART" for the app_manifest and SAMPLE_UART which also didn't work and didn't really provide an explanation as to the problem.
However then looking through the Microsoft documentation for the app-manifest, there is the reference that for the high level UART value should use the peripheral name that is declared in the hardware definition header file, and in the Realtime application it is the AppManifestValue that is declared in the hardware definition JSON file.
For me, the first item successfully uploaded such that I could continue debugging was having the Uart configured in the app_manifest as:
"Uart": [ "ISU0" ],
At which point the serial port then started working!
Next Steps
I had intended to get significantly more completed by the end of the roadtest period, however it has been a steeper learning curve getting to this point than expected.
Now that I have the serial port working with data going in and out correctly it was planned that the MT3620 would be linked to the Arduino GPS data logger I have previously created which generates a subset of statistical data as a result of approx 20-30 mins of GPS data. This would be uploaded via wireless UART link using HC-12 comms modules.
However looking at the features on the MT3620 development board, there is the possiblity that the direction of this development will change where the MT3620 will be fitted inside the same enclosure as the GPS and potentially replace the Arduino completely such that GPS processing is done alongside the Gyro / Accelerometer providing an additional layer of data to be processed and uploaded to Azure Sphere.
Conclusions
Frustratingly, the time consumed getting the development kit running originally definitely ate into the amount of time available to cover the remainder of the tasks I had originally intended to complete and as such this review is currently limited in the overall context of where it was intended to go.
Once the development kit was up and running, the support and documentation available around the IDE and the development environment from Microsoft was significantly better than the getting started guides, although there were still some points which did not seem to be as expected (Missing ADC librares from the Azure Sphere SDK as installed on my PC (and even after an update/reinstall)).
Overall, even after this road test I feel that I am just skimming the surface of the range possiblities that the Azure Sphere ecosystem supported by the AVNET Azure Sphere MT3620 Starter Kit provides. There are requirements around the Azure account and other requirements that will make less desirable for hobbyists, however if you already have access to these services then it is a simple addition to integrate into your exsiting account setup.
The hobbyist side of me I will be continuing to develop the GPS datalogger functionality and replace the Arduino with the Azure Sphere MT3620 Development Kit in the application. The work side of me be looking at using another one of these AVNET Azure Sphere MT3620 Starter Kits as a the next step for the current IoT push that managment see as the next big thing and are keen to develop hardware to support existing products.
Top Comments
You confirmed my suspicions and decision not to participate.
My current ADD issues would not have survived the many steps needed to get one of these up and running.
DAB