Release Notes 19.09
The Azure Sphere 19.09 preview release include the changes, new features, and known issues described in this article.
To update to the latest release
If your Azure Sphere device is already running the 18.11 OS release (or later), is connected to the internet, and is a member of a device group that depends on the Retail OS feed, it should be updated OTA within 24 hours after the new release is available on the Retail feed.
If you have an Azure Sphere device that has never been used, complete all the procedures in Install Azure Sphere. When you complete these steps, your device will be running the OS that the Retail feed delivers and will be ready for application development.
How to verify installation
You can verify the installed OS version by issuing the following command in an Azure Sphere Developer Command Prompt:
azsphere device show-ota-status
To check which version of the SDK is installed, use the following command:
azsphere show-version
New features and changes in the 19.09 release
The 19.09 release includes substantial investments in the Azure Sphere OS support for the MT3620 hardware and in tooling support for additional application development scenarios. The following sections describe new and changed features.
Time server name change
The name of the time server has changed to prod.time.sphere.azure.net instead of time.sphere.azure.net. See Azure Sphere OS networking requirements for details.
Important
Ensure that your network firewall settings enable access to prod.time.sphere.azure.net so that your device can receive over-the-air updates and new certificates.
ADC for high-level applications
The MT3620 supports analog-to-digital (ADC) converters. This release provides support for using ADC on the high-level (A7) core. The ADC folder in the Azure Sphere samples repository contains the ADC_HighLevelApp sample, which shows how to use ADC in a high-level application.
PWM support
The MT3620 supports pulse-width modulation (PWM). This release provides support for using PWM on the high-level (A7) and real-time capable (M4) cores. The PWM folder in the Azure Sphere samples repository contains the PWM_HighLevelApp sample, which shows how to use PWM in a high-level application.
Wi-Fi capabilities
Wi-Fi capabilities have been expanded at this release to enable connection to hidden Wi-Fi networks and to better support network discovery in congested Wi-Fi environments. These features are supported both through the azsphere device wifi command and in the wificonfig API. Note that on the command line, the name of the --key parameter has been changed to --psk and the abbreviation has changed to -p.
Device update deferral
High-level applications can now request notification of pending OS and application updates, so that they can defer updates that would interrupt critical operations. For details, see Defer device updates.
Mutual authentication for web services
This release adds support for mutual authentication in high-level apps that connect to web services. Mutual authentication verifies that both the web server and the client device are legitimate. It is a Beta feature at this release.
API changes
The 19.09 Azure Sphere OS release includes several changes to the API set:
- New Beta APIs for event notification[../reference/applibs-reference/applibs-sysevent/sysevent-overview.md] and event loops. High-level apps can use these APIs to request notification and deferral of updates.
- Changes to the Beta API for networking. Several previous Beta features have been replaced by new functionality. See the networking API reference for details.
- Changes to the wificonfig API. See Applibs wificonfig.h for details.
- Promotion of the SPI API to production/long-term support (LTS) from Beta.
- Promotion of the I2C API to production/LTS from Beta.
Application runtime version
The application runtime version (ARV) has been incremented from 2 to 3 at this release. The Azure Sphere SDK now includes four sysroots: 1, 2, 3, and 3+Beta1909. Support in azsphere commands enables detection of conflicting application and OS dependencies. See Target API sets, ARV, and sysroots for details about ARVs.
Samples
This release provides new sample applications:
Compatibility with the previous release
The 19.09 release supports Target API sets 3, 3+Beta1909, 2, and 1.
For details about compatibility with the previous release, see Target API sets and OS compatibility.
Important
The Networking API, which was a Beta feature in the previous release, remains a Beta feature in this release. However, the API has changed in ways that might break existing code at future releases. See the networking API reference for details.
Known issues in 19.09
This section lists known issues in the current release.
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 problem 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 sideload 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 using CMake, 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):
Installation of both Visual Studio 2017 and Visual Studio 2019 Preview
If you have installed the 18.11 Azure Sphere SDK Preview for Visual Studio with both Visual Studio 2017 and Visual Studio 2019 Preview, the Azure Sphere SDK Preview for Visual Studio installer may fail to install or uninstall on either or both versions with the message "unexpected error". To recover from this problem:
- Start Visual Studio 2019 Preview and go to Extensions > Extensions and Updates. Search for "azure Sphere" and uninstall the Visual Studio Extension for Azure Sphere Preview.
- Close Visual Studio 2019.
- Run the Azure Sphere SDK Preview for Visual Studio installer again.
Wi-Fi commands return device error 13.1
The azsphere device wifi show-status command may return error: device error 13.1 if the most recent azsphere device wifi add command supplied an incorrect --key value. If this occurs, use the azsphere device wifi delete command to delete the incorrect Wi-Fi network configuration and then add the network again with the correct key.
Non-ASCII characters in paths
The Azure Sphere tools do not support non-ASCII characters in paths.
Build errors with C++
The Visual Studio Integrated Development Environment (IDE) does not generate an error if you add a C++ source file to an Azure Sphere project. However, C++ development is not supported with Azure Sphere, and the resulting project will not build correctly.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for