Posted by Anna Bridge

We are pleased to announce the mbed OS 5.4.7 release is now available. This release includes a flash api and iar exporter for nRF52840 plus a number of bug fixes to improve the stability of the code base.

Here is a full list of all changes and fixes in this release.

Ports for Upcoming Targets

Fixes and Changes

• 4284: LWIP random library and TCP sequence number improvements
• 4334: Revert partially "Remove Cortex A support from CMSIS/RTOS"
• 4395: Allow generic core exports to UVision
• 4282: Flash api nRF52840
• 4383: #4354 Fix MOTE_L152RC GPIO Write
• 4382: Update cmain.S license
• 4332: Fix for blockwise observation failure
• 4303: enable iar exporter for nRF52840
• 4324: STM32F3: Remove dependence upon a specific flash vector table location
• 4393: race tests: fix conditional check for MBED_RTOS_SINGLE_THREAD being defined
• 4368: MTS_DRAGONFLY_F411RE/MTS_MDOT_F411RE: add IAR to post_binary_hook toolchains
• 4455: mbed-coap fixes

Using the release

You can fetch the mbed OS 5.4.7 release from the mbed-os GitHub repository, using the tag "mbed-os-5.4.7". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Danielle Irons

Join us at mbed Connect USA 2017: Our annual IoT Developer Summit

Register for only $25 before July 7, 2017!

We’re back in Santa Clara once again this year, as we host our annual IoT developer summit, held on the first day of ARM TechCon. This is an ideal opportunity for developers to attend and gain invaluable knowledge, through insightful keynotes, hands-on technical workshops, sessions and demonstrations. By taking advantage of this chance to meet and learn from the leading mbed experts, you’ll be uniquely positioned on the leading edge in IoT development and find out what is possible when creating and deploying IoT solutions at scale with mbed.

Early bird tickets are only $25 per developer when you purchase your tickets before July 7th. Space is limited, so be sure to secure your spot by registering before they’re gone!

We hope to see you soon! If you didn’t attend last year, have a look back at mbed Connect USA 2016 in this recap blog

Posted by Danielle Irons

We're pleased to introduce mbed OS 5.5, now available for developers!

The mbed OS 5.5 release upgrades to the latest version of CMSIS, paving the way for support of the latest ARM compilers, ARMv8-M Architecture based MCUs and lower power RTOS modes. It also introduces cellular connectivity, embedded storage and hardware security enhancements to further simplify development of connected, managed IoT devices. In addition, this release contains many minor fixes and enhancements and brings target platform support up to 85 targets.

Core

mbed OS 5.5 upgrades to the latest CMSIS version, CMSIS5, including the enhanced CMSIS-RTOS2 kernel. This is a significant step in our roadmap to enable support for the latest generation of compilers (ARM GCC Embedded 6, ARM Compiler 6 and IAR Embedded Workbench 8), support for v8-M architecture cores and introduction of low power tick-less RTOS and deep sleep modes.

The release includes many general enhancements and fixes, and upstreams those that have been maintained within the mbed OS codebase itself. The upgrade should be generally transparent to developers using the mbed OS RTOS APIs, but please report in the forums or contact us at support@mbed.com if you have any issues in this area.

The file system infrastructure now supports SPI NOR Flash devices, a low-cost, external storage solution. Developers commonly use it in IoT devices to store firmware update images, device credentials and configuration information and to cache data for later syncing to the cloud. You can use the SPI NOR Flash storage with all mbed Enabled platforms, and it is the recommended storage medium for devices requiring firmware update capabilities.

The release also includes a standard in-application flash programming API, FlashIAP, and first partner implementations. This component supports the upcoming mbed Cloud Update service capability, available to licensees, that manages device firmware update campaigns across fleets of devices.

Connectivity

mbed OS 5.5 introduces improved support for cellular connectivity modules, including standard integration through a built-in PPP network interface.

A Linux-based Thread Access Point reference that uses the Thread border router is now available.

Our new native mbed OS BLE stack has reached our Early Partner Release milestone. This allows use of BLE transceivers with any mbed Enabled MCU and provides stack consistency across different BLE hardware. Based on this, we will be working with the first mbed Partners to enable support for their BLE transceivers and SoCs using this stack, planning to provide first access to developers in the 5.6 release. Partners interested in supporting BLE transceivers or SoCs with this stack should contact their Partner Enablement Team representatives.

Security

mbed OS cryptography incorporates mbed TLS 2.5 and the completion of internal APIs for enabling hardware entropy and symmetric and asymmetric cryptographic acceleration. Many partners are implementing and landing support for acceleration on their target platforms and are seeing significant performance increases. Partner acceleration will land in patch releases as we work with partners to complete security audits and mainline these contributions.

uVisor updates address several performance and usability issues reported since the last release. Secure boxes on devices with an ARMv7-M MPU now use less memory and provide more user-friendly configuration options.

uVisor now also supports the new ARMv8-M architecture, including the TrustZone for ARMv8-M security extensions. Support for this architecture is still experimental and is currently only accessible through a feature branch in mbed OS.

Targets

Thanks to our partners’ hard work, mbed OS 5.5 now supports 85 target platforms.

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

Fixes and changes

Please see the mbed OS GitHub repository for a full list of changes introduced in this release. You can find a list of known issues here.

Using the release

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

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

Posted by Anna Bridge

We are pleased to announce the mbed OS 5.5.1 release is now available.

This release includes a fix for a critical issue found in mbed-os-5.5.0:

• 4584: Introduction of RTX/CMSIS 5 has broken semaphone signalling.

The issue has been fixed by reverting the behaviour back to how it was in RTX/CMSIS 4.

The release also includes support for CM3DS_MPS2 and DISCO_L475VG_IOT01A targets, an update to the u-blox ODIN-W2 driver binaries and a number of bug fixes to improve the stability of the tools and codebase.

Here is a full list of all changes and fixes in this release...

Ports for Upcoming Targets

• 4414: Enable CM3DS_MPS2 target
• 4242: DISCO_L475VG_IOT01A : Add new target

Known issues

• 4605: Timing tests are unstable on the ARM_BEETLE_SOC

Fixes and Changes

• 4545: Filter support with a white list of post-bin hooks in uvision
• 4544: Export static files from mbed export
• 4542: Issue#4528 K82F: Move the UART clock inititialization to board specif
• 4530: Enable verbose builds when running example build tests
• 4516: Check for correct library naming in Travis CI
• 4510: u-blox rearrange ODIN target
• 4502: STM32: serial: clear Overrun flag if it is set when checking if readable
• 4562: fatfs: Fixed initialization of block device in mount/unmount functions
• 4504: greentea: Add reporting of reserved heap
• 4554: Fix NUCLEO_L476RG linker scripts
• 4563: Increase background stack size to fix overflow
• 4364: Add C API for Greentea client
• 4540: Support app config option for export
• 4541: Fix a bug in print_large_string
• 4579: RTOS: Fix semaphore
• 4444: resolve lwip init twice issue
• 4523: Check Ethernet before including lwipopts_conf.h
• 4337: Platform support for new CellularInterface in UBLOX_C027 and UBLOX_C030_U201.
• 4567: Updated u-blox ODIN-W2 driver binaries to 2.1 rc1

Using the release

You can fetch the mbed OS 5.5.1 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.1". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Joe Alderson

Windows installer for mbed CLI

As some of you are aware, we provide a command line tool called mbed CLI for mbed OS. mbed CLI allows you to carry out actions such as creating, importing, publishing, and building projects. Typically, you might want to use this if you're looking for a lightweight way of working with mbed OS outside of a GUI.

To make life easier for Windows users we've just released an installer, which handles the dependencies necessary for using mbed CLI, such as Python, GCC, Mercurial, Git, and the mbed Serial Driver.

Download the mbed CLI installer for Windows

