├── .gitignore ├── CONTRIBUTING.md ├── Contributing to mbed.md ├── Contributor Docs └── README.md ├── LICENSE ├── README.md ├── Release Docs ├── mbed OS 15.11 Known Issues.md ├── mbed OS 15.11 Release Notes.md └── mbed_OS_Known_Issues_16_03.md ├── Reporting Bugs.md ├── examples.json ├── mbed_OS_Release_note_16_03.md └── module.json /.gitignore: -------------------------------------------------------------------------------- 1 | **.swp 2 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ARM mbed OS is an Open Source project. We encourage you to pitch in, and we 2 | welcome contributions and [bug reports](../../issues). 3 | 4 | * If you want to submit a bug report please make sure to follow our 5 | [reporting guidelines](Reporting Bugs.md). 6 | 7 | * If you want to submit a patch, please read the 8 | [contribution guide](Contributing to mbed.md). Note that we have a 9 | [Contributor Agreement](http://developer.mbed.org/contributor_agreement/) 10 | that must be agreed to before contributions can be merged. To agree to the 11 | contributor agreement, you need to have an mbed.com account and be logged in. 12 | **We only accept [bug reports](../../issues) and [pull requests](../../pulls) 13 | via GitHub.** 14 | 15 | * If you have a question about how to use mbed OS, please search the 16 | [mbed forums](http://forums.mbed.com/c/mbed-os), and if you still need help, 17 | post a new topic there. 18 | 19 | * Before contributing an enhancement (new feature, new port etc) please start by 20 | [discussing it on the forums](http://forums.mbed.com/c/mbed-os) 21 | to avoid duplication of work - we or others might already be working on it. 22 | This will help streamline your pull request for getting it merged quickly. 23 | 24 | * If you work for an [mbed Partner company](http://www.mbed.com/en/partners/our-partners/), 25 | you will have a partner manager assigned to you who can help you navigate the 26 | process and get the best out of your partnership. 27 | 28 | Thanks! :heart: 29 | 30 | mbed Team @ ARM 31 | -------------------------------------------------------------------------------- /Contributing to mbed.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | ## Code Style 4 | 5 | We want to keep a consistent code style in all mbed OS code, and thus we require 6 | that contributions match our code style, which is documented 7 | [here](https://developer.mbed.org/teams/SDK-Development/wiki/mbed-sdk-coding-style). 8 | 9 | ## Contributing Code 10 | 11 | - Before contributing an enhancement (new feature, new port etc) please start by [discussing it on the forums](http://forums.mbed.com/c/mbed-os) to avoid duplication of work - as we or others might work on a related feature already. This will help streamline your pull request for getting it merged quickly. 12 | - Please create seperate patches for functional patches and form patches. Form patches are effectively just whitespace changes. As part of our security review of incoming patches we run an whitespace-unaware diff that ignores tabs, spaces, newlines etc. The resulting diff of a form patch must be zero differnce to the master when ignoring whitespaces and linefeeds. 13 | - by using ```git diff --check HEAD~1``` you can highlight whitespace errors in your last commit 14 | - with ```git diff --minimal --word-diff-regex=[^[:space:]] --word-diff=porcelain -w HEAD~1``` you can highlight just the functional changes 15 | - Patch contributions can be only accepted through github by creating pull request from forked versions of our repositories. This allows us to review the contributions in a user friendly and reliable way under public scrutiny. 16 | 17 | ## Contributor License Agreement 18 | 19 | -------------------------------------------------------------------------------- /Contributor Docs/README.md: -------------------------------------------------------------------------------- 1 | This directory (will) contain higher level, conceptual documentation on mbed 2 | OS: how it works, how to use it, how to design APIs, how to port to new hardware, 3 | coding and design guidelines, etc, **intended for contributors to mbed OS itself**. 4 | 5 | For user and technical documentation, please look on 6 | [docs.mbed.com](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/). 7 | 8 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ARM Mbed OS 3 2 | 3 | **Please note: Mbed OS 3 documentation is no longer maintained. For the latest Mbed OS documentation see the [Mbed OS 5 site](https://os.mbed.com/docs/).** 4 | 5 | Welcome to [ARM mbed OS](http://www.mbed.com/en/development/software/mbed-os/), 6 | an operating system for ARM microcontrollers designed for the Internet of Things. 7 | 8 | mbed OS 3 is modular: its code base comprises a number of software components, combined 9 | together and built using [yotta](http://docs.yottabuild.org/). This means the code 10 | lives in a number of repositories, each covering a distinct functionality. 11 | 12 | ## Current release 13 | 14 | We are not working on any new releases for Mbed OS 3. For out latest releases, please see the [Mbed OS 5 releases page](https://os.mbed.com/releases/). 15 | 16 | ## Getting Started 17 | 18 | We have [getting started](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/) 19 | documentation on our [docs.mbed.com](https://docs.mbed.com/) site. It includes 20 | an installation guide, a quick start guide and a full developer guide. 21 | 22 | We also have a number of examples to help you get started: 23 | 24 | ## Code 25 | 26 | The code for mbed OS can be found in these repos: 27 | 28 | * **Core OS modules** 29 | * [core-util](https://github.com/ARMmbed/core-util) -- core data structures 30 | and primitives for the OS. 31 | * [minar](https://github.com/ARMmbed/minar) -- MINAR, the mbed OS event 32 | scheduler. 33 | * [minar-platform](https://github.com/ARMmbed/minar-platform) -- 34 | platform-specific adaptation for MINAR. 35 | * [minar-platform-mbed](https://github.com/ARMmbed/minar-platform-mbed) -- 36 | generic MINAR platform adaptation using the mbed HAL. 37 | * [ualloc](https://github.com/ARMmbed/ualloc) -- memory allocation for mbed 38 | OS. 39 | * [dlmalloc](https://github.com/ARMmbed/dlmalloc) -- Doug Lea's legendary 40 | memory allocator. 41 | * [uvisor](https://github.com/ARMmbed/uvisor) -- the mbed OS uVisor, a 42 | supervisory kernel for security on mbed OS. 43 | * [uvisor-lib](https://github.com/ARMmbed/uvisor-lib) -- APIs for interacting 44 | with the uVisor and incorporating it into your system. 45 | * [compiler-polyfill](https://github.com/ARMmbed/compiler-polyfill) -- common 46 | compiler intrinsics and attributes made portable across toolchains. 47 | * **Hardware Abstraction & Drivers** 48 | * [cmsis-core](https://github.com/ARMmbed/cmsis-core) -- CMSIS-Core, ARM's 49 | official low level hardware abstraction for Cortex-M. 50 | * [cmsis-core-freescale](https://github.com/ARMmbed/cmsis-core-freescale) -- 51 | generic implementation of CMSIS-Core for Freescale devices. 52 | * [cmsis-core-k64f](https://github.com/ARMmbed/cmsis-core-k64f) -- 53 | specific implementation for the Freescale K64F MCU family. 54 | * [cmsis-core-nordic](https://github.com/ARMmbed/cmsis-core-nordic) -- 55 | generic implementation of CMSIS-Core for Nordic Semi devices. 56 | * [cmsis-core-nrf51822](https://github.com/ARMmbed/cmsis-core-nrf51822) -- 57 | specific implementation for the Nordic nRF51 family. 58 | * [cmsis-core-st](https://github.com/ARMmbed/cmsis-core-st) -- generic 59 | implementation of CMSIS-Core for ST devices. 60 | * [cmsis-core-stm32f4](https://github.com/ARMmbed/cmsis-core-stm32f4) -- 61 | generic implementation of CMSIS-Core for the STM32F4 family. 62 | * [cmsis-core-stm32f429xi](https://github.com/ARMmbed/cmsis-core-stm32f429xi) 63 | -- specific implementation of CMSIS-Core for the STM32F429. 64 | * [cmsis-core-silabs](https://github.com/ARMmbed/cmsis-core-silabs) -- 65 | generic implementation of CMSIS-Core for Silicon Labs devices. 66 | * [cmsis-core-efm32gg](https://github.com/ARMmbed/cmsis-core-efm32gg) 67 | -- specific implementation of CMSIS-Core for the EFM32 Giant Gecko family of MCUs. 68 | * [cmsis-core-efm32hg](https://github.com/ARMmbed/cmsis-core-efm32hg) 69 | -- specific implementation of CMSIS-Core for the EFM32 Happy Gecko family of MCUs. 70 | * [mbed-drivers](https://github.com/ARMmbed/mbed-drivers) -- abstract drivers 71 | for common hardware peripherals and communications interfaces (SPI, I2C 72 | etc). Provides a higher level interface than the mbed HAL; these are the 73 | APIs that applications should use. 74 | * [mbed-hal](https://github.com/ARMmbed/mbed-hal) -- the mbed Hardware 75 | Abstraction Layer (HAL). 76 | * [mbed-hal-freescale](https://github.com/ARMmbed/mbed-hal-freescale) -- 77 | implementation of the mbed HAL for Freescale devices. 78 | * [mbed-hal-ksdk-mcu](https://github.com/ARMmbed/mbed-hal-ksdk-mcu) -- 79 | implementation for Freescale MCUs using Freescale KSDK. 80 | * [mbed-hal-k64f](https://github.com/ARMmbed/mbed-hal-k64f) -- 81 | implementation for the K64F. 82 | * [mbed-hal-frdm-k64f](https://github.com/ARMmbed/mbed-hal-frdm-k64f) -- 83 | specific implementation for the Frdm-K64F development board. 84 | * [mbed-hal-nordic](https://github.com/ARMmbed/mbed-hal-nordic) -- 85 | implementation for Nordic Semi devices. 86 | * [mbed-hal-nrf51822-mcu](https://github.com/ARMmbed/mbed-hal-nrf51822-mcu) 87 | -- implementation for the nRF51822 wireless MCU. 88 | * [mbed-hal-mkit](https://github.com/ARMmbed/mbed-hal-mkit) -- 89 | implementation for the Nordic nRF51822-mKIT development board. 90 | * [mbed-hal-st](https://github.com/ARMmbed/mbed-hal-st) -- implementation 91 | for ST devices 92 | * [mbed-hal-st-stm32f4](https://github.com/ARMmbed/mbed-hal-st-stm32f4) -- 93 | implementation for the STM32F4 family. 94 | * [mbed-hal-st-stm32cubef4](https://github.com/ARMmbed/mbed-hal-st-stm32cubef4) 95 | -- implementation for ST MCUs using the STM32CubeF4 library. 96 | * [mbed-hal-st-stm32f429zi](https://github.com/ARMmbed/mbed-hal-st-stm32f429zi) 97 | -- implementation for the STM32F429. 98 | * [mbed-hal-silabs](https://github.com/ARMmbed/mbed-hal-silabs) -- 99 | implementation for Silicon Labs devices. 100 | * [mbed-hal-efm32gg](https://github.com/ARMmbed/mbed-hal-efm32gg) 101 | -- implementation for the EFM32 Giant Gecko MCUs. 102 | * [mbed-hal-efm32hg](https://github.com/ARMmbed/mbed-hal-efm32hg) 103 | -- implementation for the EFM32 Happy Gecko MCUs. 104 | * [atmel-rf-driver](https://github.com/ARMmbed/atmel-rf-driver) -- PHY driver 105 | for the Atmel AT86RF2xx series of 802.15.4 radios, for mesh networking in 106 | mbed OS. 107 | * **Networking & Connectivity** 108 | * [sal](https://github.com/ARMmbed/sal) -- mbed OS's socket abstraction layer 109 | (SAL). This enables the various ARM and partner networking stacks to have a 110 | common interface. 111 | * [sal-iface-eth](https://github.com/ARMmbed/sal-iface-eth) -- support for 112 | Ethernet interfaces. 113 | * [sal-iface-6lowpan](https://github.com/ARMmbed/sal-iface-6lowpan) -- 114 | support for 6LoWPAN network interfaces. 115 | * [sal-stack-lwip](https://github.com/ARMmbed/sal-stack-lwip) -- the third 116 | party LwIP (lightweight IP) networking stack. Currently this only supports 117 | IPv4 over ethernet or WiFi, and will be replaced by a new IPv4/v6 unified 118 | stack in the future. 119 | * [sal-driver-lwip-k64f-eth](https://github.com/ARMmbed/sal-driver-lwip-k64f-eth) 120 | -- driver for the Freescale K64F ethernet interface in LwIP. 121 | * [sal-stack-nanostack](https://github.com/ARMmbed/sal-stack-nanostack) -- 122 | ARM's NanoStack 6LoWPAN/mesh networking stack. 123 | * [sal-stack-nanostack-eventloop](https://github.com/ARMmbed/sal-stack-nanostack-eventloop) 124 | -- event loop integration for NanoStack. 125 | * [sockets](https://github.com/ARMmbed/sockets) -- high level portable socket 126 | layer (sitting on top of the SAL). 127 | * [ble](https://github.com/ARMmbed/ble) -- APIs for using Bluetooth Low 128 | Energy. 129 | * [ble-nrf51822](https://github.com/ARMmbed/ble-nrf51822) -- implementation 130 | of the BLE APIs for Nordic nRF51822. 131 | * [mbed-mesh-api](https://github.com/ARMmbed/mbed-mesh-api) -- APIs for 132 | initialising and using the mesh network. 133 | * [mbedtls](https://github.com/ARMmbed/mbedtls) -- [mbed TLS](https://tls.mbed.org/), 134 | the SSL/TLS stack (including cryptographic and certification handling 135 | functionality). 136 | * **mbed Client** -- means for connecting to and managing mbed OS devices 137 | with mbed Device Server or mbed Device Connector. This includes the OMA 138 | LWM2M client, CoAP protocol implementations, and related functionality. 139 | * [mbed-client-c](https://github.com/ARMmbed/mbed-client-c) -- core library 140 | in C. 141 | * [mbed-client](https://github.com/ARMmbed/mbed-client) -- C++ API (use this 142 | one rather than the C one, as it's much easier to use correctly). 143 | * [mbed-client-mbed-os](https://github.com/ARMmbed/mbed-client-mbed-os) -- 144 | mbed OS specific implementation for mbed Client. 145 | * [mbed-client-mbedtls](https://github.com/ARMmbed/mbed-client-mbedtls) -- 146 | mbed TLS specific implementation for mbed Client. 147 | * **Tools & Utilities** 148 | * [yotta](https://github.com/ARMmbed/yotta) -- component management, configuration 149 | and build. **Start here**, as you _need_ to get familiar with this tool to use 150 | mbed OS! 151 | * [helloyotta](https://github.com/ARMmbed/helloyotta) -- example project for yotta. 152 | * [greentea](https://github.com/ARMmbed/greentea) -- regression testing tool. 153 | * [htrun](https://github.com/ARMmbed/htrun) -- test runner for host-supervised 154 | tests. 155 | * [mbed-ls](https://github.com/ARMmbed/mbed-ls) -- utility for detecting and listing 156 | mbed Enabled development boards attached to the development host. 157 | * [utest](https://github.com/ARMmbed/utest) -- simple test harness for C++ with greentea integration. 158 | * [unity](https://github.com/ARMmbed/unity) -- utest compatible test macros from the unity test framework 159 | 160 | The following modules define the [yotta targets](http://docs.yottabuild.org/tutorial/targets.html) 161 | we support building mbed OS for. Currently we only support the following boards: 162 | 163 | 1. [Freescale FRDM-K64F](http://www.mbed.com/en/development/hardware/boards/freescale/frdm_k64f/) 164 | board -- a powerful and flexible development board based around the Freescale 165 | K64F Kinetis MK64FN1M0VLL12 MCU. It has a high performance ARM® Cortex™-M4 166 | Core (with Floating point unit and DSP extensions), clocked at up to 120MHz, 167 | paired with 256KB RAM, 1MB FLASH and a wide array of peripherals. This is 168 | currently the best supported development board for mbed OS; networking 169 | (ethernet, and mesh with a 802.15.4 radio shield), cryptographic 170 | acceleration, and other features are supported already in this beta release. 171 | You can use either ARM's C/C++ compiler, or the open source GCC compiler. 172 | * [target-frdm-k64f-armcc](https://github.com/ARMmbed/target-frdm-k64f-armcc) 173 | * [target-frdm-k64f-gcc](https://github.com/ARMmbed/target-frdm-k64f-gcc) 174 | 1. [ST STM32F429I Discovery](http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090) 175 | board -- based on the STM32F429ZIT6 microcontroller with 2 MB of Flash memory, 176 | 256 KB of RAM, and a Cortex-M4 (with FPU and DSP) that can be clocked up to 177 | 180 MHz. **Currently this board and MCU is not as well supported as the K64F, 178 | especially if you want to use uVisor, networking or mbed TLS (which are not yet 179 | supported).** 180 | * [target-st-stm32f429i-disco](https://github.com/ARMmbed/target-st-stm32f429i-disco) 181 | * NOTE: we don't yet support armcc for this target. 182 | 1. [Nordic nRF51-DK](https://developer.mbed.org/platforms/Nordic-nRF51-DK/) 183 | board -- based around the Nordic nRF51822 Bluetooth Smart/Low Energy device, 184 | this has a Cortex-M0 core, with 256 kB of flash and 16-32 kB of RAM. Due to 185 | much of the RAM being reserved for Nordic's "SoftDevice" BLE stack, only a 186 | small amount of RAM is available for mbed OS and your application, thus this 187 | board is best for simpler applications such as BLE peripherals. 188 | * [target-nrf51dk-gcc](https://github.com/rgrover/target-nrf51dk-gcc) 189 | * [target-nrf51dk-armcc](https://github.com/ARMmbed/target-nrf51dk-armcc) 190 | 1. [EFM32 Giant Gecko STK](https://www.mbed.com/en/development/hardware/boards/siliconlabs/efm32giantgecko/) 191 | board –- Low-power Cortex-M3 with 1 MB of flash, 128 kB of RAM and a lot of 192 | low-power peripherals. This board allows development of bigger applications 193 | with long battery life, such as wearables. **Currently this board and MCU is 194 | not as well supported as the K64F, especially if you want to use uVisor, 195 | networking or mbed TLS (which are not yet supported).** 196 | * [target-efm32gg-stk-gcc](https://github.com/ARMmbed/target-efm32gg-stk-gcc) 197 | * NOTE: we don't yet support armcc for this target. 198 | 1. [EFM32 Happy Gecko STK](https://www.mbed.com/en/development/hardware/boards/siliconlabs/efm32happygecko/) 199 | board –- Low-power Cortex-M0+ with 64 kB of flash and 8 kB of RAM and a lot 200 | of low-power peripherals. This board is better suited for development of 201 | smaller nodes with power and space constraints. **Currently this board and 202 | MCU is not as well supported as the K64F, especially if you want to use 203 | uVisor, networking or mbed TLS (which are not yet supported).** 204 | * [target-efm32hg-stk-gcc](https://github.com/ARMmbed/target-efm32hg-stk-gcc) 205 | * NOTE: we don't yet support armcc for this target. 206 | 207 | Finally, there are a number of yotta targets that provide shared functionality: 208 | 209 | * [target-mbed-armcc](https://github.com/ARMmbed/target-mbed-armcc) 210 | * [target-mbed-gcc](https://github.com/ARMmbed/target-mbed-gcc) 211 | 212 | 213 | * [mbed-client-examples](https://github.com/ARMmbed/mbed-client-examples) 214 | * [mbed-example-network](https://github.com/ARMmbed/mbed-example-network) 215 | * [example-asynch-i2c](https://github.com/ARMmbed/example-asynch-i2c) 216 | * [example-asynch-serial](https://github.com/ARMmbed/example-asynch-serial) 217 | * [example-asynch-spi](https://github.com/ARMmbed/example-asynch-spi) 218 | * [mbed-client-example-6lowpan](https://github.com/ARMmbed/mbed-client-example-6lowpan) 219 | * [uvisor-helloworld](https://github.com/ARMmbed/uvisor-helloworld) 220 | * [ble-examples](https://github.com/ARMmbed/ble-examples) 221 | -------------------------------------------------------------------------------- /Release Docs/mbed OS 15.11 Known Issues.md: -------------------------------------------------------------------------------- 1 | # mbed OS 15.11 Known Issues 2 | 3 | ## About this document 4 | 5 | This is the list of known issues for the 15.11 release of 6 | [mbed OS](https://github.com/ARMmbed/mbed-os). We publish mbed OS as a collection 7 | of modules in GitHub, and track open issues as tickets in each repository. That 8 | makes for an easy development flow, but doesn’t make it very easy for you to get 9 | a single view of all the issues that affect the whole release. 10 | 11 | The purpose of this document is to provide that single view of all the key issues 12 | we are aware of. It isn’t a complete list; it’s a filtered and reviewed list, 13 | focusing on the issues we thought you’d want to be aware of. Each item explains 14 | the problem, as well as workarounds if those are possible. For items filed through 15 | GitHub, we’ve included a link to the issue so that you can follow the discussion 16 | and code - or even suggest a solution. 17 | 18 | For more information about an issue, contact us on the [mbed forums](http://forums.mbed.com). 19 | 20 | ### Other information not in this document 21 | 22 | We’re still very actively building mbed OS and the 15.11 release is a technology 23 | preview. As such there are some other limitations of the release that you can 24 | find described in the 25 | [release note](https://www.mbed.com/en/development/software/mbed-os/releases/mbed-os1511). 26 | This document doesn’t provide a complete list of known issues for experimental 27 | features, such as Thread; those will be published in subsequent releases. 28 | 29 | Other tools such as [yotta](https://github.com/ARMmbed/yotta) and 30 | [greentea](https://github.com/ARMmbed/greentea) also have their own lists, which 31 | you can see in their public GitHub repositories. 32 | 33 | #### Important Note for Windows Users 34 | 35 | If you are using this release on Microsoft Windows, please be advised that 36 | because of the way Windows handles filename and paths, you may have problems 37 | if you attempt to use this in a deep directory hierarchy with a long 38 | path name (e.g. `c:\some\very\long\path`). If you experience problems 39 | unpacking or building this release, please try it in a location with a 40 | shorter path before filing a bug. Thanks. 41 | 42 | *** 43 | 44 | ### `mbed-client-example-6lowpan` does not work with armcc 5.03 in Thread mode 45 | 46 | *Description*: When building the example application using armcc compiler 47 | version 5.03, it does not join the Thread network anymore. 48 | 49 | *Workaround*: None 50 | 51 | *Reported Issue*: https://github.com/ARMmbed/mbed-client-example-6lowpan/issues/35 52 | 53 | *Priority*: Critical 54 | 55 | ### Mesh network is insecure 56 | 57 | *Description*: Mesh network is insecure: 58 | 59 | * `mbed-mesh-api` does not provide an API for changing the security settings. 60 | * gateway binary releases are currently operating in insecure mode. 61 | 62 | *Workaround*: None 63 | 64 | *Reported Issue*: ARM internal reference ONME-2076 65 | 66 | *Priority*: Critical 67 | 68 | ### core-util allocators should not be copiable 69 | 70 | *Description*: PoolAllocator and ExtendablePoolAllocator are currently copiable. 71 | This is not desirable because copying either of these structures could lead to 72 | broken behaviour, such as double-allocations and double-frees. This also affects 73 | BinaryHeap indirectly, since it is built on top of ExtendablePoolAllocator. 74 | 75 | *Workaround*: Until PoolAllocator, ExtendablePoolAllocator, and BinaryHeap are 76 | fixed, care should be taken to ensure that they are only ever passed by reference 77 | and that no assignments are done to objects of either of these classes. 78 | 79 | *Reported Issue*: https://github.com/ARMmbed/core-util/issues/11 80 | 81 | *Priority*: Critical 82 | 83 | ### BLE service discovery procedure may fail with long UUIDs 84 | 85 | *Description*: When a BLE API Gatt Client launches a discovery procedure, it can 86 | fail if the client discovers a server which uses long UUIDs. Such failure will leave 87 | the BLE stack in an inconsistent state. 88 | 89 | *Workaround*: None 90 | 91 | *Reported Issue*: https://github.com/ARMmbed/ble-nrf51822/issues/27 92 | 93 | *Priority*: Critical 94 | 95 | ### uVisor cannot be enabled on targets built with armcc 96 | 97 | *Description*: Some uVisor APIs rely on complex inline assembly, which is not 98 | fully supported by the ARM Compiler 5. Their implementation requires a completely 99 | different approach, which we are working on. For this release though, we will not 100 | support armcc. 101 | 102 | *Workaround*: All targets that support uVisor and are built with armcc will still 103 | compile and work, but the security features of uVisor will not be available. uVisor 104 | APIs will still be available, but no security measure will be enabled. 105 | 106 | *Reported Issue*: https://github.com/ARMmbed/uvisor/issues/89 107 | 108 | *Priority*: Critical 109 | 110 | ### ICMP ping fails to last hop, which radio packet MTU size (127) allows to join network 111 | 112 | *Description*: When radio packet MTU is 127 bytes, the ICMP ping reaches only nodes 113 | that are at maximum nine hops away. 114 | 115 | *Workaround*: None 116 | 117 | *Reported Issue*: ARM internal reference ONME-1611 118 | 119 | *Priority*: Major 120 | 121 | ### Multicast (MPL) ping does not work over seven hops 122 | 123 | *Description*: Multicast (MPL) ICMPv6 echo packets do not get forwarded after six hops. 124 | 125 | *Workaround*: None 126 | 127 | *Reported Issue*: ARM internal reference ONME-1686 128 | 129 | *Priority*: Major 130 | 131 | ### RPL: On routing loop, an error flag is not set in the Hop-by-hop RPL option 132 | 133 | *Description*: Routing loop is not detected with data packets in a three-node loop. 134 | Data packets get forwarded but no proper flag is set. 135 | 136 | *Workaround*: None 137 | 138 | *Reported Issue*: ARM internal reference ONME-2017 139 | 140 | *Priority*: Major 141 | 142 | ### 6LoWPAN socket adaptation layer does not support DNS 143 | 144 | *Description*: 6LoWPAN socket adaptation layer does not support DNS. 145 | 146 | *Workaround*: IPv6 addresses must be given in ASCII format. 147 | 148 | *Reported Issue*: https://github.com/ARMmbed/sal-iface-6lowpan/issues/12 149 | 150 | *Priority*: Major 151 | 152 | ### 6LoWPAN socket adaptation layer has incomplete C++ API 153 | 154 | *Description*: The following mbed C++ Socket API methods are not implemented 155 | in `sal-iface-6lowpan`: 156 | 157 | * `socket_accept` 158 | * `socket_start_listen` 159 | * `socket_stop_listen` 160 | * `send_to` (for TCP sockets) 161 | * `recv_from` (for TCP sockets) 162 | * `set_option` 163 | * `get_option` 164 | * `is_bound` 165 | * `get_local_addr` 166 | * `get_remote_addr` 167 | * `get_local_port` 168 | * `get_remote_port` 169 | 170 | *Workaround*: None 171 | 172 | *Reported Issue*: https://github.com/ARMmbed/sal-iface-6lowpan/issues/11 173 | 174 | *Priority*: Major 175 | 176 | ### RPL does not select secondary parent when switching primary parent. 177 | 178 | *Description*: When mesh network is set up using 6LoWPAN-ND mode, the networking 179 | stack automatically selects the RPL primary parent for routing. When a better 180 | primary parent candidate appears in the network, it is selected - but the previous 181 | primary is not delegated to be a secondary parent. This is non-optimal behaviour 182 | for an RPL mesh network. 183 | 184 | *Workaround*: None 185 | 186 | *Reported Issue*: 187 | 188 | *Priority*: Major 189 | 190 | ### Only a single sal-stack can be used with the socket API 191 | 192 | *Description*: The mbed OS socket API handles the periodic task provided by the 193 | SAL incorrectly. Because of this, only a single stack can be used at a time. 194 | 195 | *Workaround*: Use the SAL to extract the periodic function 196 | (`void (*task)() = socket_get_api(STACK_ID)->periodic_task()`) and periodic interval 197 | (`uint32_t interval = socket_get_api(STACK_ID)->periodic_interval()`), then schedule 198 | a recurring callback in MINAR for each stack 199 | (`minar::Scheduler::postCallback(task).period(minar::milliseconds(interval)`). 200 | 201 | *Reported Issue*: https://github.com/ARMmbed/sockets/issues/36 202 | 203 | *Priority*: Major 204 | 205 | ### Weak symbols are not overridden 206 | 207 | *Description*: Weak symbols compiled using yotta with a mbed-gcc derived target are 208 | not overridden. This is because linking is done through archives, not object files. 209 | When ld finds a weak symbol in an archive, it is only overridden if it finds a strong 210 | symbol in an object file. If a strong symbol exists in an archive, it is not used 211 | because archives are only inspected if a symbol is missing and weak symbols are not 212 | strictly missing. The most obvious effect of this defect is that `mbed_mac_address` 213 | is not overridden. 214 | 215 | *Workaround*: Currently, there is no workaround. It is possible that one could be 216 | implemented with yotta config, specifically for mbed_mac_address, but there is no 217 | obvious general solution other than migrating code away from using weak symbols. 218 | 219 | *Reported Issue*: https://github.com/ARMmbed/mbed-hal-frdm-k64f/issues/3 220 | 221 | *Priority*: Major 222 | 223 | ### Distinguish between read and write access faults in uVisor 224 | 225 | *Description*: When creating a read-only region in uVisor, write access will create an 226 | access fault as expected, but it needs to avoid configuring the corresponding MPU 227 | region again. The intended behavior is to fault with a security exception. 228 | 229 | *Workaround*: Do not write to read-only memory regions. 230 | 231 | *Reported Issue*: https://github.com/ARMmbed/uvisor/issues/68 232 | 233 | *Priority*: Major 234 | 235 | ### Hardware floating point is currently disabled 236 | 237 | *Description*: uVisor has not yet implemented full handling of the FPU register 238 | file and exception model. Until the FPU is fully supported in uVisor, mbed OS must 239 | be used with hardware floating point disabled. 240 | 241 | *Workaround*: Soft-floating point can be used (providing complete functionality, 242 | but with a performance and power impact compared to hard-FP). 243 | 244 | *Reported Issue*: https://github.com/ARMmbed/uvisor/issues/88 245 | 246 | *Priority*: Major 247 | 248 | ### mbed Client will occasionally disconnect from LWM2M Server because of network errors 249 | 250 | *Description*: If mbed Client is kept running for long durations (over 24 hours) 251 | with long lifetime values, it occasionally goes offline due to unstable network 252 | conditions - and doesn't send periodic updates to LWM2M server. 253 | 254 | *Workaround*: Set the periodic lifetime value to less than 15 minutes if you want 255 | to run stability tests. Also, implement a network error handling mechanism on the 256 | application side, to handle `error()` callbacks received from the mbed-client library. 257 | 258 | *Reported Issue*: ARM internal reference IOTCLT-206 259 | 260 | *Priority*: Major 261 | 262 | ### mbed Client might experience a memory leak when running for long durations 263 | 264 | *Description*: mbed Client might have memory leak issues when left running for 265 | longer than 12 hours. 266 | 267 | *Workaround*: None 268 | 269 | *Reported Issue*: ARM internal reference IOTCLT-290 270 | 271 | *Priority*: Major 272 | 273 | ### mbed Client API may not be fully interoperable with other LWM2M servers. 274 | 275 | *Description*: mbed Client API is OMA LWM2M compatible. However, some features may 276 | not be fully interoperable against other open source LWM2M servers. This is the 277 | first release version and more features will be made interoperable over coming releases. 278 | 279 | *Workaround*: mbed Client is compatible with mbed Device Connector Service, which 280 | can be tested at [https://connector.mbed.com](https://connector.mbed.com). 281 | 282 | *Reported Issue*: ARM internal reference IOTCLT-366 283 | 284 | *Priority*: Major 285 | 286 | ### DTLS datagram drop on single record header epoch failure 287 | 288 | *Description*: When mbed TLS is acting as a client, it will resend the last five 289 | datagrams packet after a server reply is lost. When working with some implementations, 290 | there is a risk that invalid datagrams could be generated by mbed TLS which could 291 | lead to further packet loss and failed connections. This will only occur with some 292 | implementations of DTLS on lossy networks. 293 | 294 | *Workaround*: We recommend application code should retry the handshake on timeout 295 | of a successful handshake. 296 | 297 | *Reported Issue*: https://github.com/ARMmbed/mbedtls/issues/345 298 | 299 | *Priority*: Major 300 | 301 | ### Static IPv6 mode is not supported with current mesh gateway binary images 302 | 303 | *Description*: Currently provided binaries for mbed mesh gateway do not support 304 | statically set IPv6 addresses. 305 | 306 | *Workaround*: Dynamic IPv6 bootstrap must be used. It relies on ICMPv6 router 307 | advertisements from ethernet segment. 308 | 309 | *Reported Issue*: https://github.com/ARMmbed/mbed-client-example-6lowpan/issues/38 310 | 311 | *Priority*: Minor 312 | 313 | ### LwIP does not use random source port and sequence number in TCP connections 314 | 315 | *Description*: LwIP should use random source ports and sequence numbers in TCP 316 | connections. Failing to do so means that remote hosts can ignore connection 317 | requests by a device running LwIP when a connection is improperly closed and 318 | reopened, for example by a reset. 319 | 320 | *Workaround*: Manually bind a socket to a random port before connecting to a 321 | remote host. Suggested source of randomness is mbed TLS's entropy pool and 322 | random number generator. 323 | 324 | *Reported Issue*: https://github.com/ARMmbed/sockets/issues/17 325 | 326 | *Priority*: Minor 327 | 328 | ### Floating point format is not supported in printf() 329 | 330 | *Description*: If floating point data is passed to printf(), a blank space will 331 | be displayed. 332 | 333 | *Workaround*: None 334 | 335 | *Reported Issue*: https://github.com/ARMmbed/target-mbed-gcc/issues/17 336 | 337 | *Priority*: Minor 338 | 339 | -------------------------------------------------------------------------------- /Release Docs/mbed OS 15.11 Release Notes.md: -------------------------------------------------------------------------------- 1 | # mbed OS 15.11 Technology Preview Release Note 2 | 3 | This is the first public Technology Preview of mbed OS and associated tools. We're 4 | actively working on mbed OS and we expect to make exciting changes in the next six 5 | months. We're making this technology preview available so you can see the trajectory 6 | we're on. Our focus in this release is on laying the foundation for mbed OS 7 | development and collaboration, particularly core tools, technology and testing. 8 | 9 | We expect mbed OS developers to be able to access, build and run example projects 10 | and to explore the underlying code. 11 | 12 | If you're already using earlier versions of mbed, please note that mbed OS is a 13 | new operating system; although it shares some code with mbed Classic, it has its 14 | own structure, tools, APIs and philosophy. We recommend reading the links below 15 | to understand how mbed OS differs from mbed Classic and what you need to do to 16 | take full advantage of mbed OS. 17 | 18 | ## About this release 19 | 20 | Note that this is a technology preview release, offering you early access to key 21 | features and innovations enabling you to test functionality. This release is not 22 | yet suitable for volume production use. The software is still maturing, and a number 23 | of things will change, including module names, repository URLs, APIs, header file 24 | names and configuration parameters. We'll try to mitigate the impact that these 25 | changes have on your code where possible, but please expect backwards-incompatible 26 | changes. 27 | 28 | Note that in this release we're changing our version numbering scheme for mbed 29 | OS releases, to a calendar-based (year and month YY.MM) scheme. This release (15.11) 30 | has previously been called 3.0 in some communications. 31 | 32 | ## Collaboration 33 | 34 | We're building mbed OS as a collaborative project, bringing together industry and 35 | open source community contributions. If you'd like to work on mbed OS with us, we'd 36 | encourage you to pitch in. With this technology preview we're ready to start receiving 37 | contributions back from the community. 38 | 39 | ## Documentation 40 | 41 | To get started with mbed OS, please visit our Getting Started Guides, which describe 42 | the tools you need to use mbed OS, how to build and run your 43 | [first mbed OS program](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/FirstProjectmbedOS/) 44 | and where to find 45 | [a few more examples](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/GetTheCode/). 46 | 47 | To find out more about how mbed OS is structured and the services currently available 48 | in mbed OS, please visit the mbed OS repository on GitHub. It contains a list of 49 | the code repositories used in mbed OS, a list of the currently supported targets 50 | and other useful information. 51 | 52 | ## Feature Readiness 53 | 54 | The following features are currently experimental: 55 | 56 | * `sal-stack-nanostack` 57 | * The mbed mesh networking stack includes an implementation of the Thread 1.0 58 | specification that is considered experimental. ARM intends to provide full 59 | production support for Thread following completion of the Thread standard. 60 | * `mbed-mesh-api` 61 | * The mbed-mesh-api, which allows using 6LoWPAN mesh networks, currently uses 62 | static configuration. It does not provide an API for selecting the node operating 63 | mode, security option, radio channel or other options that are needed for 64 | connecting to 6LoWPAN networks. Configuration support will be available in later 65 | releases. 66 | * *mbed TLS* 67 | * Support for EC J-PAKE is experimental and the Thread specification which requires 68 | it is itself not yet final. Random number generation is not yet suitable for 69 | use in production. 70 | * `mbed-drivers` 71 | * Various APIs (including the asynchronous ones) are a work in progress; their 72 | signatures are expected to evolve over the next few releases. 73 | * `mbed-hal` 74 | * The mbed HAL APIs are subject to change. The current HAL APIs are an evolution 75 | of the blocking APIs from mbed Classic, and have a number of limitations. In 76 | particular, the current APIs lack robust error handling (a requirement for 77 | production use), as well as consistent use of clock and power management and 78 | DMA and documented implementation criteria and acceptance tests. We have big 79 | plans for the HAL. As with all other parts of the OS, we will signal 80 | incompatible changes to the HAL through the use of semantic versioning. 81 | * `uvisor` 82 | * This version of the uVisor is an early tech preview, which has partial 83 | implementation of the security features that will be present in future versions. 84 | Please use this release for ensuring compatibility with uVisor (interrupt handling, 85 | memory protection model etc) but do not rely on it for security. 86 | 87 | If you have any questions or comments about the readiness of features, please post 88 | in the mbed forum. 89 | 90 | ## Target Availability 91 | 92 | Currently the only target device officially supported by the ARM mbed team is the 93 | Freescale FRDM-K64F board (yotta targets: `frdm-k64f-gcc` and `frdm-k64f-armcc`). 94 | 95 | The following targets have experimental support: 96 | 97 | * NXP JN5179 98 | * ST Nucleo F401 and DISCO-F429I 99 | * Nordic nRF51 DK and nRF51822-mKIT. 100 | * BBC micro:bit. 101 | * SiLabs EFM32 Giant Gecko and EFM32 Happy Gecko 102 | 103 | This document will be updated shortly with instructions on how to use mbed OS on 104 | these targets. 105 | 106 | ## Changes since the last release 107 | 108 | This section documents the changes between this release and the earlier 109 | mbed OS Beta (15.09) release. 110 | 111 | ### Core libraries 112 | 113 | * `minar` 114 | * Fixed a bug that forced some callbacks to be scheduled in the past. 115 | * Removed dependency on `mbed-drivers`. 116 | * `ualloc` 117 | * All headers are now in the `ualloc` header (`mbed-alloc` folder deprecated). 118 | * `core-util` 119 | * `FunctionPointer` and `Event` are now in `core-util`. 120 | * `mbed-drivers` 121 | * `Event` and `FunctionPointer` moved to `core-util` module. 122 | * `mbed_sdk_init` renamed to `hal_init`. 123 | * In SPI, we replaced the asynchronous API with a "fluent API" (to allow easier 124 | selection of optional parameters). 125 | * All headers are now in `mbed-drivers` directory (`mbed` directory deprecated). 126 | 127 | ### HAL and CMSIS 128 | 129 | * `mbed-hal` 130 | * Pin maps can now be specified using `yotta config`. 131 | * Serial: The bit width of the transfer word is now deprecated and will be 132 | removed in the future. 133 | * STM32: Fixed prescaler computation for LPTMR. HSE config can now be 134 | specified through yotta config. Asynchronous SPI implementation. 135 | 136 | ### Networking 137 | 138 | #### 6LoWPAN/Thread stack 139 | 140 | * UDP socket connect, send, close and bind functionality changed to match mbed OS 141 | C++ Socket API. 142 | * Interoperability improvements against Thread 1.0 specification. 143 | * 6LoWPAN stack documentation published to 144 | [docs.mbed.com](https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/). 145 | * Added configuration for different operating modes. 146 | * Various bug fixes. 147 | 148 | #### Networking Libraries 149 | 150 | * `sal` 151 | * Switched to dependency based on `yotta config`. 152 | * Added `get_options` and `set_options` to the API. 153 | * Moved include files to `sal/`. 154 | * `sal-stack-lwip`: Moved include files to `sal-stack-lwip`. 155 | * `sockets`: Moved include files to `sockets/`. 156 | 157 | ### Tools 158 | 159 | #### yotta 160 | 161 | The full yotta changelog can be found [here](https://github.com/ARMmbed/yotta/releases). 162 | This release requires yotta 0.9.1 or greater. 163 | 164 | #### Test Tools 165 | 166 | * `greentea` 167 | * Added better support to latest yotta versions. 168 | * Changed application workflow to support one mbed target test execution for 169 | every specified target. 170 | * Added support for pylint scans. 171 | * `htrun` 172 | * Small improvements to host OS support and documentation. 173 | * Added command line switch `-b` to send break command to devices. 174 | * Added support for pylint scans. 175 | * `mbed-ls` 176 | * Added `--mock` command line switch; useful when prototyping and detecting new 177 | targets. 178 | * Fixed issue related to target detection on Ubuntu and Mac OS X. 179 | * Added support for pylint scans. 180 | 181 | #### uVisor 182 | 183 | The main new feature of this release is support for STM32F4 ARM Cortex-M4 devices 184 | using the ARM architected memory protection unit (MPU). In this release we support 185 | the two following target platforms for uVisor: 186 | 187 | * Freescale FRDM-K64F (GCC ARM Embedded toolchain). 188 | * ST STM32F429I-DISCO (GCC ARM Embedded toolchain). 189 | 190 | The previous beta release (15.09) demonstrated the creation of a sandbox that 191 | allocates private memories and requests individual access to security critical 192 | system peripherals using access control lists (ACLs) and demonstrating 193 | unprivileged interrupts. In this release we updated our example code with 194 | MINAR eventing. 195 | 196 | We also added secure box contexts to provide efficient box-specific secure memories. 197 | These can be used for storing box-specific class instances, or other 198 | security-critical data that needs to be restricted to individual boxes. 199 | 200 | To demonstrate µVisor we created a simple exploit demo: when pressing a switch on 201 | the development board, the main mbed box attempts to read a secured password. The 202 | µVisor will intercept that attempt and deny access by halting the code (five red 203 | blinks). The error handling will be 204 | [improved in future releases](https://github.com/ARMmbed/uvisor#word-of-caution) 205 | by supporting configurable debug channels. 206 | 207 | Most complete information about the µVisor component can be found in the 208 | [µVisor GitHub repository](https://github.com/ARMmbed/uvisor) and 209 | [known issues](https://github.com/ARMmbed/uvisor/issues?q=is%3Aopen+is%3Aissue+label%3Aissue) 210 | list. 211 | 212 | #### mbed TLS 213 | 214 | This release is based on mbed TLS 2.2.0, while the mbed OS Beta (15.09) release 215 | was based on mbed TLS 2.1.0. Major changes between those versions include: 216 | 217 | A new integrated C++ class library for TLS connections (currently only TLS clients) 218 | in the companion module 219 | [mbed-tls-sockets](http://yotta.mbed.com/#/module/mbed-tls-sockets/0.1.0). 220 | Experimental support for the EC J-PAKE key exchange as defined in the Thread 1.0.0 221 | draft specification. This support is disabled by default as the specification is 222 | not stable yet. See the 223 | [README](https://github.com/ARMmbed/mbedtls/blob/f7a46882574804d1939d48341ecc8b87e3efd651/yotta/data/README.md#configuring-mbed-tls-features) 224 | for instructions to enable it. 225 | Fixes for security issues, including 226 | [CVE-2015-5291](https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2015-01). 227 | Various bug fixes and improvements. 228 | 229 | More details can be found in the [changelog](https://github.com/ARMmbed/mbedtls/blob/development/ChangeLog). 230 | 231 | Currently the only officially supported target platform for mbed TLS in mbed OS is 232 | the Freescale FRDM-K64F board (yotta targets: `frdm-k64f-gcc` and `frdm-k64f-armcc`). 233 | We do not recommend using this release of mbed TLS in production, because the port 234 | for the Freescale FRDM-K64F board does not yet provide an adequate source of random 235 | numbers necessary for the cryptographic functions. 236 | 237 | ### Bluetooth Low Energy 238 | 239 | This release reintroduces the mbed Classic Bluetooth Low Energy (BLE) APIs into mbed 240 | OS. These APIs abstract vendors' BLE implementations, including single-chip and external 241 | peripheral configurations. Currently there is reference support for targets based 242 | on Nordic's nRF51 family of MCUs, as well as experimental support for ST BLE shields 243 | on other target boards. 244 | 245 | The Bluetooth API is hosted on [GitHub](https://github.com/ARMmbed/ble). It comes 246 | with reference implementations for some Bluetooth-SIG specified GATT profiles and 247 | services; documented example applications can be found 248 | [here](https://github.com/ARMmbed/ble-examples). 249 | 250 | ### mbed Client API 251 | 252 | This release contains the following new features: 253 | 254 | * Securely connect to mbed Device Server (mbed DS) over TCP connection through 255 | TLS. The supported secure connection includes Certificate mode. We still support 256 | non-secure connection mode for fast development and debugging. 257 | * New LWM2M Firmware Object class preview for application development. 258 | 259 | ## Known issues 260 | 261 | The known issues for this release are described [here](mbed OS 15.11 Known Issues.md). 262 | 263 | ## Other ways of accessing this release 264 | 265 | We prefer that you access and collaborate with mbed OS here on GitHub and on 266 | [mbed.com](https://www.mbed.com). However, the release may also be downloaded as 267 | an archive 268 | [on mbed.com](https://www.mbed.com/en/development/software/mbed-os/releases/mbed-os1511/). 269 | For further information, please start with the README in the root directory of the 270 | archive. 271 | 272 | ## Module versions in this release 273 | 274 | We use [semantic versioning](http://semver.org) for the modules in mbed OS. This 275 | means that you can tell from the version number of a module what's changed: an 276 | increase in the major version indicates a backwards incompatible change, and the 277 | minor and patch versions are used for backwards compatible features and bug-fixes 278 | respectively. When you use yotta to build an application that depends on a module, 279 | you can specify which sort of updates you will allow updates to. For more 280 | information on how yotta uses version specifications, see the 281 | [yotta documentation](http://yottadocs.mbed.com/reference/module.html#dependencies). 282 | 283 | This release comprises the following yotta modules and their versions: 284 | 285 | | Module | Version | 286 | |------------------------------------|---------| 287 | | `atmel-rf-driver` | 1.0.1 | 288 | | `ble` | 2.0.3 | 289 | | `BLE_URIBeacon` | 0.0.1 | 290 | | `BLE_Thermomether` | 0.0.1 | 291 | | `BLE_HeartRate` | 0.0.1 | 292 | | `BLE_EddystoneObserver` | 0.0.1 | 293 | | `BLE_EddystoneBeacon` | 0.0.1 | 294 | | `BLE_Beacon` | 0.0.1 | 295 | | `ble-nrf51822` | 2.0.2 | 296 | | `cmsis-core` | 1.0.1 | 297 | | `cmsis-core-freescale` | 1.0.0 | 298 | | `cmsis-core-k64f` | 1.0.0 | 299 | | `cmsis-core-nordic` | 1.0.1 | 300 | | `cmsis-core-nrf51822` | 1.0.1 | 301 | | `cmsis-core-st` | 1.0.0 | 302 | | `cmsis-core-stm32f4` | 1.0.2 | 303 | | `cmsis-core-stm32f429xi` | 1.0.2 | 304 | | `compiler-polyfill` | 1.1.1 | 305 | | `core-util` | 1.0.1 | 306 | | `dlmalloc` | 1.0.0 | 307 | | `example-asynch-i2c` | 1.0.1 | 308 | | `example-asynch-serial` | 1.0.0 | 309 | | `example-asynch-spi` | 1.0.1 | 310 | | `example-mbedos-blinky` | 1.0.0 | 311 | | `helloyotta` | 0.0.0 | 312 | | `mbed-6lowpan-eventloop-adaptor` | 1.0.2 | 313 | | `mbed-client` | 1.2.1 | 314 | | `mbed-client-c` | 1.1.1 | 315 | | `mbed-client-example-6lowpan` | 0.0.2 | 316 | | `mbed-client-examples` | 1.1.0 | 317 | | `mbed-client-libservice` | 3.0.8 | 318 | | `mbed-client-mbed-os` | 1.1.0 | 319 | | `mbed-client-mbed-tls` | 1.0.9 | 320 | | `mbed-client-randlib` | 1.0.0 | 321 | | `mbed-drivers` | 0.11.1 | 322 | | `mbed-example-network` | 1.0.1 | 323 | | `mbed-hal` | 1.0.5 | 324 | | `mbed-hal-frdm-k64f` | 1.0.0 | 325 | | `mbed-hal-freescale` | 1.0.0 | 326 | | `mbed-hal-k64f` | 1.0.1 | 327 | | `mbed-hal-ksdk-mcu` | 1.0.3 | 328 | | `mbed-hal-mkit` | 1.0.0 | 329 | | `mbed-hal-nordic` | 1.0.0 | 330 | | `mbed-hal-nrf51822-mcu` | 1.0.5 | 331 | | `mbed-hal-nrf51dk` | 1.0.1 | 332 | | `mbed-hal-st` | 1.0.0 | 333 | | `mbed-hal-st-stm32cubef4` | 1.0.2 | 334 | | `mbed-hal-st-stm32f4` | 1.0.3 | 335 | | `mbed-hal-st-stm32f429zi` | 1.0.3 | 336 | | `mbed-mesh-api` | 1.0.1 | 337 | | `mbed-tls-sockets` | 0.1.0 | 338 | | `mbedtls` | 2.2.0 | 339 | | `minar` | 1.0.1 | 340 | | `minar-platform` | 1.0.0 | 341 | | `minar-platform-mbed` | 1.0.0 | 342 | | `sal` | 1.0.2 | 343 | | `sal-driver-lwip-k64f-eth` | 1.0.2 | 344 | | `sal-iface-6lowpan` | 1.0.7 | 345 | | `sal-iface-eth` | 1.0.1 | 346 | | `sal-stack-lwip` | 1.0.2 | 347 | | `sal-stack-nanostack` | 3.0.5 | 348 | | `sal-stack-nanostack-eventloop` | 1.0.3 | 349 | | `sockets` | 1.0.2 | 350 | | `target-frdm-k64f-armcc` | 1.0.0 | 351 | | `target-frdm-k64f-gcc` | 1.0.1 | 352 | | `target-kinetis-k64-armcc` | 1.0.0 | 353 | | `target-kinetis-k64-gcc` | 1.0.0 | 354 | | `target-mbed-armcc` | 0.1.2 | 355 | | `target-mbed-gcc` | 0.1.3 | 356 | | `target-nordic-nrf51822-16k-armcc` | 0.0.11 | 357 | | `target-nordic-nrf51822-32k-armcc` | 0.0.11 | 358 | | `target-nordic-nrf51822-16k-gcc` | 0.0.11 | 359 | | `target-nordic-nrf51822-32k-gcc` | 0.0.8 | 360 | | `target-nrf51dk-armcc` | 0.0.4 | 361 | | `target-nrf51dk-gcc` | 0.0.4 | 362 | | `target-st-stm32f429i-disco` | 0.0.15 | 363 | | `ualloc` | 1.0.2 | 364 | | `unity` | 1.0.0 | 365 | | `uvisor-helloworld` | 0.7.3 | 366 | | `uvisor-lib` | 1.0.6 | 367 | 368 | 369 | -------------------------------------------------------------------------------- /Release Docs/mbed_OS_Known_Issues_16_03.md: -------------------------------------------------------------------------------- 1 | # mbed OS Known Issues 2 | 3 | ## About this document 4 | 5 | This is the list of known issues for the This is the list of known issues for the [16.03 release of mbed OS and related tools](https://github.com/ARMmbed/mbed-os/blob/master/mbed_OS_Release_note_16_03.md). 6 | 7 | We publish mbed OS as a collection of modules on GitHub. Issues are raised in the specific repositories and then tracked internally. 8 | 9 | The purpose of this document is to provide a single view of the outstanding key issues that have not been addressed for this release. As such it is a filtered and reviewed list based on priority and potential impact. Each item summarises the problem and includes any known workarounds, along with a link to the GitHub issue (if applicable). We welcome any comments or proposed solutions. 10 | 11 | For more information about an issue, contact us on the [forums](http://forums.mbed.com). 12 | 13 | ## Additional information 14 | 15 | For further information regarding this release please refer to the release notes referenced above. 16 | 17 | Other tools such as [yotta](https://github.com/ARMmbed/yotta) and [Greentea](https://github.com/ARMmbed/greentea) also have their own lists, which can be viewed in their public GitHub repositories. 18 | 19 | # Known issues 20 | ## Device disconnects or crashes after 50 hours 21 | * **Description**: After 50 hours online with mbed Client, device stops responding. 22 | * **Workaround**: No workarounds. 23 | * **Reported Issue**: [https://github.com/ARMmbed/sal-stack-nanostack/issues/7](https://github.com/ARMmbed/sal-stack-nanostack/issues/7) 24 | * **Priority**: Critical 25 | 26 | ## mbed-client-example-6lowpan does not recover from network connection errors 27 | * **Description**: If the border router is disconnected the mbed client ends up in an error loop and does not recover 28 | * **Workaround**: None 29 | * **Reported Issue**: ONME-2509 30 | * **Priority**: Critical 31 | 32 | ## K64F border router and 6LoWPAN ND do not work with debug trace enabled 33 | * **Description**: When debug trace is enabled the node either crashes or does not work properly. 34 | * **Workaround**: None 35 | * **Reported Issue**: [https://github.com/ARMmbed/sal-stack-nanostack-private/issues/341](https://github.com/ARMmbed/sal-stack-nanostack-private/issues/341) 36 | * **Priority**: Critical 37 | 38 | ## Low power ticker overflow issue in MINAR 39 | * **Description**: If the low power ticker overflows, MINAR might start executing periodic events faster than desired after it wakes up from sleep. 40 | * **Workaround**: None 41 | * **Reported Issue**: [https://github.com/ARMmbed/minar/issues/32](https://github.com/ARMmbed/minar/issues/32) 42 | * **Priority**: Critical 43 | 44 | ## Only a single sal-stack can be used with the socket API 45 | * **Description**: The mbed OS socket API handles the periodic task provided by the SAL incorrectly. Because of this, only a single stack can be used at a time. 46 | * **Workaround**: Use the SAL to extract the periodic function (`void (*task)() = socket_get_api(STACK_ID)->periodic_task()`) and periodic interval (`uint32_t interval = socket_get_api(STACK_ID)->periodic_interval()`), then schedule a recurring callback in MINAR for each stack (`minar::Scheduler::postCallback(task).period(minar::milliseconds(interval)`) 47 | * **Reported Issue**: [https://github.com/ARMmbed/sockets/issues/36](https://github.com/ARMmbed/sockets/issues/36) 48 | * **Priority**: Major 49 | 50 | ## Distinguish between read and write access faults in uVisor 51 | * **Description**: When creating a read-only region in uVisor, write access will create an access fault as expected, but it needs to avoid configuring the corresponding MPU region again. The intended behavior is to fault with a security exception. 52 | * **Workaround**: Do not write to read-only memory regions. 53 | * **Reported Issue**: [https://github.com/ARMmbed/uvisor/issues/68](https://github.com/ARMmbed/uvisor/issues/68) 54 | * **Priority**: Major 55 | 56 | ## uVisor cannot be enabled on targets built with armcc 57 | * **Description**: Some uVisor APIs rely on complex inline assembly, which is not fully supported by the ARM Compiler 5. Their implementation requires a completely different approach, which we are working on. For this release though, we will not support armcc. 58 | * **Workaround**: All targets that support uVisor and are built with armcc will still compile and work, but the security features of uVisor will not be available. uVisor APIs will still be available, but no security measure will be enabled. 59 | * **Reported Issue**: [https://github.com/ARMmbed/uvisor/issues/89](https://github.com/ARMmbed/uvisor/issues/89) 60 | * **Priority**: Major 61 | 62 | ## Hardware floating point is currently disabled 63 | * **Description**: uVisor has not yet implemented full handling of the FPU register file and exception model. Until the FPU is fully supported in uVisor, mbed OS must be used with hardware floating point disabled. 64 | * **Workaround**: Soft-floating point can be used (providing complete functionality, but with a performance and power impact compared to hard-FP). 65 | * **Reported Issue**: [https://github.com/ARMmbed/uvisor/issues/88](https://github.com/ARMmbed/uvisor/issues/88) 66 | * **Priority**: Major 67 | 68 | ## 6LoWPAN socket adaptation layer does not support DNS 69 | * **Description**: 6LoWPAN socket adaptation layer does not support DNS. 70 | * **Workaround**: IPv6 addresses must be given in ASCII format. 71 | * **Reported Issue**: [https://github.com/ARMmbed/sal-iface-6lowpan/issues/12](https://github.com/ARMmbed/sal-iface-6lowpan/issues/12) 72 | * **Priority**: Minor 73 | 74 | ## 6LoWPAN socket adaptation layer has incomplete C++ API 75 | * **Description**: The following mbed C++ Socket API methods are not implemented in `sal-iface-6lowpan`: 76 | * `socket_accept` 77 | * `socket_start_listen` 78 | * `socket_stop_listen` 79 | * `send_to` (for TCP sockets) 80 | * `recv_from` (for TCP sockets) 81 | * `set_option` 82 | * `get_option` 83 | * `is_bound` 84 | * `get_local_addr` 85 | * `get_remote_addr` 86 | * `get_local_port` 87 | * `get_remote_port` 88 | * **Workaround**: None 89 | * **Reported Issue**: [https://github.com/ARMmbed/sal-iface-6lowpan/issues/11](https://github.com/ARMmbed/sal-iface-6lowpan/issues/11) 90 | * **Priority**: Minor 91 | 92 | ## Mesh network is insecure 93 | * **Description**: Mesh network is insecure: 94 | * `mbed-mesh-api` does not provide an API for changing the security settings. 95 | * gateway binary releases are currently operating in insecure mode. 96 | * **Workaround**: None 97 | * **Reported Issue**: ARM internal reference ONME-2076 98 | * **Priority**: Minor 99 | 100 | ## LwIP does not use random source port and sequence number in TCP connections 101 | * **Description**: LwIP should use random source ports and sequence numbers in TCP connections. Failing to do so means that remote hosts can ignore connection requests by a device running LwIP when a connection is improperly closed and reopened, for example by a reset. Original issue: https://github.com/ARMmbed/sockets/issues/17 102 | * **Workaround**: Manually bind a socket to a random port before connecting to a remote host. Suggested source of randomness is mbed TLS's entropy pool and random number generator. 103 | * **Reported Issue**: [https://github.com/ARMmbed/sockets/issues/17](https://github.com/ARMmbed/sockets/issues/17) 104 | * **Priority**: Minor 105 | 106 | ## Floating point format is not supported in printf() 107 | * **Description**: If floating point data is passed to printf(), a blank space will be displayed. 108 | * **Workaround**: None 109 | * **Reported Issue**: [https://github.com/ARMmbed/target-mbed-gcc/issues/17](https://github.com/ARMmbed/target-mbed-gcc/issues/17) 110 | * **Priority**: Minor 111 | 112 | ## Kinetis K64F target claims RAM to be continuous. 113 | * **Description**: Random Hard Faults may happen if misaligned memory access happens between SRAM_L and SRAM_U boundary. 114 | * **Workaround**: No continuous objects in memory should cross 0x20000000 boundary. 115 | * **Reported Issue**: [https://github.com/ARMmbed/target-kinetis-k64-gcc/issues/4](https://github.com/ARMmbed/target-kinetis-k64-gcc/issues/4) 116 | * **Priority**: Critical 117 | 118 | # Known issues for mbed Client 119 | 120 | The mbed Client known issues list is available as [a separate document](https://docs.mbed.com/docs/release-documents/en/latest/16_03/mbed_Client/Known_Issues/). 121 | -------------------------------------------------------------------------------- /Reporting Bugs.md: -------------------------------------------------------------------------------- 1 | # Reporting Bugs or Issues with mbed OS 2 | 3 | Please report bugs in the individual github repositories. If you're uncertain where the bug needs to be filed, please seek for help in the [mbed forums](http://forums.mbed.com/c/mbed-os). 4 | 5 | Using ```yotta outdated``` you can list the submodules that might have been updated. Especially older code might specifically include outdated versions of submodules that might cause trouble. Using ```yotta update -l``` you can apply the latest updates to your project. Further information on using yotta can be found [here](http://yottadocs.mbed.com/). 6 | 7 | ## Writing good bug reports 8 | 9 | * Please ensure explain the setup your running, where your power comes from in much detail as possible 10 | * Don't hesitate to attach schematics of complicated setups 11 | * Sending photos of your setup explaining where peripherals are attached helps us to reproduce the bugs you submit 12 | * Please attach the output of ```yotta list``` to your bug report for identifying packages and versions 13 | * Also attach the version of yotta itself using ```yotta version``` 14 | * Unless it's empty of course - please attach the output of ```yotta outdated``` to your bug report 15 | * We are particularly interested in your toolchain versions and the specific versions of the development boards used 16 | * A good practice is to build a debug version of the software and attach the console output of the affected module to your bug report. Selected modules support multiple levels of verbosity that might require configuration changes to generate output on the debug console. We are happy to help you identifying the right settings. 17 | * Try to iteratively boild down bugs to the smallest possible setup that reproduces the bug - ideally without depending on specialized hardware. It that's not possible we need to know what other software is running in the background as detailed as possible. 18 | * We will might request a compiled firmware and the sources that allow us to reproduce the bug on one of our development boards. 19 | 20 | 21 | -------------------------------------------------------------------------------- /examples.json: -------------------------------------------------------------------------------- 1 | { 2 | "$comment": "Note that the format of this file will change when we better represent the multiple examples present in some of the repos listed below.", 3 | "example-asynch-spi": { 4 | "url": "https://github.com/ARMmbed/example-asynch-spi", 5 | "workingTargets": [ 6 | "frdm-k64f-gcc", 7 | "frdm-k64f-armcc" 8 | ] 9 | }, 10 | "example-asynch-serial": { 11 | "url": "https://github.com/ARMmbed/example-asynch-serial", 12 | "workingTargets": [ 13 | "frdm-k64f-gcc", 14 | "frdm-k64f-armcc" 15 | ] 16 | }, 17 | "example-asynch-i2c": { 18 | "url": "https://github.com/ARMmbed/example-asynch-i2c", 19 | "workingTargets": [ 20 | "frdm-k64f-gcc", 21 | "frdm-k64f-armcc" 22 | ] 23 | }, 24 | "mbed-example-network": { 25 | "url": "https://github.com/ARMmbed/mbed-example-network", 26 | "workingTargets": [ 27 | "frdm-k64f-gcc", 28 | "frdm-k64f-armcc" 29 | ] 30 | }, 31 | "mbed-client-examples": { 32 | "url": "https://github.com/ARMmbed/mbed-client-examples", 33 | "workingTargets": [ 34 | "frdm-k64f-gcc", 35 | "frdm-k64f-armcc" 36 | ] 37 | }, 38 | "mbed-client-example-6lowpan": { 39 | "url": "https://github.com/ARMmbed/mbed-client-example-6lowpan", 40 | "workingTargets": [ 41 | "frdm-k64f-gcc" 42 | ] 43 | }, 44 | "ble-examples": { 45 | "url": "https://github.com/ARMmbed/ble-examples", 46 | "workingTargets": [ 47 | "nrf51dk-gcc", 48 | "nrf51dk-armcc" 49 | ] 50 | }, 51 | "mbedtls": { 52 | "url": "https://github.com/ARMmbed/mbedtls-examples", 53 | "workingTargets": [ 54 | "frdm-k64f-gcc", 55 | "frdm-k64f-armcc" 56 | ] 57 | }, 58 | "uvisor-helloworld": { 59 | "url": "https://github.com/ARMmbed/uvisor-helloworld", 60 | "workingTargets": [ 61 | "frdm-k64f-gcc" 62 | ] 63 | } 64 | } 65 | 66 | -------------------------------------------------------------------------------- /mbed_OS_Release_note_16_03.md: -------------------------------------------------------------------------------- 1 | 2 | # mbed OS 16.03 Release Note 3 | 4 | ## About this release 5 | 6 | This document marks the availability of the 16.03 release of mbed OS and associated tools. Our focus in this release is on improving the core tools, underlying technologies and confidence through testing of the mbed OS 15.11 Technology Preview release. This release brings together improvements in the following key areas of the mbed technologies and tools: 7 | 8 | * **Thread**: Added interoperability improvements for Thread certification and introduced Thread 1.0 features and experimental Thread 1.1 features. Added Sleepy End Device configuration support to work with mbed 6LoWPAN technologies. 9 | * **6LoWPAN**: Updated Nanostack version 4.0 to introduce new APIs focused on Mesh Link Establishment (MLE) configuration and associated router management. Added guidance on updating modules for mbed 6LoWPAN implementation. 10 | * **Bluetooth Low Energy (BLE)**: Introduced new APIs with experimental whitelisting support, optional higher security settings for connections and overall improvements in General Access Profile (GAP) module and behavior. 11 | * **Infrastructure**: Updated the test environment to offer improved test coverage for the core OS and associated tools, which increases stability and reliability. 12 | * **Security**: Improved the uVisor build system to offer efficient sandboxing for all platforms, reduced the need for target-specific modifications and added new APIs that improve applications using uVisor. 13 | 14 | As an mbed OS developer, you have access to the code and can build and run the example projects. 15 | 16 | This release offers better test coverage and can be used to evaluate the latest capabilities of mbed OS. IoT use-cases are emergent and the current release does not provide full coverage of all production uses. The software is still maturing and we expect changes to a number of things including module names, repository URLs, APIs, header file names and configuration parameters. We'll try to mitigate the impact that these changes have on your code where possible, but please expect backwards-incompatible changes. 17 | 18 | If you’re already using earlier versions of mbed, please note that mbed OS has its own structure, tools, APIs and philosophy. We recommend reading the [mbed OS User Guide](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/). 19 | 20 | If you have any questions or comments, please post on the [mbed forums](http://forums.mbed.com). 21 | 22 | ## Target availability 23 | 24 | Currently the only target device officially supported by the ARM mbed team is the NXP FRDM-K64F board (yotta target: `frdm-k64f-gcc`). 25 | 26 | In addition, there is partial and experimental support for the following target devices: 27 | 28 | * Nordic nRF51-DK and nRF51822-mKIT boards for Bluetooth Low Energy (BLE) (yotta targets: `nrf51dk-gcc` and `mkit-gcc`). 29 | * NXP JN5179 (yotta target: ‘nxpdk5-jn517x-gcc’). 30 | * BBC micro:bit. 31 | * ST Nucleo F401 and DISCO-F4291. 32 | 33 | ## Collaboration 34 | 35 | We're building mbed OS as a collaborative project, bringing together industry and open-source community contributions. If you’d like to work on mbed OS with us, we’d encourage you [to pitch in](https://github.com/ARMmbed/mbed-os/blob/master/CONTRIBUTING.md). 36 | 37 | # mbed OS core 38 | 39 | ## mbed-drivers 40 | 41 | ### Feature readiness 42 | 43 | This release includes version 1.3.0 of the mbed-drivers API. The mbed-drivers API is an evolution of the original mbed SDK and, as such, there are places where its design is not well suited to the event-driven programming model used in the rest of mbed OS. We anticipate significant changes in the mbed-drivers API in future releases, but we are publishing the current API as-is, so that developers can start working with mbed OS today. 44 | 45 | From this point on, we will follow the familiar versioning rules described by [semver](http://semver.org) when publishing updates to ``mbed-drivers``. If we make a breaking change to the API, we will increase the major revision number. We will also aim to provide backwards compatibility by developing different versions of the API in different C++ namespaces. 46 | 47 | ### Changes since last release 48 | 49 | * Added support for gcov output. 50 | * Added default baud rate for stdio, derived from yotta config. 51 | * Removed mbed_mac_address default implementation. 52 | * Changed app_start linkage to C++ and remove app.h. 53 | * Converted stdio serial to lazy initialization in order to save memory allocation when stdio is not used in an application. 54 | * Updated mbed-drivers tests to new version of greentea-client. 55 | * Move test_env.h to greentea-client. 56 | * Added first version 2 driver (I2C). ``example-asynch-i2c`` has been updated to match this driver. 57 | 58 | ## core-util 59 | 60 | ### Changes since last release 61 | 62 | * Tests updated to use greentea-client. 63 | * Comment out assert in the critical section. 64 | * CriticalSectionLock to use the C based solution within the class. 65 | * C critical section for NRF51 targets. 66 | * C critical section for POSIX targets. 67 | * Allocators aligned to 8. 68 | * NRF51 critical section - fixes use with the SoftDevice disabled. 69 | * mbed-drivers - update dependency to 1.0.0. 70 | * C re-entrant critical section. 71 | * sbrk - ensure that both positive and negative `sbrk` calls are aligned to the minimum `sbrk` size. 72 | * Test function pointer - set baud rate removal. 73 | * Add support for uninitialized data sections. 74 | * Array, binaryHeap and pool allocators - forbid copying. 75 | * Newline termination for runtime errors. 76 | * Optimized specializations of atomic ops. 77 | * Add missing template specialization prototypes. 78 | * Shared pointer - API documentation. 79 | * Function pointer - fix arguments (all types of arguments, including references). 80 | * core-util.h renamed to assert.h. 81 | 82 | ##mbed-hal 83 | 84 | ### Feature readiness 85 | 86 | The mbed HAL APIs are subject to change. The current HAL APIs are an evolution of the blocking APIs from mbed Classic, and have a number of limitations. There are no notable changes to the mbed HAL APIs from the [mbed OS 15.11 release](../15_11/mbed_OS/Release_Note.md). As with all other parts of the OS, we will signal incompatible changes to the HAL through the use of semantic versioning. 87 | 88 | ### Changes since last release 89 | 90 | * Clarified doxygen and generic documentation. 91 | * K64F: 92 | * Fixed bug related to SPI transfers. 93 | * Removed console specific code from mbed-hal-ksdk-mcu. 94 | * Use the baud rate defined in yotta config. 95 | * Use CRC to generate an Ethernet MAC address. 96 | 97 | ## minar 98 | 99 | ### Changes since last release 100 | 101 | * Runtime warnings turned on by default in debug builds. 102 | * Clarified use of tolerance and the default value of tolerance. 103 | * Updated tests. 104 | 105 | ## ualloc 106 | 107 | ### Changes since last release 108 | 109 | * Tests updated to use greentea-client. 110 | * Enable memory tracing via yotta config. 111 | * ualloc header file – API documentation addition. 112 | * Handle -1 returns from krbs. 113 | * Readme – extensive information added. 114 | 115 | # Networking 116 | 117 | ## Thread 118 | 119 | ### Changes since last release 120 | 121 | * Interoperability improvements for Thread Certification. 122 | * Implemented Thread 1.0 features. 123 | * Implemented experimental Thread 1.1 features for specification studies. 124 | * Integrated mbed TLS ECJPAKE for Thread use. 125 | * Added Sleepy End Device configuration support to mbed-client-example-6lowpan. 126 | 127 | Since the Thread standard is still unapproved, this API is considered experimental. 128 | 129 | ## 6LoWPAN stack 130 | 131 | ### Changes since last release 132 | 133 | * Major version updated to 4.0. 134 | * New APIs: 135 | * MLE router and host lifetime configuration API. 136 | * MLE neighbor limits configuration API. 137 | * MLE token bucket configuration API. 138 | * API for adding and deleting routers. 139 | * FHSS API. 140 | * API changes: 141 | * Renamed the function `arm_nwk_6lowpan_link_scan_paramameter_set()` to `arm_nwk_6lowpan_link_scan_parameter_set()`. 142 | * Changed channel mask settings API. 143 | * Changed the parameters of function `cca_start()`. 144 | 145 | For instructions on updating your modules, see [https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/api_changes_to_v4_0_0/index.html](https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/api_changes_to_v4_0_0/index.html). 146 | 147 | ## Bluetooth Low Energy (BLE) 148 | 149 | ### Feature readiness 150 | 151 | The whitelist API available in the GAP module is subject to change. All experimental types and functions have their documentation tagged with `@experimental`. 152 | 153 | ### Changes since last release 154 | 155 | * Improved documentation. 156 | * Improved callback management. It is now possible to remove a callback. 157 | * Improved shutdown behavior. The BLE stack powers down fully and consistently with shutdown.The user can register hooks that will get called when the stack is shut down. 158 | * Improved UUID construction. 159 | * Add new APIs: 160 | * Handle characteristic descriptor discovery. 161 | * Allow whitelisting. This feature is still experimental. 162 | * Allow elevating security settings on a particular connection. 163 | * Fix commit of advertisement payload. 164 | * NRF51: 165 | * Use Nordic SDK v10. 166 | * NRF51: Fix handles value of characteristics descriptors. 167 | * Fix update of GAP state. 168 | 169 | ## mbed-mesh-api 170 | 171 | ### Feature readiness 172 | 173 | The [mbed-mesh-api](https://github.com/ARMmbed/mbed-mesh-api), which allows using 6LoWPAN mesh networks, currently uses static configuration. It does not provide an API for selecting the node operating mode, security option, radio channel or other options that are needed for connecting to 6LoWPAN networks. Configuration support will be available in later releases. 174 | 175 | ## sal 176 | 177 | ### Changes since last release 178 | 179 | * Added inet_ntop and inet_pton support. 180 | * Added a socket options API. 181 | 182 | ## sal-stack-nanostack 183 | 184 | ### Feature readiness 185 | 186 | The mbed mesh networking stack includes an implementation of the Thread 1.0 specification. It is experimental, because the Thread specification is still under development. ARM intends to provide full production support for Thread following completion of the Thread standard. 187 | 188 | ## Sockets 189 | 190 | ### Changes since last release 191 | 192 | * Added support for address parsing and formatting to the SocketAddr class. 193 | * Added support for enabling and disabling Nagle’s algorithm. 194 | 195 | # Security 196 | 197 | ## mbed TLS 198 | 199 | ### Feature readiness 200 | 201 | * Support for ECJPAKE is experimental and the Thread specification which requires it is itself not yet final. 202 | * Integration of the random number generation is not yet suitable for use in production. 203 | 204 | ### Changes since last release 205 | 206 | Disabled MD5 handshake signatures in TLS 1.2 by default, to prevent the SLOTH attack on TLS 1.2 server authentication. See [https://www.mitls.org/pages/attacks/SLOTH](https://www.mitls.org/pages/attacks/SLOTH). 207 | 208 | ### uVisor 209 | 210 | Porting uVisor to a whole range of devices has [been greatly simplified since the last release](https://docs.mbed.com/docs/uvisor-and-uvisor-lib-documentation/en/latest/Porting/): no target-specific headers or code-edits are required any more. Debugging is now delegated to unprivileged debug drivers. We also added box identity APIs, so boxes can identify API callers across security boundaries to impose caller-specific API restrictions. 211 | 212 | #### Changes since last release 213 | 214 | * Improved build system: 215 | * Reduced need for hardware-specific implementations. 216 | * Introducing uVisor configurations: A unified point for hardware-specific configuration details that defines a single uVisor release binary. 217 | * New centralized build system. A single make in the top folder builds all configurations for all platforms in release and debug mode. 218 | * See our [porting guide](https://github.com/ARMmbed/uvisor/blob/master/docs/PORTING.md) for updated information. 219 | * New features: 220 | * [New APIs](https://github.com/ARMmbed/uvisor-lib/blob/master/DOCUMENTATION.md#box-identity) to read current box ID and caller box ID. 221 | * New concept of box namespaces to authorize cross-box/cross-device API communication. 222 | * Added context switching features in UVISOR_DISABLED mode. 223 | * Extended SVCall handler table. 224 | * Global vMPU configurations for ARMv7-M: Shared vs. Standalone SRAM. 225 | * MadeMake ACLs optional in secure box configuration. 226 | * Debug boxes (prototype). 227 | * New platforms: 228 | * Now supporting the entire Cortex-M3 and Cortex-M4 based EFM32 family from Silicon Labs. 229 | * Breaking APIs: 230 | * Applications using UVISOR_BOX_CONFIG(...) will not work after this update if they do not include a call to the UVISOR_BOX_NAMESPACE(...) as well. 231 | * All other APIs are backwards compatible. 232 | * This update only affects applications actively using uVisor, not yotta modules depending on it. 233 | 234 | #### Security disclaimer 235 | 236 | This version of the mbed OS uVisor is an early tech preview, which has partial implementation of the security features that will be present in future versions. Please use this release for ensuring compatibility with uVisor (interrupt handling, memory protection model and so on), but do not rely on it for security. 237 | 238 | # Tools 239 | 240 | ## yotta changes since last release 241 | 242 | Many bugfixes and improvements, including: 243 | 244 | * Improved support for generating IDE project files with -G option. 245 | * New yotta shrinkwrap command for recording and subsequently installing specific versions of dependencies. 246 | * Improved support for modules with custom CMake (including the ability to ignore custom CMake), the ability to define custom CMake in targets, and the option to specify the source directory to build automatically (making it easier to support existing libraries with yotta). 247 | * Add useful information to the output of `yotta config` and `yotta outdated` commands. 248 | * Modules and targets can now specify a dependency on the version of yotta they require. 249 | * Many improved and additional warnings and diagnostic messages. 250 | 251 | The full yotta changelog can be found at [https://github.com/ARMmbed/yotta/releases](https://github.com/ARMmbed/yotta/releases). 252 | 253 | This release requires yotta 0.15.2 or greater. 254 | 255 | ## Test tools 256 | 257 | ### Greentea changes since last release 258 | 259 | * Released “mbed-greentea” version 0.2.0 in PyPI (current release support). 260 | * Released “mbed-greentea” version 0.1.x (for backward compatibility with mbed-drivers/test_env.h) 261 | * Introduced a new test environment package: greentea-client. It is the Greentea device under test (DUT) counterpart. 262 | * Added support for the asynchronous host test model. 263 | * Added support for utest v1.10.0 onwards. 264 | * Added test suite and test case support (also with utest v1.10.0 onwards). 265 | * Added code coverage support for gcov/lcov reporting. 266 | * Added support for hooks (used mainly by the gcov/lcov feature). 267 | * Deprecated the use of mbed-drivers/test_env.h. See greentea-client notes below. 268 | * Deprecated the --digest switch. 269 | 270 | ### greentea-client changes since last release 271 | 272 | * DUT C++ Greentea client library. 273 | * Deprecates mbed-drivers/test_env.h. 274 | * Introduces stateless parser/tokenizer for simple key-value protocol between the host and DUT. 275 | * This is the slave side of the Greentea framework. 276 | * Released as “greentea-client” version 1.0.0 in the yotta Registry. 277 | 278 | ### htrun changes since last release 279 | 280 | * Added support of the key-value protocol – asynchronous host test execution model. 281 | * Added support of the key-value protocol callbacks. 282 | * Added event state machine. 283 | * Deprecated --digest switch. 284 | * Released as “mbed-host-tests” version 0.2.0 in PyPI. 285 | 286 | ### mbed-ls changes since last release 287 | 288 | * Added support for DAPlink version 0240. 289 | * Added parsing for DETAIL.TXT. 290 | * Added DAPlink version detection. 291 | * Small improvements to the way we display data on the screen. 292 | * Added more platforms to detection pool. 293 | * Minor bugfixes. 294 | * Released as “mbed-ls” version 0.2.0 in PyPI. 295 | 296 | Please note that mbed-ls does not support OS X El Capitan. 297 | 298 | # mbed Client 299 | 300 | ## Changes since last release 301 | 302 | * New APIs: 303 | * Setting the max-age of a resource value. See [https://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.10.6](https://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.10.6). 304 | * Omitting registered resources' URI path from the registration message's body (which is sent from the client to the server). 305 | * Allowing the client to send a delayed response to POST requests. See [https://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.2.2](https://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.2.2). 306 | * Getting Object and Object Instance information from Resource Object. 307 | * Added a new class for handling arguments received from POST method for Resource. 308 | * Enabled CoAP Blockwise payload handling by client. See [https://tools.ietf.org/html/draft-ietf-core-block-08#section-2](https://tools.ietf.org/html/draft-ietf-core-block-08#section-2). 309 | * Added support for handling observation cancellation through a RESET message from Device Connector Server. 310 | * Disabled Bootstrap API functionality from source code. 311 | 312 | # Known issues 313 | 314 | The known issues list for this release is available as [a separate document](https://github.com/ARMmbed/mbed-os/blob/master/Release%20Docs/mbed_OS_Known_Issues_16_03.md) 315 | 316 | # Other ways of accessing this release 317 | 318 | We prefer that you access and collaborate with mbed OS online. However, the release may also be downloaded [as an archive](https://mbed-media.mbed.com/filer_public/fc/1a/fc1a497b-ece4-4a60-bc91-b0bcf9abe1d5/mbedos-1603.zip). For further information, please start with the readme in the root directory of the archive. 319 | 320 | # Getting started 321 | 322 | To get started with mbed OS, please visit our [Getting Started Guide](http://docs.mbed.org/docs/getting-started-mbed-os/en/latest/), which describes the tools you need to use mbed OS, how to build and run your [first mbed OS program](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/FirstProjectmbedOS/) and where to find [a few more examples](https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/GetTheCode/). 323 | 324 | # Module versions in this release 325 | 326 | We use [semantic versioning](http://semver.org) for the modules in mbed OS. This means that you can tell from the version number of a module what’s changed: an increase in the major version indicates a backwards incompatible change, and the minor and patch versions are used for backwards compatible features and bug-fixes respectively. When you use yotta to build an application that depends on a module, you can specify which sort of updates you will allow updates to. For more information on how yotta uses version specifications, see the [yotta documentation](http://yottadocs.mbed.com/reference/module.html#dependencies). 327 | 328 | This release comprises the following yotta modules and their versions: 329 | 330 | 331 | | Module | Version | 332 | |--------------------------------|----------| 333 | | async-util | 0.0.2 | 334 | | atmel-rf-driver | 2.0.3 | 335 | | ble | 2.5.2 | 336 | | ble-batterylevel | 0.0.1 | 337 | | ble-beacon | 0.0.1 | 338 | | ble-button | 0.0.1 | 339 | | ble-eddystoneobserver | 0.0.1 | 340 | | ble-gapbutton | 0.0.1 | 341 | | ble-heartrate | 0.0.1 | 342 | | ble-led | 0.0.1 | 343 | | ble-ledblinker | 0.0.1 | 344 | | ble-thermometer | 0.0.1 | 345 | | ble-uribeacon | 0.0.1 | 346 | | ble-nrf51822 | 2.5.3 | 347 | | cmsis-core | 1.1.2 | 348 | | cmsis-core-freescale | 1.0.0 | 349 | | cmsis-core-k64f | 1.0.0 | 350 | | cmsis-core-nordic | 1.0.1 | 351 | | cmsis-core-nrf51822 | 1.3.2 | 352 | | coap-service | 2.1.0 | 353 | | compiler-polyfill | 1.2.1 | 354 | | core-util | 1.7.1 | 355 | | dlmalloc | 1.0.0 | 356 | | example-asynch-i2c | 1.1.0 | 357 | | example-asynch-serial | 2.0.0 | 358 | | example-asynch-spi | 3.0.0 | 359 | | example-mbedos-blinky | 1.0.0 | 360 | | example-mbedos-interruptin | 1.0.0 | 361 | | greentea-client | 1.0.0 | 362 | | helloyotta | 0.0.0 | 363 | | k64f-border-router | 1.0.1 | 364 | | mbed-6lowpan-eventloop-adaptor | 1.1.1 | 365 | | mbed-client | 1.6.0 | 366 | | mbed-client-c | 2.2.11 | 367 | | mbed-client-example-6lowpan | 0.0.2 | 368 | | mbed-client-examples | 1.1.0 | 369 | | nanostack-libservice | 3.1.1 | 370 | | mbed-client-linux | 1.1.9 | 371 | | mbed-client-linux-example | 1.1.0 | 372 | | mbed-client-mbed-os | 1.1.6 | 373 | | mbed-client-mbedtls | 1.0.16 | 374 | | nanostack-randlib | 1.0.0 | 375 | | mbed-drivers | 1.4.0 | 376 | | mbed-example-network | 1.0.1 | 377 | | mbed-hal | 1.2.2 | 378 | | mbed-hal-frdm-k64f | 1.0.2 | 379 | | mbed-hal-freescale | 1.0.0 | 380 | | mbed-hal-k64f | 1.2.0 | 381 | | mbed-hal-ksdk-mcu | 1.1.0 | 382 | | mbed-hal-mkit | 1.0.2 | 383 | | mbed-hal-nordic | 2.0.0 | 384 | | mbed-hal-nrf51822-mcu | 2.1.6 | 385 | | mbed-hal-nrf51dk | 2.0.0 | 386 | | mbed-mesh-api | 2.2.0 | 387 | | mbedtls | 2.2.2 | 388 | | mbed-tls-sockets | 0.1.1 | 389 | | mbed-trace | 1.0.1 | 390 | | minar | 1.2.0 | 391 | | minar-platform | 1.0.0 | 392 | | minar-platform-mbed | 1.2.0 | 393 | | nanostack-border-router | 1.0.3 | 394 | | nrf51-sdk | 2.2.1 | 395 | | sal | 1.2.0 | 396 | | sal-driver-lwip-k64f-eth | 1.0.6 | 397 | | sal-iface-6lowpan | 2.0.1 | 398 | | sal-iface-eth | 1.0.2 | 399 | | sal-nanostack-driver-k64f-eth | 1.0.5 | 400 | | sal-stack-lwip | 1.3.1 | 401 | | sal-stack-nanostack | 4.0.3 | 402 | | sal-stack-nanostack-eventloop | 1.0.7 | 403 | | sal-stack-nanostack-slip | 1.0.3 | 404 | | simplelog | 1.0.0 | 405 | | sockets | 1.2.0 | 406 | | target-frdm-k64f-gcc | 2.0.0 | 407 | | target-kinetis-k64-gcc | 2.0.2 | 408 | | target-linux-native | 1.0.0 | 409 | | target-mbed-gcc | 1.2.0 | 410 | | target-mkit-gcc | 1.0.0 | 411 | | target-nordic-nrf51822-gcc | 1.0.0 | 412 | | target-nrf51dk-gcc | 1.0.0 | 413 | | target-x86-linux-native | 1.0.0 | 414 | | ualloc | 1.2.0 | 415 | | unity | 2.1.0 | 416 | | utest | 1.11.0 | 417 | | uvisor-helloworld | 0.8.0 | 418 | | uvisor-lib | 2.2.1 | 419 | 420 | -------------------------------------------------------------------------------- /module.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "mbed-os", 3 | "version": "15.11", 4 | "description": "ARM mbed OS", 5 | "keywords": [], 6 | "author": "Hugo Vincent ", 7 | "repository": { 8 | "url": "https://github.com/ARMmbed/mbed-os.git", 9 | "type": "git" 10 | }, 11 | "homepage": "https://github.com/ARMmbed/mbed-os", 12 | "licenses": [ 13 | { 14 | "url": "https://spdx.org/licenses/Apache-2.0", 15 | "type": "Apache-2.0" 16 | } 17 | ], 18 | "dependencies": {}, 19 | "targetDependencies": {} 20 | } --------------------------------------------------------------------------------