The nRF5 SDK documentation includes descriptions and other reference material to help you understand the various components of the SDK. Examples are provided for development purposes only and should always be tested with your design.
See Getting Started for instructions on how to run the provided examples.
This version of the SDK supports the following SoftDevices:
This SDK supports developing for nRF52810 on the PCA10040 board. See Developing for nRF52810 for details.
To download a copy of the SDK documentation for offline use, go to developer.nordicsemi.com.
SDK Release Notes:
nRF5 SDK v14.2.0
------------------------
Release Date: Week 46, 2017
Highlights:
- Support for the new S112 SoftDevice v5.1.0.
The following toolchains/devices have been used for testing and
verification:
- ARM: MDK-ARM version 5.18a
- GCC: GCC ARM Embedded 4.9 2015q3
- IAR: IAR Workbench 7.80.4
- SES: SES 3.30
- Linux: Ubuntu 17.04, Kernel 4.10.0.
- Jlink: 6.20d
Supported SoftDevices:
- S112 v5.1.x
- S132 v5.0.x (for v5.1.x, see the note below)
- S140 v5.0.0-2.alpha
- S212 v5.0.x
- S332 v5.0.x
S132 compatibility:
The newly released S132 SoftDevice v5.1.0 is drop-in compatible with
S132 v5.0.0, which is included in this SDK release.
However, there are some limitations that you must be aware of when
replacing the included SoftDevice with the new one:
- In S132 v5.1.0, the SoftDevice RAM usage is reduced. Examples that are
optimized on RAM usage return a warning that the application RAM start
address can be lowered. The examples work as before but are not fully
optimized on RAM usage.
- The test images in examples\dfu\secure_dfu_test_images are tightly
connected with the precompiled HEX files located in
examples\dfu\bootloader_secure_ble\hex. Therefore, they cannot be used
in combination with the new SoftDevice.
Supported boards:
- PCA10040E (nRF52810 emulation on PCA10040)
- PCA10040
- PCA10056 (limited support; see the "Scope for the nRF52840 chip" section)
- Dynastream's D52DK1 (only for ANT examples)
For other devices and boards, see the SDK documentation, section "Using
the SDK with other boards".
*** Scope for the nRF52840 chip
********************************
All examples and libraries for the new chip must be treated as
experimental.
Some examples have not been ported to run on nRF52840. Check the
existing example projects to see which targets are supported.
The following SDK features are supported on the new nRF52840 chip:
- IEEE 802.15.4 stack library with an example
- Most BLE, hardware peripheral, and NFC examples (with some
exceptions; see the available example projects for details)
- Peripheral HAL and drivers (both for existing and new peripherals)
- Cryptography library including CryptoCell CC310 backend
- NFC Type 2 Tag and Type 4 Tag
- Secure DFU (only with micro-ecc backend)
- DTM including support for the new Bluetooth 5 features
- Gazell
The following SDK features are not supported on the new nRF52840 chip:
- ANT
- Eddystone
- ESB
- FreeRTOS
- IoT components
- Serialization of the S140 SoftDevice v5.0.0-2.alpha
*** New features
*****************
** BLE **
- Added support for the S112 SoftDevice v5.1.0.
** Crypto **
- Added a makefile for compiling the micro-ecc library with a "soft"
FPU ABI (required for nRF52810, which does not have hardware FPU
support).
** Drivers and libraries **
- Added support for a "soft" FPU ABI in the Task Manager library
(required for nRF52810, which does not have hardware FPU support).
*** Changes
************
** Drivers and libraries **
- TWI Transaction Manager: Added support for passing the TWI
configuration in function nrf_twi_mngr_perform(). Pass NULL if you do
not want to use this new feature.
- Command Line Interface: Added support for commands longer than 255
characters.
*** Bugfixes
****************
** Drivers and libraries **
- Fixed "echo" command behavior in nrf_cli.
- Fixed a bug in nrf_ringbuf where allocation protection failed on a
second attempt to allocate a buffer in use.
- Fixed a compile error in the Task Manager library when stack guard is
off.
- Fixed invalid module names in logger output when LTO was used in the
GCC compiler.
- Fixed a bug in the logger where output could get corrupted when
logging was interrupted by NRF_LOG_PROCESS() (for example, flushing
in error handler).
** DTM **
- Fixed a bug preventing certain TX power values to be set.
- Set the PDU header payload type field of coded PHY 0xFF packets to
0x04 instead of 0x03 to make the 0xFF packets valid.
*** Known Issues
****************
** BLE **
- When working on the emulated nRF52810 target, if you change the
optimization level and/or add the logging functionality, the project
might not compile or fail at runtime due to not enough flash
available for FDS or Peer Manager.
- All Bluetooth applications not using the nrf_queued_write module will
assert when a peer sends a Write request with the opcode 'cancel all
operations' (BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL), after the
SoftDevice call to sd_ble_gatts_rw_authorize_reply. This SoftDevice
call, for the opcode 'cancel all operations', returns
NRF_INVALID_PARAMS if the gatt_status is not BLE_GATT_STATUS_SUCCESS.
** BLE IOT **
- Neighbor discovery module for lwIP requires the on-link flag in the
router advertisement to be set in order to create a SLAAC address
from the prefix. However, RFC 7668 (https://tools.ietf.org/html/rfc7668)
requires this bit to be zero. Therefore, the nd6.c from lwIP source
has been modified to relax this check.
- There are some issues when using the IoT examples against Linux
Kernel 4.12+ which causes the kernel to only work with one 6LoWPAN
connection. If more than one kit is connected using 6LoWPAN, none of
the nodes will be accessible.
- Scheduler has been included in most IoT examples to avoid race
conditions found when using lwIP stack, more precisely the TCP
examples.
The issue was that the TCP client stopped working after about 15
hours. However, when using mbedTLS, the use of scheduler is not
possible.
Therefore, the MQTT client examples might be affected by this issue.
- The use of security, both with TLS and DTLS, should be treated as
experimental.
- MQTT examples cannot be used with commissioning. There is not enough
RAM to accommodate both TLS and the commissioning service.
** NFC **
- NFC Type 2 and Type 4 Tag HAL modules require using TIMER 4 on
nRF52832.
- Some mobile phone apps cannot write Type 4 Tag ("NFC Tools" and
"TagWriter" v4.1 seem to be okay to use).
** USB (experimental) **
- MSC implementation does not stall when the host requires more bytes
than are available in the selected descriptor. It is not a problem
for any tested driver on Windows and Linux, but still violates the
specification.
- During high USB traffic, in rare cases, communication might hang or
the endpoint data might be transferred twice. See PAN 104.
** Drivers and libraries **
- SAADC driver is not handling detection limits 'high' and 'low'
correctly if SAADC resolution is greater than 10 bits.