Arm Mbed OS 5.10 Release: Focus on connectivity, firmware management and ease of use


About this release

In Mbed OS 5.10 we are improving the firmware update user experience. Mbed OS provides integrated firmware over-the-air (OTA) update capability, enabled by Pelion Device Management. Mbed OS now makes this process seamless, providing secure and flexible IoT firmware update, and device management capabilities right from Arm Mbed CLI tool itself. Bluetooth Low Energy (BLE) is quickly becoming the IoT connectivity protocol of choice for a variety of use cases. In Mbed OS 5.10, we are launching Arm Mbed Cordio stack, the world’s first open-source, fully-qualified and production-ready BLE software stack, which supports BLE 5, giving developers even more flexibility when developing new IoT solutions with BLE connectivity.

Security is the most important challenge for IoT developers. Mbed OS is supporting Arm V8M with built in Trustzone functionality, laying the foundations to build highly secure devices. In Mbed OS 5.10, we are now supporting the Nuvoton M2351 based on the latest ARM V8M core. Along with integrating storage components such as, SPIF, SD and FlashIAP block devices, into the Mbed OS repository to simplify the use of storage components.

We’ve listened to user feedback and made content and structure improvements to our documentation. We’re working hard to keep improving, and value your feedback. In addition, this release contains many minor fixes and enhancements and brings support for 145 target development boards. In the release note below, we summarize some of the key updates to Mbed OS that are part of the Mbed OS 5.10.0 release.

Core OS

Enhancing the user experience for firmware OTA updates: Firmware OTA updates are critical for IoT devices to ensure that the IoT device can be maintained throughout its lifecycle. Firmware OTA updates can significantly increase your device’s lifespan. If a device cannot update its firmware over the air, you must go to the field where the device is deployed and update its firmware, which is expensive and not scalable. Mbed OS supports firmware updates enabled by Pelion Device Management and provides flexible, secure and simple IoT device management for any device. It enables the provisioning and connection of IoT end nodes with cost-effective, secure and reliable software updates, ensuring a long product lifetime. In Mbed OS 5.10, we are simplifying the firmware update user experience. This enhancement means you can seamlessly enable firmware update capabilities in your IoT device. Using Mbed CLI, you can perform firmware updates to your device in fewer commands. You can also prepare firmware updates for one or multiple devices. For more information, please refer

Support for ARMv8-M with Nuvoton M2351: Mbed OS supports building highly secure IoT embedded solutions based on the ARMv8-M platform. The most significant enhancement in the ARMv8-M architecture is the inclusion of the TrustZone security extension, a technology that adds a new dimension of security control, and allows multiple security domains within a single processor system, resulting in enhanced security and simplified development. TrustZone enables a “secure world” that keeps important data, such as private keys or pre-shared keys isolated from the main operating system and apps. Mbed OS 5.10 supports Nuvoton M2351, based on the Cortex-M23 processor. Mbed OS also provides all necessary tools to support building and deploying both secure and nonsecure sides of application. Please see for more information.

Integration of storage components inside Mbed OS:Storage functionality is an essential requirement for building IoT devices that store data, firmware images, and credentials on external MCU memory. Throughout the past few Mbed OS releases, we have developed functionality to support many different types of external memories, such as SPI flash and SD card. The storage drivers were developed as external components, allowing to allow continuous development and maturity of those drivers before bringing them inside Mbed OS. In Mbed OS 5.10, we are moving the SD, SPI Flash (SPIF) and FlashIAP drivers into Mbed OS. Integration of storage components into the Mbed OS repository makes it easy to use them, and allowing the simple add-on of default block device and default file system functionality. We added SD, SPIF and FlashIAP block devices under the new component label configured in target.json. Any board with an SD or SPI Flash component enabled has a default block device and file system. For more information, please visit the SDBlockDevice, SPIFBlockDevice and FlashIAPBlockDevice API documentation.

Quad SPI (QSPI) block device driver: With the cost of memory going down rapidly decreasing and performance on MCUs increasing every day, devices are storing more data than ever before. QSPI enables faster data transfer compared to traditional flash, and used with components such as connectivity modules, displays and others. With QSPI, Mbed OS can communicate with external memories much faster than through SPI because the communication can be up to four lines between the host and a device. We are releasing the QSPI block device driver to enable NOR-based QSPI flash devices that support SFDP. For more information, please visit the


Arm Mbed Cordio Bluetooth Low Energy (BLE) stack: Production-ready open source BLE software stack: BLE is quickly becoming the Internet of Things (IoT) connectivity protocol of choice for a variety of use cases, including smart lighting, smart cities and asset tracking, where low cost, power consumption and a small footprint are fundamental requirements. According to the 2018 Bluetooth Market Update, there will be more than 5 billion Bluetooth device shipments by 2022, with 97% of them containing BLE technology. The advances in Bluetooth 5 technology, along with the introduction of Bluetooth Mesh, are driving new market opportunities across building automation, sensor networks and other IoT solutions.

