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. Release numbers are typically in year.month format, so 19.11 identifies the release in November, 2019.
If your devices are connected to the internet, they should receive the OS update from the cloud. However, if you have an early 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.
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:
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.
If critical bugs are discovered during the Retail Evaluation period, we may release an updated OS on the Retail Evaluation feed and, in turn, may restart or extend the evaluation period. As possible, we will post notifications on Azure Updates and the Azure Sphere IoT Tech Community blog. The version number of the final retail OS release will reflect any such updates.
What's new in the 20.05 quality release
The 20.05 quality release of the Azure Sphere OS includes changes to strengthen OS security by reducing the denial-of-service attack surface.
In addition, a new sample is now available that shows how to use Azure Sphere and Azure RTOS to implement a real-time capable application.
Independent of this release, we have also published a new paper, Best practices for implementing seven properties in Azure Sphere. This paper describes practices that the Azure Sphere team learned and applied during the development of Azure Sphere.
About the 20.04 feature release
The 20.04 release of Azure Sphere OS includes new features to support EAP-TLS networking and certificate management. A single Windows SDK now supports both Visual Studio and Visual Studio Code; each has its own extension, which is installed separately. Further changes in the 20.04 SDK provide simpler configuration of CMake for building applications on all platforms.
New and enhanced features in the 20.04 release
The 20.04 release supports the new user-visible features that are described in the following sections. The release also includes improvements to ensure a more sustainable infrastructure.
Enterprise connectivity features
The 20.04 release supports Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) to connect to Wi-Fi networks. EAP-TLS provides certificate-based authentication for secure connections to enterprise networks.
See Use EAP-TLS in the online documentation for details about the Azure Sphere EAP-TLS platform and the requirements for local network administrators. EAP-TLS is not supported over Ethernet.
As part of EAP-TLS support, this release also supports:
- A new CertStore API, which provides an interface to store and manage Root CA and client certificates on an Azure Sphere device
- New WifiConfig API features, which enable programmatic configuration, setup, and management of an EAP-TLS network
- Enhanced azsphere CLI commands, so that network administrators can manage certificates and configure EAP-TLS networks from the command line
Because EAP-TLS network configurations require more storage space than other networks, the limit of 37 networks no longer applies. The number of networks you can store on an Azure Sphere device is resource dependent.
Single Windows SDK
The 20.04 release provides a single Windows SDK, which works with Visual Studio, Visual Studio Code, or on the Windows command line. Windows SDK installation now involves downloading and installing this SDK. If you installed the 20.01 SDK or an earlier version, you can install the new SDK without uninstalling the old version.
Separate extensions for Visual Studio and Visual Studio Code that work with this SDK are available in the Marketplace. Both Visual Studio and Visual Studio Code will notify you when an updated extension is available.
The CMake interface for configuring and building Azure Sphere projects has been simplified to provide greater consistency across development environments and command-line interfaces. Configure Builds with CMake describes the new features.
If you already have an Azure Sphere application that was built with CMake prior to the 20.04 SDK, you should convert it to use these new features. You can still build such applications unchanged for now, but support for them is deprecated and may be removed in a future release.
You can use a single instance of Visual Studio or Visual Studio Code to simultaneously debug applications for both the high-level and real-time cores.
The new Certificates sample shows how to store and manage certificates for use in EAP-TLS authentication.
The IntercoreComms sample has been updated to support simultaneous debugging of both the high-level application and the RTApp. The RTApp now sends a message to the high-level app every second and displays any messages that it receives.
The WiFi_HighLevelApp sample has been extended to demonstrate configuration of EAP-TLS networks. See the README.md file for the sample to find out how to modify the sample to configure an EAP-TLS network from a high-level app.
Changes in the 20.04 release
Fixed bugs and common vulnerabilities in the 20.04 release
The 20.04 release includes updates to mitigate against the following CVEs:
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:
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:
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.
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.
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|
|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|
|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:
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.
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>
If the OS Feed Type is RetailEval, change it to Retail:
azsphere device-group update --productname <product> --devicegroupname "Development" --osfeed "Retail"
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:
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 Visual Studio 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):
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
DeviceCompletemanufacturing 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.