To report bugs or issues for mbed CLI, or the installer, please raise them in the mbed CLI GitHub repository.

Commands

Once installed, just use "mbed" in cmd. Here are the currently available commands in mbed CLI which follow "mbed":

new        Create new mbed program or library
import     Import program from URL
add        Add library from URL
remove     Remove library
deploy     Find and add missing libraries
publish    Publish program or library
update     Update to branch, tag, revision or latest
sync       Synchronize library references
ls         View dependency tree
status     Show version control status

compile    Compile code using the mbed build tools
test       Find, build and run tests
export     Generate an IDE project
detect     Detect connected mbed targets/boards

config     Tool configuration
target     Set or get default target
toolchain  Set or get default toolchain

More information

You can find more information on mbed CLI and the CLI installer in our documentation.

Posted by Anna Bridge

We are pleased to announce the mbed OS 5.5.2 release is now available. This release includes new target support for DISCO_F413ZH and VBLUno51 and an update for the STM32F7 cube from v1.6.0 to v1.7.0. It also includes SHA256 and SHA1 hw acceleration support for NUCLEO_F439ZI, USB Device for DISCO_L072CZ_LRWAN1, plus a number of fixes to mbed OS and tools to improve stability and functionality.

Here is a full list of all changes and fixes in this release...

Ports for Upcoming Targets

• 4410: DISCO_F413ZH: Add new platform
• 4629: Add support for VBLUno51 board

Known Issues

Due to a dependency of stm32f413 on a later patch version of IAR which is currently not available in our CI systems, IAR export support for this platform is not available for this release.

• 4697: IAR: remove stm32f413 from definitions

Fixes and Changes

• 4578: Turn off "browse information" in Uvision template
• 4616: Fix unresolved include of mbed_config.h in Eclipse
• 4375: Stm32 spi : use LL API to improve performances
• 4401: STM32 : Add USB used pins in PinNames.h files
• 4520: Update link in CONTRIBUTING.md
• 4103: Add extra_targets.json support to build tools
• 4390: Nucleo-F070RB It doesn't work when use internal clock
• 4405: DISCO_L072CZ_LRWAN1: PC_13 definition missing in PinNames.h fix
• 4426: Improve directory scanning performance
• 4538: Avoid lock collision b/w SerialBase & UARTSerial
• 4552: NUCLEO_F767ZI: Add missing IAR definitions
• 4557: Enable I2C and Analogin drivers for CM3DS_MPS2 target
• 4572: DISCO_L072CZ_LRWAN1: Add support of USB Device
• 4157: NUCLEO_F439ZI/mbedtls: add SHA1 hw_acceleration
• 4422: STM32F4 set HSE timeout value to 100ms
• 4594: Introduce mbed::NonCopyable traits
• 4598: Fix style issues in IAR exporter
• 4604: cmain IAR: add mbed main
• 4607: bd: Fix missing init in MBRBlockDevice
• 4603: STM32 : mbed_overrides.c is common for all families
• 4638: DISCO_L475VG_IOT01A: Fix startup files for cmsis5
• 4610: STM32 : targets.json file simplification
• 4647: Remove hardcode UART pins definitions for nRF52832 SoC
• 4646: RTX: Fixed RTXv5 mutex owner list handling.
• 4625: Update STM32F7 cube from v1.6.0 to v1.7.0
• 4421: STM32 : Clock source selection in json config file
• 4559: fatfs: Remove unused fat_filesystem_set_errno function
• 4571: events: Adopt osEventFlags from RTX 5
• 4577: XDOT_L151CC: enable HSI after waking from stop mode so ADC functions
• 4601: rtos: Fix MemoryPool and Queue destructor
• 4632: STM32: fix us ticker set event timestamp double ISR possibility
• 4641: Increase L0 ADC sample time
• 4656: Correct comments in flash api for STM32 L0 targets
• 4671: retarget: fix microlib for mbed 2
• 4529: Manage multiple instances of analog out
• 4565: Add FlashIAP support for REALTEK_RTL8195AM
• 4159: NUCLEO_F439ZI/mbedtls: add SHA256 hw_acceleration

Using the release

You can fetch the mbed OS 5.5.2 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.2". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Martin Kojtal

We are pleased to announce the mbed OS 5.5.3 release is now available. This release includes only bugfixes.

Here is a full list of all changes and fixes in this release...

Fixes and Changes

• 4446: Customer port verification tests for cellular

• 4531: Update branching option to branch from another branch.

• 4672: Cellular: not-supported error if MODEM_ON_BOARD not defined

• 4468: Put quotes around include files

• 4685: Rename runnig_thread to running_thread in rtx_mutex

• 4163: STM32L486RG/mbedtls: add aes hw acceleration

• 4659: Add the correct startup s file in TARGET_STM32F767

• 4215: Add script to lint targets.json

• 4711: added the missing verbose=verbose to printout the command line correctly at build_api.py

• 4710: Correct a typo in the github issue template

• 4636: Double escape defines in gnuarmeclipse export

• 4635: _acquire() function added & removed duplication in format/freq calls

• 4548: Resolve Warnings for mbed-os-examples

• 4547: Sort the config parameters before printing them

• 4546: Fix bad test print and move locks for printf into macro.

• 4599: Update timing tests to be robust

• 4720: FlashIAP: Add explicit read function to flash_api.h

• 4525: Improve the startup code on the STM32F070

• 4561: fatfs: Add full support for multiple fs volume prefixes

• 4674: Fix LED4 for UBLOX_EVK_NINA_B1

• 4749: tools: fix toolchain extend inc paths

• 4747: Remove unused header files includes for REALTEK_RTL8195AM

• 4736: NRF52832: Extend idle thread stack size to 512 bytes.

• 4707: STM32: serial: use proper macro to check interrupt

• 4699: STM32L0 : internal ADC channels

• 4694: DISCO_L475VG_IOT01A: typo corrections in PeripheralPins.c

• 4693: Nordic: Fix multiple defined symbol.

• 4691: STM32: F4: Increase ADC sampling time for VBAT

• 4677: Increase default PPP stack size from 512 bytes to 768 bytes.

• 4668: DISCO/NUCLEO_F429ZI: Enable all alternate functions and pins

• 4667: Update and mute debug messages of REALTEK_TRL8195AM

• 4666: Fix timing issues found in "Flash - clock and cache test"

• 4652: fatfs: Fix unaligned access in disk_ioctl

• 4592: [ONME-3089] - Adjust lowpan ND interface connect timeout

• 4634: Fix the issue #4357: NRF52 doesn't support simultaneous use of I2C and SPI.

• 4725: Parse and use custom targets in exporters

Using the release

You can fetch the mbed OS 5.5.3 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.3". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Guest Blog

This is the first blog in the "Power of Where" series, authored by Brian Salisbury, VP of Product Management at Comtech Telecommunications Corp.

Every day, an incredible amount of data is being created and captured by sensors. The number of these sensors that are connected to the Internet is also growing rapidly every day. One of the great promises of the Internet of Things (IoT) is that this data will be captured automatically by a broad range of smart “Things” that will be distributed everywhere. Machine learning and artificial intelligence platforms will then consume this data and take actions on our behalf, as well as create amazing insights to help us make the world a better place. But many of those actions and insights won’t be that useful without the context of location. This is what we mean by the “Power of Where.”

This posting is the first in a series on this topic, in which we will discuss why location is such an important contextual element, how location is typically determined, and why many traditional approaches don’t work that well in IoT use cases. We will also share our thoughts on a different approach for location, and how it can conserve energy, minimize device memory requirements, reduce communication bandwidth, and support a broad range of networks. We welcome your feedback and questions, and invite you to share your insights and experiences on the subject.