In Mbed OS 5.10, we are adding Arm Mbed Cordio BLE stack to make it easier and more secure for organizations and developers to add BLE to their IoT devices to drive adoption levels to new heights. Arm Mbed Cordio BLE stack is the world’s first open-source, fully-qualified and production-ready BLE software stack, which gives developers even more flexibility in developing new IoT solutions with BLE connectivity. Using Arm Mbed Cordio BLE stack, you can innovate through Bluetooth 5 which supports 2x the data rate, 4x the range and 8x the broadcast capability compared to the previous version, Bluetooth 4.2.

Near field communication (NFC) card emulation mode support: NFC is a short-range radio technology that enables use cases such as contactless payments, access control and device pairing. We are enabling the card emulation mode in Mbed OS 5.10 through an NFC controller or NFC EEPROM. With Mbed OS 5.10, it is now possible to create NDEF messages that can contain device identification, pairing or sensing data. For more information, please visit the NFC API documentation at

Default network interfaces: Mbed OS 5.10 targets that provide network connectivity also provide a default network interface. This can be Ethernet, Wi-Fi, mesh or cellular. Using a default interface allows you to port applications to different targets and connectivity options. Applications no longer require libraries, such as Easy-connect, to be portable.

Refactored Socket API: This release refactors the Mbed OS Socket API by bringing it closer to the POSIX equivalent. The new design contains an abstract socket interface that applications can use directly. Casting Socket pointers back to TCPSocket or UDPSocket is no longer necessary. For most of the applications, these changes are not noticeable because the TCPSocket and UDPSocket classes still emulate previous behavior. The new design also renders the TCPServer API unnecessary, moving its functionality directly into TCPSocket itself. The legacy TCPServer class still exists and is fully functional.

Connectivity stack always built-in: Applications are no longer required to specify FEATURE_NANOSTACK, FEATURE_LWIP or FEATURE_COMMON_PAL to use any of the connectivity stacks that Mbed OS supplies. Those are always included in the build. This change does not increase any flash use because the linker can drop any unused functions.

Connectivity drivers: For easier integration and testing, this release includes some connectivity drivers for external modules, such as the ESP8266 Wi-Fi driver, AT86RF233 driver and MCR20A driver. Now applications using these drivers receive applicable bug fixes every time they update Mbed OS.


Update to Mbed TLS 2.13: Mbed TLS 2.13.0 introduces several new features improving our support for DTLS over low-bandwidth, high-latency networks with high packet loss.


Support for fragmentation of outgoing handshake messages. This allows the use of Mbed TLS across networks with datagram links with MTUs as low as 512 bytes, making it suitable for NB-IOT networks.

Grouping outgoing handshake messages in a single datagram, reducing both the network load and the likelihood of reordering effects.

Reordering handshake packets that have been received out of order, reducing the number of retransmissions necessary to complete a handshake and therefore increasing handshake efficiency and reducing network load.

For more information, please visit

Upcoming Features

Mbed OS is constantly adding new features to support the latest technologies and to make Mbed OS more robust and user friendly. This section identifies what can be expected from the Mbed OS teams in the upcoming releases.

Secure sockets: With secure sockets, your Mbed OS applications can connect to and send data to any cloud or server through any TCP or UDP based protocol in a secure way. By introducing native secure sockets to Mbed OS, we aim to simplify making secure connections for customers by enabling the TLS functionality for secure sockets in background. Secure sockets are currently in development. You can find more information about secure sockets can at

Mbed Crypto APIs: The Mbed Crypto library is a reference implementation of Arm’s Platform Security Architecture (PSA) Cryptography API. Therefore, the library's API documentation is the PSA Cryptography API specification. PSA is a holistic set of threat models, security analyses, hardware and firmware architecture specifications and an open source firmware reference implementation. PSA provides a recipe, based on industry best practices, that allows you to consistently design security at both a hardware and firmware level. The PSA Cryptography API provides access to a set of cryptographic primitives. It has a dual purpose: You can use it in a PSA-compliant platform to build services such as secure boot, secure storage and secure communication. You can also use it independently of other PSA components on any platform. Mbed Crypto APIs are currently in development. You can find more information at

Targets and tools

Thanks to our Partners’ hard work, Mbed OS 5.10 added 10 new target platforms and now supports 145 target platforms. Here’s a sneak peek at the new Mbed Enabled targets added since Mbed OS 5.9 in alphabetical order:

Advantech WISE 1530 -

Avnet AT&T WNC M14A2A Cellular LTE kit -

Nuvoton NUMAKER_PFM_M2351 -



NXP LPCXpresso54628 -

Sigma Delta Tech SDT51822B -

Sigma Delta Tech SDT52832B-

ST Discovery L496AG -

Toshiba TMPM46B -

Toshiba TMPM3H6 -

We’ll continue to add targets in our biweekly patch releases as Partners work with us on support.

Fixes and changes

