Enhancement/Fixes to existing features

BLE host code size optimization

The HCI (Host Controller Interface) command/acknowledgement exchanges have now been made blocking, resulting in a simpler API, minimization of finite state machine, and reduction in code size. The NimBLE host has also been made task-less by default but allowing an application developer to turn the host's flat library into its own task if so desired. 
These changes are not backwards compatible.

File system changes

Garbage collection now deletes and recreates all cached data blocks as they are potentially invalid after a garbage collection cycle.

Logging improvements

Mynewt OS allows the application to pick handler for logs. Logs can be directed to console, circular buffer in memory, or to circular buffer in flash (FCB). Timestamp for logs now have microsecond precision. Multiple log entries can now be sent in a single newtmgr json response.

Config improvements

Config variable settings can now be persisted either in a file, or in FCB. Application chooses where it wants the configuration to be loaded, and where it should be saved.

New features

HAL additions in OS 

 

Pairing and Security Management Protocol in BLE (NimBLE)

Pairing is the process for creating one or more shared secret keys. NimBLE now supports LE Legacy pairing (“Just Works”, “Passkey entry” pairing methods). All LE legacy pairing methods use and generate 2 keys:
  1. Temporary Key (TK): a 128-bit temporary key used in the pairing process which is used to generate STK.
  2. Short Term Key (STK): a 128-bit temporary key used to encrypt a connection following pairing.
Initial encryption support has been added to the Nimble controller for both nRF52 and nRF51. By default, encryption is off. Enabling encryption requires configuration before compile time. Note that the nRF51 hardware limits the maximum payload that can be encrypted to 27 bytes. 
LE Secure Connections with public key exchange will be supported in the next release. Also planned is support for encryption of larger 251 byte frames on the nRF51.

iBeacon support in BLE (NimBLE)

Mynewt NimBLE supports broadcast of iBeacon advertisements containing four main pieces of information (UUID, Major, Minor, Tx) in the standardized format at a regular interval.

Signed images

Mynewt offers a choice RSA or ECDSA signature over the image hash (SHA256). The signature is stored as a TLV at the end of the image. The bootloader is built with the public key corresponding to the private key signing the image and uses the public key to verify the signature before allowing the image to boot.

Flash Circular Buffer

FCB is a facility that allows you to store blobs of data in flash a bit like a FIFO. Data is appended in the end, and is read from the beginning. The FCB is typically used for keeping a log of events and having them persist over a system reset. When the flash sectors fill up eventually, the data in the oldest sector is erased. 

Low power support

Support has been added for tickless operation during idle task to reduce power consumption by putting the CPU to sleep when the OS does not have any useful work to do.. The Mynewt OS can enter a low power idle state using a CPU-specific mechanism. For example, ARM processors use the 'WFI' instruction for this purpose. 

Bootloader support

Bootloader is now available for all supported BSPs including nRF52 boards, Rigado BMD-300 eval board (also based on the nRF52 SoC), and Olimex boards.

Known Issues

1. Default application task size is too small when full logging is enabled.

 This results in stack overflow when full logging is enabled. The fix is to increase the bleprph app task stack size from 200 words to 288 words. The change may be applied to the current release by modifying apps/bleprph/src/main.c as follows:

 #define BLEPRPH_STACK_SIZE          (OS_STACK_ALIGN(288))

Alternatively, the user may choose to use the fixed code in the "develop" branch in the repository. The fix will be available as part of the download package in the next release.

 

2. BLE peripheral devices may become unresponsive to the service discovery requests from the central device.

The "Bleprph" application may not instruct the host to send the initial startup sequence to the controller.  The result is that BLE events are masked in the controller (i.e., the controller doesn't send the necessary notifications to the host).  The immediate issue is that the host is not informed when a connection is established.  Because the host does not know about connections being established, it is unresponsive to the service discovery that the central performs immediately after connecting.  The central eventually disconnects when its service discovery operation times out.