Let me illustrate the idea of data records needing to be location “tagged” with some basic examples. If an air temperature sensor reports a reading of 23 degrees, it is obviously important to know whether the reading is in degrees Celsius or Fahrenheit and what time the measurement was taken. That’s interesting, but it’s not very useful without additional context. Where was the air temperature sensor?

• Was it outdoors? 23 Celsius is a very comfortable temperature, while 23 Fahrenheit means roads could be icy.
• Was it indoors? Again the difference between below freezing and normal room temperature is meaningful, and leads to different actions being needed.
• Was it inside a refrigerated produce storage area? In one case, the temperature is too low and produce may become frost damaged, in the other case the produce will spoil for a different reason.
• Was it in a refrigerated storage on a truck rolling down the freeway? Determining the best place to intercept the truck will require frequent location updates, not just an initial position.

Clearly context is critical to understanding, and context that includes “Where” is more powerful context.

When important assets are left unattended, there is risk that they will be lost, misplaced or stolen. Having the ability to request the current location of the asset is one way to keep track of it, but when there are hundreds, thousands, or many more such assets being managed, a more automated approach is required.

This is where concepts like geo-fencing come into play. If you can define an area where the asset is supposed to be and only receive alerts when the asset moves outside that area, you will significantly reduce the volume of requests.

Furthermore, once the device’s position is initially established, if the positioning solution is only activated when motion of the device is detected, you will significantly reduce the amount of time that energy is being consumed to determine its location. Less energy means the power source can be smaller and the cost can be lower.

In our next post, we will cover the primary methods that can be used to determine location and their pros and cons in IoT use cases.

Brian Salisbury is VP Product Management at Comtech Telecommunications Corp, which is an mbed Partner. Comtech Telecommunications Corp. designs, develops, produces and markets innovative products, systems and services for advanced communications solutions. Comtech sells products to a diverse customer base in the global commercial and government communications markets. Comtech believes it is a leader in most of the market segments that it serves.

Posted by Jan Jongboom

This is the third article in the 'built with mbed'-series. In the previous articles, we monitored snow and brewed beer.

Shipping bananas from Africa to Europe, sending flowers over the Pacific Ocean, importing electronics from Asia. Every year, there are almost 700 million container movements (data.worldbank.org/indicator/IS.SHP.GOOD.TU) around the world. The sheer volume of global shipments can pose some interesting challenges. How do you ensure that the temperature of your fruit has been consistent during the entire trip? How do you know that the container was not opened after loading, for example to smuggle drugs? And how do you communicate the data back to HQ in time to act on it? The Dutch company Itude Mobile has tackled all of these questions with Babbler, a small and tamper-proof seal that monitors how your cargo is treated. A fascinating product by itself, it’s even more interesting when you realize that it's the first hardware product the company has ever developed. Reason enough for Jan Jongboom (Developer Evangelist) and Danielle Irons (Content Specialist) to talk with Robin Puthli, CEO of Itude.

Babbler seal attached to a shipping container. Still from vimeo.com/182254746.

Congratulations on launching! Where did the idea for Babbler come from?

At Itude Mobile, we have been developing software for supply chain monitoring for the past six years, and during that time, we identified a real issue when attempting to verify that your container has not been compromised. Traditionally, this is done by adding a security seal, a piece of plastic or metal attached on the outside of the container, which needs to be broken in order to open the container. However, these seals are prone to evasion, for example by attacking the hinges of the door; plus they can often be easily defeated, as is shown in this DEFCON talk.

We figured if we create an electronic seal that is placed inside the container, we can use sensors to detect whether the container was opened or tampered with. In addition, you can use the seal for cold chain monitoring, verifying that your produce has been at a consistent temperature. That is important when shipping perishable goods, such as fruits or vegetables.

Sounds interesting. What kind of hardware is in the seal?

The device contains a light sensor, magnetic field sensor, accelerometer and a temperature sensor, which are connected to an nRF51422 MCU (Cortex-M0) from Nordic Semiconductors that has a Bluetooth Low Energy radio. Because the device is not connected most of the time, we encrypt and store all sensor data locally, and an operator can read the data back using a mobile phone when the shipment arrives.

In addition, there is an option to add a long-range radio to the seal, through an NB-IoT or LoRa radio module. The nice thing about that option is that it allows you to read the data from a distance, but of course it adds extra cost to the module. Another aspect that we're experimenting with involves putting LoRa gateways on ships, with a satellite backhaul, so the seals can synchronize their data when they are loaded onto the ship, without manual intervention.

What was the hardest part of designing the product?

Definitely power management. It's already hard to design your software to be power efficient when you're dealing with two separate radios and multiple sensors, but we also found that individual sensors do not conform to their specifications when running in low power mode. Very frustrating, as it directly affects your hardware design. Also, do you want a replaceable or a rechargeable battery? That’s a decision that you need to make before you even start designing the product because it directly influences the design.

Your software is built on mbed. When did you first find out about us?

We saw mbed OS for the first time during Mobile World Congress two years back, and our software engineers thought it was a great fit. It's a lot nicer to develop against than programming bare-metal, the event system works well for our usecase, and the project is well maintained. Of course, it was also great that the nRF51422 was already supported, so that saved a lot of work. Right now, we're still on mbed OS 3, but we'll probably move to mbed OS 5 at some point in the future.

Sounds terrific! Any crazy stories from actual deployments?

We were monitoring a shipment of flowers from an Eastern African country, and at some point - while the shipment was driven from the plantation to the harbor - we saw the temperature of the shipment rising. Nothing dangerous, but there was a sudden temperature rise while the container doors remained closed. Normally, you might want to blame this on a faulty refrigerator unit or the driver opening the doors to check on the cargo, but given that we were verifying our product, we decided to dig deeper. In the end, we found out that the driver was stealing fuel from the truck, requiring him to turn off the motor, which stopped the refrigeration units and caused the temperature fluctuations. Without our seals, that would have never been found out.

Great story! Good luck with the product.

If you want to know more about Babbler, or order some units, visit babbler.io.

-

This was the third article of 'Built with mbed'. In this series, we look at innovative IoT projects that use ARM mbed. Want to get featured as well? Contact us!

-

Jan Jongboom is Developer Evangelist IoT and Danielle Irons is Content Specialist for mbed.

Posted by Martin Kojtal

We are pleased to announce the mbed OS 5.5.4 release is now available. This release includes 3 new targets: LPCXpresso54114, LPCXpresso54608 and VBLUno52.

Here is a full list of all changes and fixes in this release...

Ports for Upcoming Targets

• 4290: Add mbed support for LPCXpresso54114 & LPCXpresso54608 boards

• 4765: Add support for the VBLUno52 board

Fixes and Changes

• 4620: Extend tests for RTOS Thread class

• 4640: STM32L1 Flash API and xDot bootloader support

• 4664: STM32: Fix the CAN initializing to the wrong frequency

• 4676: Correctly enable / disable InterruptIn Edges detection

• 4682: Test: RTOS: Semaphore: Rework tests

• 4687: STM: cleanup mbed_rtx.h file

• 4708: Enable greentea testing on CM3DS_MPS2 target

• 4733: Prevent double define in very old builds

• 4718: Toolchain: Add a note about weak functions and header files

• 4732: Correct DAC pin assignment

• 4727: Update UART3 pins for UBLOX_C030 platform.

• 4745: WIZnet W7500*: Remove support for RTC

• 4751: Remove redundant ODIN-W2 target folder

• 4662: BLE/HRM : Fix #4661

• 4740: STM32 : Clock source selection in json config file (PR2)

• 4696: Max32630 UART: Fix IRQ dispatching and CTS/RTS line configuration

• 4615: Add set_baud() method to UARTSerial().

• 4706: Fix inconsistent mbed-trace dummy defines and original function declarations

• 4721: REALTEK_RTL8195AM: FlashIAP read and address scope

