Windows IoT Core booting on SabreLite!!

Finally able to completely boot up Windows IoT Core on my iMX6 SabreLite Platform!

It took quite a bit of work but finally had success! I believe I may be the first one to have Windows IoT Core running on this platform.

I will be doing a pull request to the Project Kayla repo to share my work with the community…stay tuned!

See the Video!

Booting Windows IoT Core on i.MX6SabreLite

Made some good progress on secure booting on the SabreLite platform.

While the SabreLite platform from Boundry Device is getting rather long in the tooth. It is one of the (presently) unsupported platform for Windows IoT Core. I have put in a great deal of time and I now have, at least, a secure u-boot implementation working. I plan on doing a pull request to the private Microsoft repo soon. Just a few more pieces to check out. I anticipate the next steps to be not as difficult as there are some good templates to follow. Stay tuned…

NXP i.MX6/7 secure boot

So it’s been fun digging into the Windows IoT Core implementation on the i.MX platform. One of the most unique features of the Microsoft implementation is the secure boot feature. I have seen and heard lots of hype on IoT implementations on all kinds of platforms. Everything from high end x86/x64 down to the tiny Ardunio claim to be “IoT” ready and everyone seems to be jumping on the band wagon. But one thing I have noticed on many platforms is the lack of a good security infrastructure. This starts from boot up and continues through image loading and onward.

The windows boot process starts with a good solid secure boot infrastructure. Secure boot helps a compute resist attacks and infection from malware. Secure boot relies on the same public/private key (PKI) infrastructure we have become use to such things as secure web transactions and the like.  The private key is stored locally in a private key store an is used with the encryption algorithm to secure the boot code. Some of the newer silicon actually have features which help in this process. Some chips have dedicated I.P. (intellectual property) that will do the encryption based on standard algorithms, like A.E.S. Others may have on chip T.P.M. (Trusted Platform Module). For the i.MX platform we use the H.A.B. (High Assurance Boot or sometimes call High Availability Boot) feature. The HAB library is a sub-component of the boot ROM on i.MX processors. It is responsible for verifying the digital signatures included as part of the product software and ensures that, when the processor is configured as a secure device, no unauthenticated code is allowed to run.

From the developers point of view implementing secure boot can be quite painful. There are several additional steps that must be followed in a very specific order or you stand the chance of totally bricking your device. I have been working on an internal Microsoft project that uses the HAB feature of the i.MX and I have found the work most interesting. While for the time being this work is covered under an N.D.A. you will be hearing more in the near future.  Stay tuned!

.NET core vs. IoT core

The terms .NET Core and IoT Core sometimes get confused. When speaking Microsoft embedded I here these terms confused quite often. So here is the bottom line:

IoT Core is Microsoft’s strategy for crafting a stripped down version of the Windows 10 operating system suitable for running on small, resource constrained devices. These devices are usually embedded devices which may or may not have a display and are targeted for the “Internet of Things” space. The operating system is a “lite” version of the desktop OS running typically on ARM or x86 based devices. IoT Core maintains much of the desktops “look and feel” and the programming API’s so it should be familiar to Windows developers. IoT devices typically interface to IO sensors, acquire data for some local process and may be network connected.

.NET Core is a free, cross-platform, open source developer platform (i.e. framework) for building many different types of applications. .NET Core can run on the Linux or Apple’s macOS operating system. .NET Core supports several languages like C#, F# and Visual Basic. .NET Core does not support all the full .NET (desktop) Framework app-models, in part because many of them are built on Windows technology. .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and programming model.

So remember IoT Core is an operating system while .NET Core is a programming framework.



Windows IoT Core on NXP Saber Lite board

I was pretty stoked with this announcement about NXP’s support for Windows IoT Core.

I was pretty far along the Windows IoT Core learning curve having rebuild and modified the Raspberry Pi BSP and image. I was looking for a new platform to port IoT Core too which lead me to my previous post. The porting to the Beaglebone was a dead end because of the way the interrupts were implemented on the SOC. Now, with the NXP support I have renewed enthusiasm. I am happily contributing to the private repo to broaden the boards supported. In particular I have a “close to working” image running on the Sabre Lite board developed by Boundary Devices. The standard reference SABRE board is already supported so I have a good starting point.

more to come …

.NET Core on Beaglebone and Gumstix platforms

With the release of .NET Core 2.0 its now practical to develop apps with Visual Studio 2017 and run them on BeagleBone and Gumstix platform. You may recall I developed the Windows Embedded Compact BSP for these platform. .NET Core is another twist in that it will run on top of a Debian Linux distro. Linux distro’s are much more popular on these platforms and they also come preinstalled from the factory this way. I have a few simple apps running and hope to be publishing more shortly. Stay tuned…

