What's new in Azure Sphere

Azure Sphere is updated on an ongoing basis. Feature releases support new functionality and include both the Azure Sphere OS and the SDK. Quality releases include bug fixes and performance enhancements, and typically include only the Azure Sphere OS. For all releases, the updated OS is automatically downloaded from the cloud to Azure Sphere devices that are connected to the internet.

Devices that receive the Retail Evaluation release of the OS will be updated to the final Retail OS within 24 hours after it is released. The Retail Evaluation release is available for backward compatibility testing 14 days before the Retail OS release. If you are not familiar with the Retail Evaluation program, see Set up devices for OS evaluation to find out how to participate.

What's new in the 20.03 quality release

The 20.03 quality release includes only the Azure Sphere OS. It incorporates the following changes and bug fixes:

  • Updated the Linux kernel to 4.9.213 LTS.
  • Fixed a bug where PWM settings were not updated after PWM output was disabled, the period and duty cycle were changed, and then output was re-enabled.
  • Fixed a bug where the network interface status was incorrectly reported as "Connected" after the network was disabled by a call to Networking_SetInterfaceState.
  • Fixed SPI bugs that could result in kernel crashes.
  • Fixed an issue that could cause the device to run out of memory after repeatedly deleting an application.
  • Fixed a problem that could cause an OS update to loop.

For those who have a valid Azure Sphere OEM Customer License Agreement (CLA), 20.03 is a required Update and use is subject to the terms and conditions of such agreement.

What's new in the 20.01 feature release

The 20.01 release of Azure Sphere includes new features to support power management, error reporting, and to provide better management of data returned by the Azure Sphere Security Service. In addition, this release incorporates enhancements to the OS and SDK to further strengthen the security of devices at customer sites and ensure supportability.

Although our goal is to avoid the introduction of breaking changes and incompatibility between releases, in a few situations, action may be required to ensure that your devices and applications continue to work as intended. Please read Changes in the 20.01 release carefully to learn about changes that might affect you.

To update to the latest OS and SDK

If your devices are connected to the internet, they should receive the OS update from the cloud. However, if you have an older Seeed MT3620 Development Kit that has not been used, you might need to update manually, as described in Update the OS on an early dev kit.

After your devices receive the 20.01 OS, they will be unable to recover or roll back to an earlier Preview release. See Return to earlier Public Preview versions unavailable for more information.

Earlier versions of the SDK do not work with the 20.01 release, and will return Unexpected error or a similar message. To update to the latest SDK, download and install the latest version:

Note

If you installed the 20.01 evaluation SDK during the Retail Evaluation period, you must now install the final SDK so that you can use new features.

To verify the installed OS version on an attached device, use the following command:

azsphere device show-os-version

To check which version of the SDK is installed on your local computer, use the following command:

azsphere show-version

We introduced a new cloud management model with the 19.10 SDK. See About migration for additional information if you have not yet completed the migration to this model.

Important information about devices that have the 20.01 Retail Evaluation OS

Devices that are running the 20.01 Retail Evaluation OS may encounter errors if you move them to a device group that receives the Retail OS feed. Symptoms of this problem are that azsphere continually reports that an OTA update is in progress, but the update never completes; you cannot sideload images from the command line or from an IDE; the device reboots every few minutes.

To prevent this problem:

  • Do not use the azsphere device enable-development command on a device that is in the "Field Test OS Evaluation" or "Production OS Evaluation" group, or in a custom group that receives the RetailEval OS feed. This command moves the device to a group that receives the Retail OS feed.
  • If your device is currently in a device group that receives the RetailEval OS feed, leave it there. We recommend retaining at least one device in such a group at all times.

To resolve this problem:

Recover the device to the 20.01 OS, even if it has already received the 20.01 OS through the RetailEval feed, by using the following command:

azsphere device recover

New features in the 20.01 release

The 20.01 release supports the new user-visible features that are described in the following sections. The release also includes numerous security and infrastructure improvements that are not visible.

Tighter security for deployed devices

Connected device manufacturers and OEMs can disable computer-to-device communications to prevent malicious use by those who have physical access to the device.

Disabling such access is part of device finalization. Finalization is typically performed on the factory floor before the connected device manufacturer ships their product to an end user site, but some dev kit manufacturers may finalize devices as well. After finalization, a user will be able to get the device ID over computer-to-device connection, but all other operations require a device capability.

Field support technicians who need computer-to-device communications for set-up and servicing can download the fieldServicing device capability. Using this capability, a technician can create a servicing session that provides temporary access from a computer. For application developers, the azsphere device enable-development command (which applies the appDevelopment capability) will continue to work as in preview releases.

Power management API