• 4717: STM32: Remove i2c_read() and i2c_write() redirects to HAL_I2C_IsDeviceReady()

• 4726: Update ATCmdParser example code

• 4731: Boot: Make ARMC library mutexes dynamic

• 4734: Avoid data loss with serial interrupt used at high baudrates

• 4754: Resolve TLS handshake failing issue for REALTEK_RTL8195AM

• 4756: Fix #4613: remove duplicated startup files for MICRONFCBOARD

• 4762: DISCO_L475VG_IOT : pin update

• 4764: STM32F0 : remove unavailable pins

• 4774: Add support for runtime test specification

• 4775: Fix non-portable defines

• 4778: Add AES HW encryption for NUCLEO_F756ZG in mbedtls

• 4782: mbed-hal: Fixed flash test

• 4793: STM32 I2C : correct async issue

• 4794: NUCLEO_F767ZI : boot issue with GCC

• 4714: Expose SystemCoreClock via cmsis.h to support new CMSIS/RTX

• 4744: Allow user to set default transfer byte for block read

• 4807: LPC MCUXpresso: fix write_fill argument for block write function

• 4742: Deprecate unsupported exporters

• 4729: RTOS: Mutex: Rework tests

• 4715: Nanostack+mbed-client libservice update

• 4738: ONME-3113: Fix GCC_ARM and ARM compiler warnings from mbed-mesh-api

• 4755: Bluepill: hse config fix

• 4790: Improve documentation for memory stat ops

• 4800: Fix infinite calling loop

• 4804: Copy static files only

Using the release

You can fetch the mbed OS 5.5.4 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.4". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Jan Jongboom

Last month, Arm sponsored Data Science Africa 2017, a machine learning and data science conference held annually in East Africa. This year, the Nelson Mandela African Institute of Science and Technology in Arusha, Tanzania hosted the 300 attendees for five days of workshops, talks and interesting conversations. Arm hosted a two-day IoT workshop and a keynote, but the fun starts when you apply your acquired knowledge to a real-life scenario. Thus, on the Saturday after the conference, Jan Jongboom (Developer Evangelist), Damon Civin (Lead Data Scientist) and 15 conference attendees, headed to the outskirts of Arusha for some good, old-fashioned field work.

The problem

The first visit of the day was to a dairy farm, where Dr. Ciira Maina presented the premise that behavioral analysis of cows can predict whether a cow is in heat, or when a cow is becoming sick. This is valuable information because insemination timing is important, semen samples are expensive, and preventing sickness is better than curing. However, analyzing a cow's behavior requires data…

Armed with a plastic case, an Arm Mbed Enabled NUCLEO F411RE development board, a 9-axis accelerometer, an ESP8266 Wi-Fi chip and a 9V battery - Arm provided a hundred of these kits during the IoT workshop earlier that week - the group quickly assembled a circuit held together by jumper wires, electrical tape and hope.

Sensor assembly in progress. Placing the accelerometer in a consistent way is important when building multiple sensors.

Storing data

After the assembly, the team faced another challenge: where to store the data? Typically, one sends the data for small IoT sensor nodes to the cloud using LwM2M over CoAP or MQTT, but these protocols are made for streaming small amounts of data periodically (such as sending a temperature value every minute). When dealing with an accelerometer, you want data to be sampled many times per second and to stream this data as fast as possible. In addition, internet connectivity is not a given in Tanzania. So the engineers did not want to rely on a stable internet connection.

Cow with the sensor attached

One way would be to cache the data locally in flash or on an SD card, but the downside is that you need to physically retrieve the device afterward to read the data, which is not practical in a real life scenario. Thus, the team decided to do it differently. By setting up a local UDP server on a laptop on the same network as the cow, the sensor can broadcast its data locally, and the laptop can cache the data. Because UDP has almost zero overhead, you don't waste any CPU cycles on network connectivity. This way, you can grab data 30 times per second, send it to the computer and upload it to the cloud (in this case, an InfluxDB time series database) when there is internet.

Gathering data and sending it over UDP (TCP would work, as well) with mbed OS 5 is easy:

// Structure to store the accelerometer readings
typedef struct {
    char mac[17]; // MAC address to identify from which sensor the packets came
    int16_t x[330];
    int16_t y[330];
    int16_t z[330];
} AccelerometerData_t;

// accelerometer readings are done on a separate RTOS thread
void accelerometer_thread_main() {
    while (1) {
        printf("Start reading data\r\n");

        AccelerometerData_t accel_data;
        memcpy(accel_data.mac, mac_address.c_str(), 17);

        int readings[3] = { 0, 0, 0 };

        int seconds = 10;                     // seconds
        int timeout = 33;                     // ms. timeout between measuring
        int intervals = seconds * timeout;    // number of intervals (needs to match the AccelerometerData_t type)

        for (size_t ix = 0; ix < intervals; ix++) {
            accelerometer.getOutput(readings);

            accel_data.x[ix] = readings[0];
            accel_data.y[ix] = readings[1];
            accel_data.z[ix] = readings[2];

            wait_ms(timeout);
        }

        printf("X: ");
        for (size_t ix = 0; ix < intervals; ix++) {
            printf("%d ", accel_data.x[ix]);
        }
        printf("\n");

        printf("Done reading data\r\n");

        printf("Sending data\r\n");
        socket.sendto("192.168.8.101", 1884, &accel_data, sizeof(AccelerometerData_t));
        printf("Done sending data\r\n");
    }
}

To retrieve the data, the group wrote a simple Node.js script that sets up a UDP server and listens for incoming packets. To decode the data structure, the team used the struct package, which makes it easy to pack and unpack C-style data structures from JavaScript.

const udpServer = dgram.createSocket('udp4');
const Struct = require('struct');

udpServer.on('listening', () => {
  var address = udpServer.address();
  console.log('UDP Server is up and running at port', address.port);
});

let messages = {};

udpServer.on('message', (message, remote) => {
  let key = remote.address + ':' + remote.port;

  // messages come in two with the ESP8266 chip that was used... wait for the second one
  if (!(key in messages)) {
    setTimeout(() => {
      let totalLength = messages[key].reduce((curr, m) => curr + m.length, 0);
      if (totalLength === 1470 + 528) {
        // now my message is complete
        let pos = 0;
        let buffer = Buffer.concat(messages[key]);

        let entry = Struct()
          .chars('mac', 17)
          .array('x', 330, 'word16Sbe')
          .array('y', 330, 'word16Sbe')
          .array('z', 330, 'word16Sbe');

        entry._setBuff(buffer);

        entry.fields.x.length = entry.fields.y.length = entry.fields.z.length = 330;

        console.log('Got accelerometer data for', entry.fields.mac);

        // now send the data to a cloud of your choice… read the data via `Array.from(entry.fields.x)`
      }
      else {
        console.log('msg was incomplete after 200 ms...', totalLength);
      }
      delete messages[key];
    }, 200);
  }

  messages[key] = messages[key] || [];
  messages[key].push(message);

  console.log('UDP Receive', remote.address, remote.port, message.length);
});

udpServer.bind(1884, '0.0.0.0');

Analyzing data

With everything in place, the engineers attached the sensor to the cow, and let it run wild. At the same time, they manually tagged what the cow was doing at which point in time, so they could tag the data later and use the tagged data for a machine learning algorithm.

With the data in the cloud, they could cross-reference it with the manual activity tagging and see if they could draw any conclusions from it. The first trait they looked at was standing still or running, as it should show up quite clearly even when analyzing the data manually. Damon Civin quickly started a Jupyter Notebook and visualized the data live in the field. At the same time, students digitized the tagged data, so they would have a coherent set of tagged training data that could be used in a machine learning model.

Analyzing data live in the field

Conclusion