AndroidThings and Stranger Things debugging.

So on my quest to get Bluetooth LE running on my Raspberry PI AndrodThings (AT) platform I came across a few strange debugging oddities.

AndroidThings uses the same Android Studio for platform and application development just like it’s big brother phone Android. There are some differences thou, and its probably worth your wild to get familiar with these if you plan on doing any significant development. Here are a few things I discovered on my journey .

  1. The API’s are much reduced from the standard Android. This makes sense seeing AndroidThings targets a much more “resource constrained” device.  AT can run on low end platform like the iMX6UL. This is a low cost part with an ARM A7 core. Also, AT can run “headless”, meaning no display so all the baggage associated with higher end display’s removed. There is some good information on the Google site here.
  2. Permissions are also granted differently. Like big boy Android you can declare basic permissions in your apps manifest like the following:
<span class="tag"><manifest</span> <span class="atn">xmlns:android</span><span class="pun">=</span><span class="atv">""</span><span class="pln">
    </span><span class="atn">package</span><span class="pun">=</span><span class="atv">""</span> <span class="tag">></span><span class="pln">
    </span><span class="tag"><uses-permission</span> <span class="atn">android:name</span><span class="pun">=</span><span class="atv">"android.permission.RECEIVE_SMS"</span> <span class="tag">/></span><span class="pln">
</span><span class="tag"></manifest></span>

Permission described in this way are called “normal” permissions. These are permissions that don’t pose much risk to the users privacy. Another set is called “dangerous” permission. Dangerous permissions are things like Internet access or location permission which can, potentially, comprise a users privacy. Granting dangerous permission usually involves another layer of security like explicitly asking the user to grant the permission at app install time or at run time via a dialog popup. Here is where AndrodThings diverges, because an AT device may not have a user interface the Google folks did things a little different. According to the documentation, you can describe both normal and dangerous permissions in the manifest and the dangerous permissions take effect “on the next device reboot”. There is no run time check necessary.

So I was trying to debug my AT Bluetooth app when I ran into this issue. I was trying to set a breakpoint and single-step through the Bluetooth connection process. Initially, it always complained because it did not have permissions so I had to reset it. But if I reset it, it would loose its debug connection. Sounds like a catch 22 situation. The only workaround I was able to make work was the following:

  1. Install and instance of the app.
  2. Reset the device and let the app run.
  3. Start another “debug” instance of the same app.

This seems to have solved the permission issue as I can now set breakpoints and step through the code without permission violation exceptions. I know this is not an ideal solution and logically having two of the same apps running is probably going to raise other issues.

If anyone knows a better way please drop me a comment.





BeagleBone and Windows IoT core?

Some of you may know that I am the author of the Windows Embedded Board Support Package for the BeagleBone development board.

This board comes with a Texas Instruments AM335x Arm Cortex-A8 processor. I developed the BSP as an open source project with all the source code available online. I have had hundreds of downloads when the site was hosted on Codeplex. And now that I moved it to GitHub I continue to receive regular hits (see my previous post).

This made me wonder if it would possible to port Windows Embedded Core to the BeagleBone platform? It seems Microsoft prefers to work with the silicon vendors themselves with this type of endeavor, and obviously so, as who else knows the chips innards better than the creator. Undaunted, I decided to do a bit of research on my own. Here is what I found.

Documentation: The AM335x technical reference manual for the CPU chip is readily available from Texas Instrument’s download site. Be prepared, it over 3000 pages of nitty-gritty detail on every subsystem available on the chip. While doing the Windows Embedded Compact (WEC) BSP port, I found this information to be invaluable.

The Windows IoT Core documentation is another story. Microsoft publishes a lot of really good information on building IoT core images with its IoT Core manufacturing guide. This is good information for customizing images and doing things like adding or removing drivers etc. but it assumes and already developed base BSP. There are a few established BSP’s for the other, already supported, IoT Core platforms and these can be valuable templates to get started. BSP’s of note are the Raspberry Pi, Intel Joule and the Qualcomm DragonBoard 401C. The Joule is not an ARM platform so that leaves it out. The source for DragonBoard’s BSP was not available at the time I was looking. Maybe if you sign an NDA with Qualcomm …but good luck with that. Be aware some BSP’s are only available in compiled form. This means you can uses add and remove drivers but you don’t have access to the actual driver source code. Be warned, most vendors are quite protective of this information and if you ask for it, they will usually give you the runaround. I don’t know how many times I have asked the vendor for BSP information and they will say you have to go to Microsoft. If you ask Microsoft they will say you have to go to the vendor. There is a nasty term for this but I wont use it here. The one BSP that is a good reference and is available in source is the Raspberry Pi. The code is available here.

