Release Date

Dec 13, 2016

Enhancement/Fixes to existing features

Simplified and consistent system configuration and initialization

The updated system simplifies the process of creating an app by moving package initialization out of apps code (main()) into syscfg.yml files in the app and BSPs and auto-generated C code. It also enables an audit of the entire system configuration via the "newt config" command.

System initialization happens in two stages:

 1. BSP init (bsp_init()):  sets up everything that is BSP specific:

    • Flash map
    • Driver initialization: UART, ADC, SPI, etc.

2. sysinit (sysinit()): sets up all the libraries which aren't BSP or hardware dependent (os, msys, network stacks, etc).

The initialization code is implemented in the appropriate package. Newt generates C code which executes each package's initialization function.

For example, you can check out the syscfg.yml file for bleprph app (to enable a BLE Peripheral) here. If you are running it on an nRF52 board, configurations may be set in the syscfg.yml file for the BSP as seen here.

Newt Tool enhancements

newt sync

To refresh/recreate the contents of the project.state file locally. This is useful in two scenarios:

    1.  When you are subscribed to a branch that might change (e.g. 0-dev)
    2. When you don't want to check-in the repos directory, but you want to exactly replicate the contents of project.state for known releases.

newt vals

Displays valid values for the specified element type(s). Valid element types are:

    • api
    • app
    • bsp
    • build_profile
    • compiler
    • feature
    • lib
    • sdk
    • target

For example, 

$ newt vals bsp
bsp names:

newt pkg new

This command allows the user to create a new package from a template. The package template includes:

    • src/ directory to place the source files,
    • include/ directory to place the header files,
    • pkg.yml containing the base definition of the package,
    • file 

newt build: honors precedence hierarchy for flags

In the case of conflicting flags, the higher priority package's flag wins. See MYNEWT-323 - Getting issue details... STATUS  for details. Package priorities are assigned as follows (highest priority first):

    • target
    • app (if present)
    • bsp
    • <library package>
    • compiler

newt error message fixed

Error message corrected when trying to load an image that does not exist.  MYNEWT-362 - Getting issue details... STATUS

Log format changes

The initialization of logging resources has been moved from modules to application. The logging handler is chosen by application and uses standard log_handlers rather than having each app call the handler_init function. Per-instance log structure are declared and initialized in each app and are associated with the log calls by log_register. 

Image manager improvements

The image upgrade manager utility (/mgmt/imgmgr/) now has a Command Line Interface (CLI) through which you can list images, tell it to boot to a specific version, and display info about currently running image.

New Features

Bootloader supports serial upgrade of images

A package has been added that can be conditionally included in bootloader to allow it to accept image upgrades over serial port. The code monitors a GPIO pin, and if it’s set to specific state during bootup, it will enter the serial downloader, awaiting these commands. 

The 'BOOT_SERIAL:' option in apps/boot/syscfg.yml must be set to '1' in  to compile in the serial upgrade package.

Host-only NimBLE stack

The host and controller portions of the NimBLE stack has been separated. The HCI (Host Controller Interface)  allows the user to use only the host portion of the NimBLE code or the controller portion.

Several example BLE apps added

In addition to bletiny (which provides a basic interface to the NimBLE host), blehci (a BLE controller-only application that can interact with a different host e.g. BlueZ), Mynewt now comes with the following apps by default:

  •  bleprph: A basic peripheral device with no user interface. It advertises automatically on startup, and resumes advertising whenever a connection is terminated. It supports a maximum of one connection.
  •  blecent: A basic central device with no user interface. This application scans for a peripheral that supports the alert notification service (ANS). Upon discovering such a peripheral, blecent connects and performs the following actions:
    •  Reads the ANS Supported New Alert Category characteristic.
    • Writes the ANS Alert Notification Control Point characteristic.
    • Subscribes to notifications for the ANS Unread Alert Status characteristic.
  • bletest: An application to test different BLE features, roles (advertiser, scanner, initiator), throughput, connections etc.
  •  bleuart: Implements a simple BLE peripheral that supports the Nordic UART / Serial Port Emulation service

Wi-Fi support

A socket interface for WiFi chips has been added. Basic functions are supported e.g. scan, connect, disconnect. Configuration is currently through a console interface but additional management functions (e.g. AP profiles, saving config in flash etc.) are on the roadmap. Supported hardware are Arduino MKR1000 and Arduino's Wifi shield with WINC1500 on it.

Hardware Abstraction Layer (HAL) additions


An API has been implemented for a new HAL for SPI access for both master and slave:


 The API for an I2C bus can be seen here: . Currently, this is a master API allowing the Mynewt device to function as an I2C master. A slave API is pending for future release.


Allows you to set a recurring watchdog timer to fire no sooner than in 'expire_secs' seconds. Watchdog should be tickled periodically with a frequency smaller than 'expire_secs'. Watchdog needs to be then started with a call to hal_watchdog_enable().


A HAL timer API has been added to the OS. The user can declare multiple HW timer if desired. They are enqueued on a particular HW timer queue when the user calls the hal_timer_start or hal_timer_start_at API.

GPIO: MCU-specific API that maps port->pin 

An MCU-specific define has been added that maps port/pin to a single number. Thus, for MCUs that have ports, MCU_PORTA(pin) returns that pin. For example, the defines for STM32F4 can be seen at


The full list of HAL API completed so far can be seen at The BSP specific parameters for the HAL can be found in the appropriate directory e.g. hw/bsp/nrf52dk/src/hal_bsp.c for Nordic nRF52 Dev Kit. 

Newtmgr over BLE

This enables remote configuration, remote soft reset, and firmware upgrade using "newtmgr" protocol over Bluetooth Low Energy. A globally unique UUID is used for newtmgr.

Crashdump generation

Mynewt now offers a utility for recording information when the system crashes to facilitate troubleshooting. There are two options:

  • full memory dump of all SRAM
  • reduced footprint with only registers and stack of task creating the fault (optional)

Support for New BSPs

  • FRDM-K64F from NXP
  • STM32F4 from STMicroelectronics
  • NUCLEO-F401RE from STMicroelectronics 
  • Nano2 BLE SoC from Redbear
  • Blend2 from Redbear


  • No labels