DAPLink 0250 release: During the 5.10 development cycle, we created DAPLink 0250. This improves the drag-and-drop programming experience when using the Mbed OS bootloader. We recommend anyone using DAPLink upgrade to this version.

The release includes many general enhancements and fixes and upstreams those that we have maintained within the Mbed OS codebase, itself. Please visit for a full list of changes and known issues.

The upgrades should be transparent to developers using the Mbed OS RTOS APIs, but please report in the forums or contact us at if you have any issues in this area.

Testing and improvements

Icetea test framework: Icetea is an automated testing framework for Mbed development. It automates the process of flashing Mbed boards, running tests and accumulating test results into reports. Developers use it for local development as well as for automation in a Continuous Integration Environment. Icetea allows you to execute commands remotely via the command line interface in a device under test. More information is available at

Support for unit tests: Unit tests enable testing of code in small sections on a host machine and don’t require embedded hardware. Unit testing takes place in a build environment where you test each C or C++ class or module in isolation. This means you build test suites into separate test binaries and stub all access outside to remove dependencies on any specific embedded hardware or software combination. This results in much faster testing using native compilers on the build machine. For more information, please visit our unit testing documentation at

Support for Fast Models: Arm Fast Models are software models of Arm cores, subsystems, peripherals and so on. Mbed OS has enabled working with Cortex-M family Fast Models. You can run Mbed OS on the software model instead of the hardware. This give users the flexibility of running and testing Mbed OS and its applications in a hardware-free environment. For the details of running Mbed OS on Fast Models, please visit the Fast Models documentation at

Continuous integration framework:

We designed Mbed OS to significantly reduce cost and time for embedded software development by providing a production-quality toolset and code. We are committed to delivering high-quality code working across all supported boards and platforms. To ensure all the features of code meet our quality control requirements, we have built an automated testing environment and processes that perform rigorous testing on every line of code. The continuous integration framework is a highlight of our testing framework.

The continuous integration framework ensures that every new feature and change in Mbed OS is tested, so that:

For every new feature, we create tests that we then deliver to our Partners. For every board to be Mbed Enabled, we need our Partners to successfully conduct these tests. Partners must test the changes on their boards before submitting pull requests (PRs) on GitHub. Once the PR is submitted, the Mbed OS gatekeepers manually review the code to ensure it meets the coding guidelines and code standards. Once approved by gatekeepers, the code goes through the automated test infrastructure, which tests the submitted code across multiple platforms using three toolchains: IAR, ARM and GCC. During the testing phase, we select the combination of boards and devices that support a variety of peripherals, MCU cores and features for maximum coverage. To ensure the Mbed OS code is compatible with all the IDEs, we test that the code exports properly to all the compilers. We merge the PRs only if all the above procedures are successful.

Below are the summary results for testing conducted for Mbed OS 5.10.0:

- Total test time is 40,293 hours on actual development boards.

- We have added 292 new test cases since the Mbed OS 5.9.0 release to test new and existing features on Mbed OS. The number of total test cases is 1,316.

- The total number of binaries built since the Mbed OS 5.9.0 release is 46,270,224.

We plan to share more details about testing processes, such as our out-of-box testing coverage and system testing, in upcoming release blogs.

Design process and contribution

New design process for Mbed OS: Mbed OS introduces a new design process with the 5.10 release. This makes developing for Mbed OS more fluid by enabling developers to interact with the larger Mbed OS community even during the software design process. With more developers and products embracing Mbed OS, establishing a design process makes large and complex feature development more efficient by having early design reviews and a common design document template. Please see the software design documentation at for more information.

Two-factor authentication required for Mbed OS on GitHub: Security is also important to IoT developers. It is critical to ensure that the code in Mbed OS is contributed from known, secure sources. Two-factor authentication is one method of adding a layer of security to online accounts. This reduces the risk of the account being hacked. For security purposes, this release requires our GitHub contributors to use two-factor authentication on their GitHub accounts. For more information about two-factor authentication on GitHub, please see GitHub’s two-factor authentication information page at . To enable it, please see GitHub’s instructions at

Using the release

Mbed CLI

To take advantage of the new device management and testing framework features, please update Mbed CLI to 1.8.x or later versions. More information is available at the Mbed CLI documentation at

When you create a new program, Mbed CLI automatically imports the latest Mbed OS release. Each release includes all the components: code, build tools and IDE exporters. To update your Mbed OS version or existing program to Mbed OS 5.10.0, run the CLI command mbed update mbed-os-5.10.1

Mbed Online Compiler

When you create a new program, the Arm Mbed Online Compiler automatically uses the latest Mbed OS release. If you want to update your Mbed OS version, right click on the mbed-os library, and press update.


You can also fetch the latest version of the Mbed OS 5.10 release from the mbed-os GitHub repository using the branch “mbed-os-5.10”.

Please feel free to ask any questions or provide feedback about this release on the forum, or to contact us at

Please log in to start a discussion or ask a question.