This release includes a new power management API, which enables applications to put the device into the power-down state. See Manage Power Down state for Azure Sphere devices for an overview of its use and Powerdown in the Azure Sphere Samples repo on GitHub for a sample application.

Error reporting

You can now download data about errors and other events that affect your devices by using the azsphere tenant download-error-report command. The downloaded information contains data for all devices in a tenant and can be viewed with Excel or other tools. See Collect and interpret error data for details.

Paged display of device information

The Azure Sphere CLI now supports paging for commands that return large amounts of data. This feature is useful for gathering information about tenants that contain many devices. Display device information describes how to use this feature.

Changes in the 20.01 release

Changes in the 20.01 release affect recovery and rollback, Visual Studio support, and support for several SDK features that may require you to rebuild your applications. Carefully read the following sections to ensure that you take the appropriate measures.

Return to earlier Public Preview versions unavailable

As part of our defense-in-depth against rollback attacks, recovery and rollback to earlier Public Preview versions of the Azure Sphere OS will be unavailable on devices that have already updated to the 20.01 release.

After a device updates to the 20.01 release, it will no longer be able to run an earlier release of the Azure Sphere OS. This means that you will be unable to recover a device to an earlier Public Preview release after it has received the 20.01 update. The 20.01 release will become the earliest release that can be installed on the device.

Visual Studio support

Development of Azure Sphere applications with Visual Studio 2017 is no longer supported starting with the 20.01 release. We released support for Visual Studio Code and Linux in the fall of 2019, and we continue to support Visual Studio 2019. Both Visual Studio 2019 and Visual Studio Code provide additional support for CMake beyond what is available in Visual Studio 2017.

In addition, development with Visual Studio 2019 now requires version 16.4 or more recent.

On Windows, you can compile, build, and debug Azure Sphere apps with Visual Studio 2019, with Visual Studio Code, or the command line.

On Linux, you can compile, build, and debug Azure Sphere apps with Visual Studio Code or the command line.

TLS versions

Libcurl on Azure Sphere supports TLS 1.2 and has deprecated TLS 1.0 and TLS 1.1 in alignment with the broader Microsoft TLS security strategy.

Deprecation of Visual Studio projects

Since the 19.10 SDK release, all new Azure Sphere apps are built using CMake by default. CMake is a cross-platform build system that you can use for all your development: for high-level apps and real-time capable apps; for Windows and Linux; and for development in Visual Studio, Visual Studio Code, or the command line.

The 20.01 SDK release does not support the use of Visual Studio projects (.vcxproj and msbuild). You will need to convert any existing apps to build with CMake. See Convert a Visual Studio project to CMake for guidance.

Deprecation of sysroots 1 and 2

The 20.01 SDK release does not include sysroots 1 and 2, or their corresponding API sets. If you have an app that uses one of these older API sets, you'll need to rebuild it using the 20.01 SDK and retarget it to use API set 3, 4, or 4+Beta2001.

Beta API promotions

In the 20.01 release, the following APIs are promoted from Beta to long-term stable (LTS). For more information on Beta APIs, see Application runtime version, sysroots, and Beta APIs.

Header file API changes from Beta to LTS
eventloop.h EventLoop_RegisterIo parameter type change; function signature unchanged, so existing code should continue to run
networking.h All promoted; interfaceNameLength removed from Networking_NetworkInterface struct
rtc.h No changes; all promoted
storage.h No changes; all promoted
sysevent.h SysEvent_RegisterForEventNotifications parameter type change; function signature unchanged, so existing code should continue to run
stdlib.h getenv, setenv, unsetenv promoted
mman.h memfd_create promoted
tlsutils/deviceauth_curl.h DeviceAuth_SslCtxFunc promoted; DeviceAuth_CurlSslFunc supported as an inline function

Removal of default CA certificates

Starting with the 20.01 release, the Azure Sphere OS no longer contains default CA certificates.

Preview releases of Azure Sphere included several CA certificates for use in authenticating HTTPS servers, and the cURL library was configured to look for these certificates on the device. To provide a more sustainable security environment, the Azure Sphere OS no longer contains these certificates.

Applications that rely on the presence of one or more of these default certificates will require changes. To authenticate a server, you'll need to add the required certificate to the application image package. For details, see Server Authentication.

Default device groups and OS feeds

The new cloud management model includes five default device groups: Development, Field Test, Production, Field Test OS Evaluation, and Production OS Evaluation. We strongly recommend that you maintain at least one device in a device group that receives the RetailEval OS feed, as a best practice. See Set up devices for OS evaluation for details.