Going into the field to gather data is exciting because it goes beyond the theory behind the Internet of Things. Grabbing data from a sensor becomes a lot more exciting when the sensor is attached to a cow. The team also saw some interesting issues with our current approach, such as the cow running out of range of the Wi-Fi hotspot. The sight of 10 people running after a cow with a laptop and a hotspot must have been hilarious.

It's going to be interesting to see what people will do with the dataset. So far, the group has gathered around an hour of data, but local initiatives have started in Kenya to replicate the research on a wider scale. It would be great if farmer’s lives became easier thanks to the technology created during this conference. If you want to play with the data yourself, you can grab it here. The software the students used during the fieldwork is here (server) and here (firmware).

This was only one of the activities that Arm did in Arusha. We also visited a chicken farm, where we tried to analyze why chicks crowd at the same place in a hen house, ran a workshop during the summer school with 60 participants and worked with local academics and entrepreneurs to solve their data science needs. You can read more about that in a follow-up blog post by Damon.

-

Jan Jongboom is Developer Evangelist IoT at ARM. Damon Civin is Lead Data Scientist for ARM. Both have not grown up at farms.

Posted by Anna Bridge

We are pleased to announce the mbed OS 5.5.5 release is now available.

This release includes mbedTLS SHA1 and SHA256 hw acceleration for NUCLEO_F756ZG, crypto HW acceleration for UBLOX_EVK_ODIN_W2, an update of mbed-coap to version 4.0.8, bootloader support for the UBLOX_C030 and NUCLEO_F412ZG platforms, plus numerous bug fixes and enhancements to improve the stability and functionality of the code.

Here is a full list of all changes and fixes in this release...

Known Issues

None

Ports for Upcoming Targets

None

Fixes and Changes

• 4623: Improve management handling of multiple instances of analogin ojects

• 4398: MAX326xx: BLE updates, fixed sleep, open-drain LEDs

• 4158: NUCLEO_F756ZG / mbedTLS_SHA1 hw acceleration

• 4750: Enable crypto HW acceleration for UBLOX_EVK_ODIN_W2

• 4162: NUCLEO_F756ZG/mbedtls: Add hw acceleration for SHA256

• 4690: test: add us ticker test

• 4752: RTOS: Queue tests & docs rework

• 4835: Add bootloader support for the UBLOX_C030 platforms.

• 4854: NUCLEO_F412ZG add flash driver and bootloader support

• 4868: STM32F437: remove flash api implementation

• 4805: K64F: Update the DSPI SDK driver to support the new API to change DUM

• 4695: F756/F439: add mbedtls md5 hash feature

• 4833: Updating mbed-coap to version 4.0.8

• 4822: fix unresolved linker msg: wrap_

• 4828: Enhancement - exporter/cdt

• 4836: mbed exporter: Add IAR support for various NXP platforms

• 4851: STM32F4_HAL_MMC erase command check is wrong. == has higher precedence than &

• 4852: SAM_CortexM0P uses uninitialized memory in i2c and uses out of bounds array in pwmout

• 4857: DISCO_L475VG_IOT01A: Add support of USBHost

• 4859: Add copyright header to all tests

• 4813: Dual Flash and Hex file support on NCS36510

Using the release

You can fetch the mbed OS 5.5.5 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.5". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Jan Jongboom

The Dutch have a saying: "where people work, mistakes are made." This is a problem if the mistake involves thousands of IoT devices that have a critical bug or a gaping security hole, especially if these devices are on a remote island or baked into concrete. Therefore, every Internet of Things deployment needs to remotely upgrade firmware securely and safely. To help developers build these firmware update capabilities into their devices, we have added new APIs and tools to Arm Mbed OS 5.5.

The example in this blog requires a FRDM-K64F, NUCLEO-F429ZI or EVK-ODIN-W2 development board, plus a micro-SD card. However, the same principles apply to any other Mbed OS 5 board and any other flash chip.

New APIs

In Mmbed OS 5.5, we have added support for these new features:

1. Bootloader support - The ability to build bootloaders, the ability to jump to other applications and integration of bootloaders in the Mbed build process.
2. FlashIAP - A new standard API - part of the HAL - to do In Application Programming on a variety of boards.
3. Storage drivers - New APIs for SD cards and block storage devices. Plus a FATFileSystem library, which you can mount to any storage driver.

Let's use these new APIs to build a simple firmware update demonstration. All these APIs are currently supported on the FRDM-K64F, NUCLEO-F429ZI, EVK-ODIN-W2 and MultiTech xDot. Support for more platforms is welcome. An example of adding support for a new board is here.

How a firmware update works

A microcontroller stores its application in its flash memory. When you program a microcontroller - through drag-and-drop programming for example - the programmer (for example DAPLink or a JTAG) stops the MCU, erases the flash, stores the new program and restarts the MCU. The new program loads. You need to stop the MCU because if you rewrite instructions while the application is running, the MCU crashes almost instantly.

However, if you guarantee that you're only programming flash that the running application does not touch, then you don't need to stop the MCU. This technique is called In Application Programming (IAP). The way to do this is to create two applications, each in their own region in flash. The first application starts up, checks if there is new firmware and then overwrites the flash of the second application. Afterward, jump to the address of the second application, and the new firmware runs.

This first application is called a bootloader. Bootloaders are typically small, do not use any networking and are only used to verify if new firmware has to be applied and then flash the new application. To facilitate firmware updates this way, the bootloader and our application need some shared storage space such as an external flash chip or an SD card. The example application in this blog post checks if new firmware is ready, downloads it and puts it in the external flash. On reboot, the bootloader checks the external flash, upgrades the application and hands control back.

Building the bootloader

Part of the Mbed OS 5.5 release is an example bootloader, which uses an SD card as its external firmware storage. On startup, the bootloader verifies that an update file is on the SD card, loads the file and then uses FlashIAP to program the new application. The application is at mbed-os-example-bootloader and can be built in the Mbed Online Compiler or with Mbed CLI:

$ mbed import https://github.com/armmbed/mbed-os-example-bootloader
$ cd mbed-os-example-bootloader
$ mbed compile -m UBLOX_EVK_ODIN_W2 -t GCC_ARM

As you can see in the source code, the bootloader is a normal Mbed OS 5 application. The magic is in mbed_app.json, where we set the target.restrict_size option. When this option is set, the size of the bootloader image inflates to always match this size. This is necessary because you need to know exactly at which address the real application starts. If you inflate the bootloader size to a standard size (0x40000 in this case), you can concat the two images together in the build process.

Another addition is the mbed_start_application function and the POST_APPLICATION_ADDR macro (used here). The macro indicates the location of the second application in flash, and the mbed_start_application function jumps to this address. In addition, it clears any interrupts that the bootloader application set.

Note: Pins are not reset when the bootloader hands over to the application.

As you're using the FATFileSystem, make sure to format the SD card as FAT. Also note that you can use any other external flash chip, as long as you implement the BlockDevice class. (Here's an example for the popular AT45 chip.)

Bootloader alignment

Some rules apply when setting the target.restrict_size option. First, any Arm application must start at a vector table size aligned address. Vector address alignment depends on the number of external interrupts on the target chip, but the maximum on ARMv7-M is 256 words (1024 bytes); thus, setting target.restrict_size to a multiple of 1024 is a safe choice for any Mbed Enabled MCU.

Second, the FlashIAP API can only reprogram complete pages, thus the application should also be page size and sector size aligned. These sizes differ from board to board, and you can obtain them by calling the get_sector_size and get_page_size functions of the FlashIAP API:

FlashIAP iap;
iap.init();
// note: the address passed into `get_sector_size` should be close to where the application will be to get accurate numbers
printf("page size is %lu, sector size is %lu\n", iap.get_page_size(), iap.get_sector_size(0x8000000));