Boot Code: Windows IoT Core requires EFI start up code. EFI is kind of a universal start up code. You can describe it like a next generation version of U-Boot. UEFI as it is generally known is an open source project, started by Intel to support booting its x86 based products. It was originally designed as a replacement for BIOS which dates back to the original PC days. UEFI is also available for ARM and this is what is used to boot Raspberry Pi. The Raspberry Pi start up code is unique because the ARM A53 core is actually a slave processor of the video core processor. This leads to some weird start up code for the BMC2835 chip. The later generations based on the BMC2839 chip may have changed this a bit.

Can the BeagleBone use UEFI? Absolutely, but I don’t know if anyone has actually done a port. I know the original BeagleBoard (AM3730) does have a UFEI port, and a mater of fact, it is used as one of the reference platform showing how UEFI runs on ARM. Virtually all Linux/Android BeagleBone OS’s boot with U-Boot so you don’t see much interest in a UEFI port.\

Gotcha: So here is the blocker. The TI AM335x interrupt core is a TI design. TI did not use the standard ARM based Intellectual Property (IP) core for the interrupt controller, they decided to do the design themselves. This is not unusual, many vendors that have purchased the full ARM architectural license go their own way for one reason or another. They may have some special peripheral they need to interface to, maybe they felt they could just do it better, maybe the interrupt IP from ARM was not available at the time, or maybe they just did not want to purchase it. Who knows?

But here is the bottom line: Windows IoT Core’s interrupt processing is baked into the core OS code and it assumes the standard ARM’s IP for the interrupt controller. There is no way around this fact that I have found. It would require some fundamental rewiring of the Windows kernel to get this to work and only Microsoft would have the resources needed to do such a port. I see no desire on MS’s part to support a part that is already past its prime in light of the fact there are so many newer, more powerful, parts coming on the market every day.

If anyone knows how to overcome this hurtle please let me know.

In the mean time I am looking another platform as a possible candidate…..stay tuned.



Connecting AndroidThings to Azure IoT part 2

In the previous post I showed how to develop a simple AndroidThings project and deploy it to a Raspberry Pi device. The project sends temperature and humidity sensor reading up to the Azure cloud.

In this post I will show how to consume sensor data in the cloud and publish it to a Power BI dashboard for real-time visual representation. I will start by going back to our Connect The Dots example IoT project. I will add another Azure Streaming Analytics resource to our Connect The Dots resource group. An Azure Streaming Analytics (ASA) job allows for near real-time analysis on “hot” streaming data from a variety of IoT devices. In our case we will be taking input data from our IoTHubStream  (originating from our Connect the Dots IoT hub) and splitting off sensor data and feeding it to the Power BI service as an output (Power BI service being the destination endpoint). Provisioning input and output streams is actually quite easy as Azure is already aware of the existing IoT hub from the resource group and many of the services and selections are just point and click. Here we just show one input, the IoTHubStream and one output, the Power BI service. Of course we could add more …like adding a database as an output sink but lets keep it simple for now.

ASA allows for a “SQL like” query language to condition the data streams. I will use a simple script to direct the sensor data to the output sink.

ASA has additional features that allow you to exercise your query with “test” data. You can actually upload a test json data file or capture a segment of data from the live stream.

If all is set you can start the service and client and hopefully you will see the input and output monitoring graph update as shown above.

The final step is to import the streaming data into a Power BI dashboard. When we set the output in ASA we associated it with our Power BI online account so after logging in and opening the Power BI web service we should see our dataset prepopulated:

From here we can create a new streaming dashboard and populate it with “tiles” that dynamically update.

Fantastic! A streaming dashboard that shows, in real-time, temperature and humidity as originating from an AndroidThings device!

Connecting AndroidThings to Azure IoT part 1

I decided to take a minor detour on my path to using .NET embedding on an AndroidThings device.  As a “get familiar” exercise I decided to connect my Raspberry Pi AndroidThings device to the cloud by using the IoT features of Microsoft Azure. I had previously set up the Connect the Dots  IoT project as another learning exercise so most of the backend Azure stuff has already been provisioned. I added another client device to the Connect The Dots IoT hub named “MyAndroidThingsDevice”.