Your Development device groups should receive the Retail OS feed. Follow these steps to check the OS Feed Type for your Development device group:

  1. List all products in your tenant:

    azsphere product list

    If your tenant has no products, you can skip the remaining steps; you don't need to change the feed.

  2. For each product, look at the details of the Development device group:

    azsphere device-group show --productname <product> --devicegroupname "Development"

    If the Development device group doesn't exist for this product, use this command to create it now. You can then skip the last step.

    azsphere product device-group create-defaults --productname <product>

  3. If the OS Feed Type is RetailEval, change it to Retail:

    azsphere device-group update --productname <product> --devicegroupname "Development" --osfeed "Retail"

Samples

Most of the real-time capable application (RTApp) samples that Microsoft provided for earlier Preview releases have been removed at this release. Additional drivers and samples for the M4 real-time cores on the MT3620 chip are available on GitHub from Azure Sphere partners MediaTek and Codethink.

Fixed bugs and common vulnerabilities in the 20.01 release

The 20.01 release includes changes to mitigate against the following CVEs for WolfSSL:

  • CVE-2019-19960
  • CVE-2019-19962
  • CVE-2019-19963

Although Microsoft does not believe that Azure Sphere is exploitable as a result of these vulnerabilities, we have nevertheless prioritized mitigation.

Known issues in the 20.01 release

This section lists known issues in the current release.

One-time failures after update

After a device updates to the 20.01 OS, the first attempt to sideload a board configuration image or enable functionality with a capability (such as by using the azsphere device enable-development command) will fail. Retrying this operation should succeed and the operation will no longer fail in the future.

Number of Wi-Fi networks reported

Azure Sphere currently supports a maximum of 37 Wi-Fi networks. Attempts to store more than 37 networks may result in undefined behavior.

CMake path lengths

If the length of your starting directory path is long, CMake returns an error when you open the folder. To avoid this problem, use short paths when developing with CMake.

Inaccurate clock on real-time cores

The GPT0 and GPT1 timers that are built into the real-time cores should use a 32 KHz clock source, but currently they do not run at the correct frequency. Consequently, applications that use these timers will get inaccurate timeouts. For example, a request for a 1-second delay could actually delay for 1.5 seconds. GPT3 has higher resolution, but if your scenario requires more than one timer, you may need to use GPT0 or GPT1. You can work around this issue by implementing a timer queue and running all the timers from GPT3.

Determine where an RTApp runs

By default, the RTApp is deployed to the first available real-time core on the device. To find out which core the application is running on, use the azsphere device app start command to start the application. The azsphere device app show-status command does not currently display this information.

You cannot choose which of the two real-time cores an RTApp runs on.

CMake startup item

When you're developing RTApps with Visual Studio or VS Code, the Select Startup Item menu may reset, resulting in an error when you try to start the application. This tends to occur when you regenerate the CMake cache. Before starting the application, ensure that the menu specifies GDB Debugger (RTCore):

startup item menu

Information for manufacturers about the 20.01 release

This release includes several changes that may affect manufacturers of finished goods:

  • Manufacturers of finished goods have finer-grained options for protecting the software and device from end-user modification. The new Module1Complete and DeviceComplete manufacturing states enable manufacturers to restrict the kinds of modifications users can make to radio settings and device software, respectively. See Set the device manufacturing state for additional details.

    • Module1Complete. The Module1Complete manufacturing state is designed to limit the adjustments users can make to radio configuration settings such as maximum transmit power levels and allowed frequencies. RF commands can be used until Module1Complete is set. Restricting end-user access to these settings may be required to satisfy regulatory policies around radio hardware. This setting primarily affects manufacturers who need to test and calibrate radio operating parameters.

      Microsoft recommends that you set this manufacturing state after radio testing and calibration have been completed; RF commands cannot be used after it is set. The Module1Complete state protects the device against changes that may disrupt proper operation of the radio and other wireless devices in the vicinity.

    • DeviceComplete. The Device Complete manufacturing state allows manufacturers of finished products to secure devices that are deployed in the field against changes. Once a device is placed into the DeviceComplete state, a device-specific capability file is needed to perform any software loading and configuration tasks.

      Do not set DeviceComplete for unfinished devices or modular devices (Wi-Fi modules, development boards, and so forth) that may be used as part of a larger system; this state limits manufacturing activities such as production-line testing, software installation, and configuration.

  • To better serve different manufacturing roles and needs, our manufacturing resources have now been split into three packages. Tools for communicating with attached Azure Sphere devices, loading software, and claiming are distributed as part of the Azure Sphere SDK. The Manufacturing Samples package contains scripts and apps for device manufacturers, and the RF Tools package contains low-level radio tuning and calibration tools intended for Wi-Fi module manufacturers. The Manufacturing Samples and RF Tools packages are available by request from Microsoft.

We recommend that you follow the OS version migration checklist to verify your manufacturing and factory procedures with the new OS and SDK.