For the ODIN-W2 board, this results in a page size of 0x400 and a sector size of 0x4000. The target.restrict_size setting of 0x40000 aligns with both.

Building the application

An application that uses a bootloader is almost exactly the same as an application without the bootloader. The only thing you need to add is a section in mbed_app.json, which points to the bootloader file:

{
    "target_overrides": {
        "UBLOX_EVK_ODIN_W2": {
            "target.bootloader_img": "bootloader/UBLOX_EVK_ODIN_W2.bin"
        }
    }
}

When this option is present, the application automatically aligns, and the build process combines the bootloader with the application. In addition, you see an extra binary in the BUILD folder, called projectname_application.bin. This binary contains only the application - but offset at the address right after the bootloader. This is the application you flash through FlashIAP. For initial drag-and-drop programming, still use projectname.bin.

For this blog post, we have written a small application that uses mbed-http to download a file from the network and then store it on the SD card. When the download is complete, the system restarts, and the bootloader can update the firmware.

To build this application:

• Import mbed-os-example-fota-http through Mbed CLI.
• Set your connectivity method (and, optionally, your Wi-Fi credentials) in mbed_app.json.
• Set the address of a server (for example, your local computer's IP) in main.cpp.
• Build and flash the application.

The application already contains a bootloader for three boards (FRDM-K64F, NUCLEO-F429ZI and ODIN-W2). If you want to add another board, you need to compile the bootloader.

Creating an updated application

Now, change some parameters in the application, for example the speed at which blinky runs or the text at the start of the application, and recompile. Then, copy the mbed-os-example-fota-http_application.bin to a location where the board can download it.

For example, with Python installed, copy the file to a new folder, rename the file to update.bin. From a terminal, run (in the folder):

$ python -m SimpleHTTPServer

This starts an HTTP server on port 8000. If the board and computer are on the same network, the board can download the file directly from the computer.

Running the application

Here's a video of the process in action on a uBlox EVK-ODIN-W2 board.

Security

This application contains no security, so do not deploy it to real devices! Some tips to make the process more secure:

• Download the firmware over HTTPS. Mbed-http already supports this.
• Calculate the hash of the firmware to ensure the whole firmware was downloaded.
• Sign the firmware with a private key, and hold the public key in both bootloader and application, so the update process can verify the source of the firmware.
• Tag the new firmware with a version number and a device class ID, so you do not apply a wrong firmware accidentally.
• Keep the key used to verify the firmware in a secure element to prevent people from stealing it.
• Store at least two copies of the firmware for rollback purposes.
• Add a watchdog in the bootloader, so if the new firmware image bricks the device, you can roll back the old firmware.

Arm has already completed all this work for you, and the cryptographically secure bootloader and update client are available to Mbed Cloud licensees.

Size of the bootloader

A final note on the size of the bootloader. When working on a constrained device, you can make the bootloader smaller by removing the FATFileSystem driver and using the external flash directly. In addition, make sure to not use any printf statements, compile with a release profile (mbed compile profile=release) and remove the RTOS. In addition, building with ARMCC yields better results than with GCC for code size. With these optimizations, we built a bootloader for the MultiTech xDot that only uses 21K of flash.

Conclusion

Mbed OS 5.5 has the infrastructure in place to make it a lot easier to build firmware-update aware applications. Integration of bootloaders in the build process removes the error-prone process of manually linking bootloader and application together, and the standard FlashIAP and data storage APIs make it possible to target many boards with only one application. On top of this, these APIs are not linked to any connectivity method. Arm is using the APIs to have a single update client which can update devices both over CoAP and LoRaWAN. The initial release supports four development boards, but we hope to support many more boards very soon. Pull requests are always welcome (here's an example)!

-

Jan Jongboom is working on secure multicast firmware updates over Low-Powered Wide Area Networks like LoRa. He is speaking about this topic during Arm Techcon 2017.

Posted by Anna Bridge

We are pleased to announce the mbed OS 5.5.6 release is now available. This release includes support for new targets NUMAKER_PFM_M487 and TOSHIBA TMPM066, an update of mbed-coap to version 4.0.9, plus numerous bug fixes to improve code reliability.

Here is a full list of all changes and fixes in this release...

Known Issues

• 4928: AES hardware acceleration not working for STM32F439xI

Ports for Upcoming Targets

• 4608: Support Nuvoton's new target NUMAKER_PFM_M487

• 4840: Add Support for TOSHIBA TMPM066 board

Fixes and Changes

• 4801: STM32 CAN: Fix issue with speed function calculation

• 4808: Make HAL & US tickers idle safe

• 4812: Use DSPI SDK driver API's in SPI HAL driver

• 4832: NUC472/M453: Fix several startup and hal bugs

• 4842: Add call to DAC_Enable as this is no longer done as part

• 4849: Allow using of malloc() for reserving the Nanostack's heap.

• 4850: Add list of defines to vscode exporter

• 4863: Optimize memory usage of wifi scan for REALTEK_RTW8195AM

• 4869: HAL LPCs SPI: Fix mask bits for SPI clock rate

• 4873: Fix Cortex-A cache file

• 4878: STM32 : Separate internal ADC channels with new pinmap

• 4392: Enhance memap, and configure depth level

• 4895: Turn on doxygen for DEVICE_* features

• 4817: Move RTX error handlers into RTX handler file

• 4902: Using CMSIS/RTX Exclusive access macro

• 4923: fix export static_files to zip

• 4844: bd: Add ProfilingBlockDevice for measuring higher-level applications

• 4896: target BLUEPILL_F103C8 compile fix

• 4921: Update gcc-arm-embedded PPA in Travis

• 4926: STM32L053x8: Refactor NUCLEO_L053R8 and DISCO_L053C8 targets

• 4831: Remove excessive use of printf/scanf in mbed_fdopen/_open

• 4922: bug fix: xdot clock config

• 4935: STM32: fix F410RB vectors size

• 4940: Update mbed-coap to version 4.0.9

• 4941: Update of MemoryPool.h header file.

Using the release

You can fetch the mbed OS 5.5.6 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.6". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Jan Jongboom

It happens to all of us. At some point, your application compiles, but the linker fails with a message similar to '.data' will not fit in region RAM. This is a sign that the application does not fit in flash, something that is limited on most microcontrollers. Flash memory takes up a lot of silicon area, and therefore increases both the cost and the likelihood of defects in microcontrollers. Flash also requires power, and more flash increases power consumption. Less flash is better for cost and energy efficiency, but it can be a nuisance when writing applications.

To find out what filled that precious flash, you can dissect the .elf file in your build folder, but it's a tedious task. To make this process easier, Milosch Meriac - security expert at Arm and the author of uVisor - wrote mbed-os-linker-report. This small tool creates a visualization of linker statistics for Arm Mbed OS 5.

Visualization of flash usage of an Mbed OS 5 program

Instructions on how to use the tool are on GitHub, and a live demo is available here.

If you're interested in making your application use less flash, read the blog posts on optimizing flash memory usage and on tuning the parameters of Mbed's RTOS.

-

Jan Jongboom is Developer Evangelist IoT at Arm, and he values his flash memory.

Posted by Danielle Irons

An era of pervasive connectivity is dawning – beyond the computer on your desk or the smartphone in your pocket, now everything else is joining the network. For industrial equipment, the Internet of Things movement is opening up entirely new economic possibilities for remotely monitoring the condition of connected assets to optimize operational efficiency, prevent downtime, and drive incremental aftermarket service and support revenue.

On Tuesday, September 26th, this webinar will be hosted in both a morning and afternoon session. Our speakers will dive into detail to explain the benefits, system architecture, and industry best practices for deploying highly secure remote condition monitoring solutions for smart industrial and factory products.

Register now to secure your spot and gain greater insight into the business value of monitoring connected assets.

Agenda

1. Introduction to the benefits of remote condition monitoring for smart industrial products

2. A secure reference architecture based on Arm Mbed and Exosite Murano

3. Industry best practices for commercializing remote condition monitoring solutions for industrial and factory use cases

Speakers

Jim Carver, Sr Mgr, Americas Business Development, Arm

Mark Benson, CTO, Exosite

Posted by Danielle Irons

An era of pervasive connectivity is dawning – beyond the computer on your desk or the smartphone in your pocket, now everything else is joining the network. For industrial equipment, the Internet of Things movement is opening up entirely new economic possibilities for remotely monitoring the condition of connected assets to optimize operational efficiency, prevent downtime, and drive incremental aftermarket service and support revenue.

On Tuesday, September 26th, this webinar will be hosted in both a morning and afternoon session. Our speakers will dive into detail to explain the benefits, system architecture, and industry best practices for deploying highly secure remote condition monitoring solutions for smart industrial and factory products.

Register now to secure your spot and gain greater insight into the business value of monitoring connected assets.

Agenda

1. Introduction to the benefits of remote condition monitoring for smart industrial products

2. A secure reference architecture based on Arm Mbed and Exosite Murano

3. Industry best practices for commercializing remote condition monitoring solutions for industrial and factory use cases

Speakers

Jim Carver, Sr Mgr, Americas Business Development, Arm

Mark Benson, CTO, Exosite

Posted by Anna Bridge

We are pleased to announce the mbed OS 5.5.7 release is now available.

This release includes an update for mbed-coap to version 4.0.10, bootloader support for DISCO_L476VG and a critical workaround for 'STM32F439xI-family AES hardware acceleration occasionally produces incorrect output (#4928)' (achieved by disabling AES acceleration by default). There are also numerous bug fixes and code enhancements.

Here is a full list of all changes and fixes in this release...

Known Issues

Ports for Upcoming Targets

Fixes and Changes

• 4977: disable -f option for assembly files for IAR

• 4944: STM32: F1 GPIO: Enable AFIO clock

• 4950: M487: Support USB device/host

• 4951: UBLOX_EVK_ODIN_W2- add BUTTON1/2 definitions

• 4954: Fix ISR powerdown in mbed_application.c

• 4934: mbedtls: STM32F439xI: Don't enable AES acceleration by default

• 5001: Update mbed-coap to version 4.0.10

• 4933: test: fix stats depth variable scope

• 4963: K66F,KW24D,K22F,K64F: Fix NVIC_NUM_VECTORS value

• 4939: Fix crashes on boot on some Kinetis devices

• 4929: STM32F4: Increase ADC sample time for VREF

• 4945: Extends test set for Mail class

• 4975: Stm32 spi 3 wires mode support

• 4992: Fix BLE API docs

• 4995: Add LED color remapping definitions to Odin target

• 4996: Reduce K64F Ethernet driver to 1 thread

• 4997: Correct LWIP_DEBUG definition

• 5013: MTS targets: Don't use any printf() calls when NDEBUG is defined

• 4924: Adjust Stack size Allocation (IAR, LPC176x)

• 4776: Remove use of internal RTX types

• 4881: [STM32F401xE] Freeze master timer on stop/breakpoint

• 4984: Unify mbed OS tools testing style with what's used in mbed-ls, htrun, greentea

• 4665: Enable sdram usage of REALTEK_RTL8195AM

• 4958: Add bootloader support for DISCO_L476VG

• 5055: Travis: fix the latest breakage - use group:

Using the release

You can fetch the mbed OS 5.5.7 release from the mbed-os GitHub repository, using the tag "mbed-os-5.5.7". Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Posted by Jan Jongboom

A year ago we launched experimental JavaScript support for mbed OS 5, which allows developers to write their IoT applications in a high level scripting language. This is possible through JerryScript, a lightweight JavaScript engine that has full EcmaScript 5.1 support, but fits in only 64K of RAM.

Last week the core contributors to the JerryScript project came together in Szeged, Hungary to talk shop, discuss new features and drink some home-made palinka. Rob Moran (senior engineering manager, Tools team) and Jan Jongboom (JerryScript contributor) were representing Arm.

JerryScript workshop participants: twenty-four people from seven companies, flying in from three continents.

State of JerryScript

With twenty-four participants from Arm, Intel, Texas Instruments, Samsung, Fitbit, Hop.js, and the University of Szeged, we had a wide range of JerryScript users and contributors in the same place.

The workshop was kicked off by Ákos Kiss - who leads the JerryScript team at the University of Szeged - and László Langó, giving an overview of the changes in JerryScript since the last workshop in April 2016. Some highlights:

1. Last year the JerryScript project was transferred by Samsung to the JS Foundation. This will provide long-term governance and stability to the project.
2. A debugger was added to the project, making it possible to step through JavaScript code running on a real device.
3. A lot of new features were contributed, including ArrayBuffer, TypedArray, Promises, extensions for argument parsing and module extensions, an automated test system and support for Zephyr and Mbed OS 5.
4. Performance has increased by 200%, and memory consumption is down by (up to) 30% when running Sunspider tests.

This was all an amazing community effort, with 44 contributors landing 676 pull requests. The full slide deck is available here.

Projects and companies using JerryScript

The teams demonstrated a number of JerryScript projects:

• Fitbit is releasing their first smartwatch in a few weeks, the Fitbit Ionic. The watch comes with a complete JerryScript API to deal with all kinds of watch functions, allowing developers to write their watch applications in JavaScript. It was great to hear from a product company on how they integrate the runtime, separating application heaps (through an MPU) and enforcing constraints to avoid the system becoming unresponsive due to a rogue application.
• Arm showed the current state of JerryScript on Mbed, including Bluetooth Low Energy support with an nRF52-DK connecting to an iPhone, the REPL, an experimental simulator, and the JerryScript wrapper generator.
• Intel showed their work on the argument parsing and module extensions, which have both landed in core. They also showed an early version of their in-browser simulator, which uses Emscripten to cross-compile C++ bindings, and they presented the NAPI proposal, which makes it possible to share native modules between node.js and JerryScript. Last, they demonstrated a new testing framework (compatible with Jest) to run integration and unit tests.
• The IoT.js project, mainly developed by Samsung and the University of Szeged, released their 1.0 version two months ago. The project implements a variety of node.js compatible modules, including events, net and dgram, which provide a really nice ecosystem on top of JerryScript. It's something that we (Arm) are looking at with great interest, and running IoT.js on top of Mbed would be great.
• Hop.js showed their distributed JavaScript runtime - built on top of IoT.js - that creates services for business applications, all written in one language, which can run partially on embedded devices and partially on the server.
• Texas Instruments proposed a system for defining JerryScript interfaces on top of WebIDL, the interface language used by browser vendors for browser APIs. They created a set of scripts that take WebIDL definitions and output JerryScript boilerplate, separating the interface from the actual C++ <-> JS conversion code.

In addition, there were various discussions on the W3C Sensor API, calling conventions of C++ functions from JavaScript, debugging, and how to simulate JerryScript applications in the browser.

Other events

Of course a workshop is not all business; there was time for some fun as well. For many of us it was the first time that we met face to face, normally only talking on GitHub, IRC or during the bi-weekly community calls (join us! The calls are announced on the mailing list), so dinner conversations are a great casual opportunity to get to know your fellow core contributors. Many thanks to everyone at the University of Szeged who took us out every night, who brought us palinka, and who dragged us to the wine festival (Hungary is great wine country).

View from the wine festival, and a bottle of homemade palinka.

-

Jan Jongboom is a contributor to JerryScript. He spoke about JerryScript on mbed OS 5 during JSConf.asia 2016.

Posted by Mohit Kedia

The Arm Mbed OS 5.6.0 release helps to further simplify the internet of things (IoT) and embedded product development with the addition of several new features, such as tickless RTOS scheduler support to enable long periods of low-power sleep and IPv6 support to cellular stack to provide enhanced web connectivity. The release also adds several new drivers and platform APIs, support for IAR Embedded Workbench v8.1 and hardware security enhancements. In addition, this release contains many minor fixes and enhancements and brings support for 93 target development boards. In the release note below, we summarize some of the key updates to Mbed OS as a part of Mbed OS 5.6.0 release.

One additional change you may have noticed is developer.mbed.org is now os.mbed.com. We have updated our URL for consistency across the website. The community should experience no significant changes or issues due to this change, as all redirects are in place.

Core OS

Tickless RTOS Scheduler

Power consumption is one of the most important design requirement for IoT devices. Meeting the power budget is becoming very challenging as the systems today include more sensors, faster responses and more connectivity. Mbed OS introduces the Tickless RTOS Scheduler to help achieve the design of low power systems.

Support Tickless Operation: In tickless operation, you don’t have to make a tradeoff between high-frequency timing interval, which consumes more power, and low frequency timing interval, which results in suboptimal time keeping, because the scheduler schedules the next timer tick in response to the next event rather than a fixed timer tick.

Integration with Mbed OS: The Tickless RTOS Scheduler is integrated in the native OS and based on the low power ticker. The Tickless RTOS Scheduler is already integrated in the Ticker API available at https://os.mbed.com/docs/v5.6/reference/ticker.html . The specifications are released to help other boards support the implementation of the low power timer and Tickless scheduler. We are working with Mbed silicon partners to enable support for Tickless Scheduler on all Mbed Enabled boards.

Support for Arm Cortex-M23 and Cortex-M33 Devices

Connected devices are growing at a fast pace, and according to Gartner, there will be more than 20 billion connected devices by 2020. As the number of IoT devices grows, the devices are becoming an increasingly attractive target for cybercriminals. Security is becoming one the most important product requirements for IoT devices. Arm has announced Arm Cortex-M23 and Cortex-M33 processor architecture, which includes TrustZone for Armv8-M and provides hardware-enforced isolation between trusted and untrusted resources while maintaining the efficient exception handling and determinism that have been the hallmark of all Cortex-M processors.

Mbed OS 5.6.0 release provides initial support for Arm Cortex-M23 and Cortex-M33 based devices. This release includes support for RTX and tools for GCC only. This release is an instrumental step in supporting upcoming Arm Cortex-M23 and Cortex-M33 MCUs. You would benefit from support for Arm Cortex-M23 and Cortex-M33 as the new development boards including those processors start to come out.

New Drivers and Platform APIs

In the Mbed OS 5.6.0 release, we have also added several new drivers and platform APIs. Following are some of the notable additions.

CriticalSectionLock Class:CriticalSectionLock class enables the code to run with interrupts disabled. More information is available at https://os.mbed.com/docs/v5.6/reference/critical-section-lock.html.

DeepSleepLock Class: DeepSleepLock class enables the code to run with deep sleep locked. More information is available at https://os.mbed.com/docs/v5.6/reference/deepsleeplock.html.

Mbed_error: Mbed_error prevents recursion if error is called again. More information is available at https://os.mbed.com/docs/reference/error.

NonCopyable Class: NonCopyable class allows the creation of classes whose objects cannot be constructed using a copy constructor or assigned to another. It forces the classes copy constructors to be private. More information is available at https://os.mbed.com/docs/v5.6/reference/noncopyable.html.

Apart from the features described above, Mbed OS 5.6.0 also includes several new features, improvements in current APIs and HAL specification to ensure cross platform support of all APIs. You can find all the changes on Github.

Connectivity

Cellular stack now supports IPv6 along with previous IPv4

Cellular connectivity is widely used for connecting IoT devices. It is more prominent in the use cases which are designed for mobility, such as smart cars, and devices operating in remote areas, such as oil fields. According to Ericsson, 10% of all IoT devices by 2021 will be connected by cellular connectivity.

Mbed OS already includes the cellular point to point stack with IPv4 connectivity, and in Mbed 5.6.0, we are releasing cellular stack supporting IPv6. IPv6 is being widely adopted because it allows almost unlimited (3.4×1038) addresses, and IPv4 only allows up to 4.3 billion addresses. More information is available at https://os.mbed.com/docs/v5.6/reference/cellular-api.html.

Security

Update to Mbed TLS 2.6.0

Mbed TLS is an open source, portable, easy to use, readable and flexible SSL library. It enables you to include cryptographic and SSL/TLS capabilities in your embedded products.

The Mbed OS 5.6.0 release supports the latest release of Mbed TLS 2.6.0. The Mbed TLS 2.6.0 fixes an authentication bypass issue in SSL/TLS. More Mbed security information is available at https://os.mbed.com/docs/v5.6/reference/security-overview.

Targets and Tools

Thanks to our partners’ hard work, Mbed OS 5.6 adds eight new target platforms and now supports 93 target platforms. We’ll continue to add targets in our biweekly patch releases as partners work with us on support.

Support for IAR Embedded Workbench for Arm v8.1

Mbed OS 5.6.0 enables initial support to IAR Embedded Workbench for Arm v8.1, which is the latest IAR compiler to support Arm MCUs. Although the default compiler version for IAR remains 7.8.x, you can also build the codebase using IAR 8.1 (builds without dependencies on archives). The current support for IAR Embedded Workbench for Arm v8.1 is limited only to the Mbed CLI tool, and we plan to migrate to the IAR Embedded Workbench for Arm v8.1 as a default IAR toolchain in Mbed OS release 5.7.0.

Support for Arm Compiler 6

Mbed OS 5.6.0 adds early support for the latest and most efficient version of the Arm compiler, the Arm Compiler 6. This version is based on the LVVM framework, optimized to best use hardware features. You can read about the Arm Compiler 6 at https://developer.Arm.com/products/software-development-tools/compilers/Arm-compiler. The current support for Arm Compiler 6 is limited only to the Mbed CLI tool, and we plan to migrate to Arm Compiler 6 as a default in Mbed OS release 5.7.0.

Fixes and changes

The release includes many general enhancements and fixes and upstreams those that have been maintained within the Mbed OS codebase itself. Please visit https://os.mbed.com/releases/ for the full list of changes and known issues.

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

Testing

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

Continuous Integration Framework:

The continuous integration framework is designed to make sure that every new feature and change in Mbed OS is tested to ensure

- For every new feature, we create tests that we then deliver to our partners. For every board to be Mbed Enabled, we need our partners to successfully conduct these tests.

- Partners test the changes on their board before submitting a Pull Request (PR) on GitHub.

- Once the PR is submitted, then the gatekeepers manually review the code to make sure it meets all the coding guidelines and code standards.

- Once approved by gatekeepers, the code goes through the automated test setup where code is added to Mbed OS for testing and examples built across all the platforms, such as IAR, ARM and GCC.

- During the testing phase, we select the combination of boards and devices that support a variety of peripherals, MCU cores and features to select maximum coverage.

- To make sure that the Mbed OS code is compatible with all the IDEs, we test that the code exports properly to all the compilers.

- We merge the PR only if the all the above is successful.

Above: One of the Mbed OS test farms.

Following are the summary results for testing conducted for Mbed OS 5.6.0:

· Total test time is 5,770 hours on actual development boards.

· We have added 94 new test cases since the Mbed OS 5.5.0 release to test new and existing features on Mbed OS. The number of total test cases is 312.

· We performed 361,440 example builds since the Mbed OS 5.5.0 release.

· The total number of binaries built is 12,826,080 since the Mbed OS 5.5.0 release.

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

Using the release

You can fetch the latest version of the Mbed OS 5.6 release from the mbed-os GitHub repository using the branch https://github.com/ARMmbed/mbed-os/releases/tag/mbed-os-5.6.0.