I then created an empty AndroidThings Android Studio project. I used bits and pieces from the sample IO projects as a starting point. I made sure I had a working “things” Java project that toggled a LED on and off every second running on my Raspberry Pi device. From here I added more Java code from the Microsoft Azure Java IoT SDK  device sample. The SDK has several sample projects that illustrate various aspects of connecting and provisioning an Android client device to the Azure cloud. Merging the two samples allowed me to construct an IoT message for a simulated temperature and humidity sensors which reported to the IoT hub every second. This was also the LED toggle rate so I had a visual indication every time the message was sent.

Here is the code for the start up activity class:

package com.example.davidvescovi.myapplication;

import android.os.Bundle;



import android.os.Handler;
import android.util.Log;
import android.view.KeyEvent;

import java.util.ArrayList;
import java.util.List;

public class MainActivity extends Activity {
    private static final String TAG = MainActivity.class.getSimpleName();
    private static final int INTERVAL_BETWEEN_BLINKS_MS = 1000;
    private static final String CONNECTION_STRING = "";
    private static final String deviceId = "MyAndroidThingsDevice";
    private  static final int D2C_MESSAGE_TIMEOUT = 2000; // 2 seconds
    private  static List failedMessageListOnClose = new ArrayList(); // List of messages that failed on close

    private Handler mHandler = new Handler();
    EventCallback callback = new EventCallback();
    private Gpio mLedGpio;
    private boolean mLedState = false;
    private DeviceClient client;
    double temperature = 0.0;
    double humidity = 0.0;
    int id = 0;

    protected void onCreate(Bundle savedInstanceState) {
        Log.i(TAG, "Starting BlinkActivity");

        PeripheralManagerService service = new PeripheralManagerService();
        try {
            String pinName = BoardDefaults.getGPIOForLED();
            mLedGpio = service.openGpio(pinName);
            Log.i(TAG, "Start blinking LED GPIO pin");
            // Post a Runnable that continuously switch the state of the GPIO, blinking the
            // corresponding LED
        } catch (IOException e) {
            Log.e(TAG, "Error on PeripheralIO API", e);

        try {
            client = new DeviceClient(CONNECTION_STRING, IotHubClientProtocol.MQTT);
        } catch (Exception e) {
            Log.e(TAG, "Error on Azure API", e);


    protected void onDestroy() {
        // Remove pending blink Runnable from the handler.
        // Close the Gpio pin.
        Log.i(TAG, "Closing LED GPIO pin");
        try {
        } catch (IOException e) {
            Log.e(TAG, "Error on PeripheralIO API", e);
        } finally {
            mLedGpio = null;
        // Close the Azure connection.
        Log.i(TAG, "Closing Azure hub connection");
        try {
        } catch (Exception e) {
            Log.e(TAG, "Error on Azure API", e);
        } finally {
            client = null;


    private Runnable mBlinkRunnable = new Runnable() {
        public void run() {
            // Exit Runnable if the GPIO is already closed
            if (mLedGpio == null) {
            try {
                // Toggle the GPIO state
                mLedState = !mLedState;
                Log.d(TAG, "State set to " + mLedState);

                if (client != null)
                    temperature = 20 + Math.random() * 10;
                    humidity = 30 + Math.random() * 20;

                    String msgStr = "{\"deviceId\":\"" + deviceId +"\",\"messageId\":" + id + ",\"temperature\":"+ temperature +",\"humidity\":"+ humidity +"}";
                    Message msg = new Message(msgStr);
                    msg.setProperty("temperatureAlert", temperature > 28 ? "true" : "false");
                    client.sendEventAsync(msg, callback, msg);

                // Reschedule the same runnable in {#INTERVAL_BETWEEN_BLINKS_MS} milliseconds
                mHandler.postDelayed(mBlinkRunnable, INTERVAL_BETWEEN_BLINKS_MS);
            } catch (Exception e) {
                e.printStackTrace(); // Trace the exception

    protected static class EventCallback implements IotHubEventCallback
        public void execute(IotHubStatusCode status, Object context)
            Message msg = (Message) context;

            System.out.println("IoT Hub responded to message "+ msg.getMessageId()  + " with status " +;

            if (status==IotHubStatusCode.MESSAGE_CANCELLED_ONCLOSE)
<span id="mce_marker" data-mce-type="bookmark" data-mce-fragment="1">​</span>

If you use the code be sure to substitute your connection string.

If everything compiles and runs you should see the LED blinking. You can use the “Device Explorer Twin” utility to monitor messages going back and fourth between the device and Azure. You should see something like this on the MONITORING tab:

In my next post I will show how to use Azure Streaming Analytics and Power BI to visualize the AndroidThings temperature and humidity data.