nRF5 SDK for Mesh v5.0.0
Migration guide

This migration guide is complementary to the Release Notes. It describes practical actions you must take to update your code to a newer version of the nRF5 SDK for Mesh.

Note
Always refer to the migration guide from the latest documentation release on the nRF5 SDK for Mesh documentation website, regardless of the versions you are migrating to and from.

Table of contents


Migration from v4.2.0 to v5.0.0

Read this migration guide together with the nRF5 SDK for Mesh v5.0.0 release notes.

Recompiled Bootloader binaries

Required actions

New timer in Sensor Server API

Required actions

Revised entry ID constants

Required actions

MemorySegment section renamed

Required actions

model_common functions replaced

Required actions

generic_ponoff_setup_server_status_publish removed

Required actions

Replay cache is now stored

Required actions


Migration from v4.1.0 to v4.2.0

Read this migration guide together with the nRF5 SDK for Mesh v4.2.0 release notes.

Change to mesh_config_clear() behavior

Required steps

Recompiled Bootloader binaries

Required actions

Removed prebuilt sensor for LC example

Required actions

Updated nrfutil branch

Required actions


Migration from v4.0.0 to v4.1.0

Read this migration guide together with the nRF5 SDK for Mesh v4.1.0 release notes.

Updated GNU ARM Embedded Toolchain required minimum version to 9-2019-q4-major

Required actions

UUID generation updated

Required actions


Migration from v3.2.0 to v4.0.0

Read this migration guide together with the nRF5 SDK for Mesh v4.0.0 release notes.

Added Mesh configuration for DSM, net state and access layer

Required actions

BEARER_EVENT_USE_SWI0 changed location

Required actions


Migration from v3.1.0 to v3.2.0

Read this migration guide together with the nRF5 SDK for Mesh v3.2.0 release notes.

Node unprovisioning requirement

Required actions

Health Server subscription list addition

Required actions

Freezing of access layer model configurations

Required actions

AD Type filtering

Required actions

New nRF5 SDK version support

Required actions

Changes to Device State Manager API

Required actions

Updated DFU

Required actions


Migration from v3.0.0 to v3.1.0

Read this migration guide together with the nRF5 SDK for Mesh v3.1.0 release notes.

Table of contents

Example UUIDs updated

Required actions

PB-ADV bearer selection define change

The MESH_PROVISIONEE_BEARER_ADV_ENABLED define has been replaced by MESH_FEATURE_PB_ADV_ENABLED. Setting MESH_FEATURE_PB_ADV_ENABLED=1 (which replaces MESH_PROVISIONEE_BEARER_ADV_ENABLED=1) will no longer cause compilation error.

Required actions

Make sure that your code reflects this change to avoid errors.

Error checking on OOB input data

The interface for providing provisioning authentication data nrf_mesh_prov_auth_data_provide() will now do stricter error checking on OOB input data. This ensures that the inputs are better tested and sanitized.

Required actions

Make sure that your usage of the API is still valid.

Generic Power OnOff API simplified

The API of Generic Power OnOff client initialization has been simplified. The generic_ponoff_client_init function doesn't call generic_onoff_client_init anymore.

Required actions

Manually extend the Generic Power OnOff Client with the Generic OnOff model. To do this, call the generic_onoff_client_init function and share subscription list between Generic OnOff and Generic Power OnOff clients by calling the access_model_subscription_lists_share function.


Migration from v2.2.0 to v3.0.0

Read this migration guide together with the nRF5 SDK for Mesh v3.0.0 release notes.

Table of contents

Added and removed files

The following files have been added in the v3.0.0 release:

The following files have been removed in the v3.0.0 release:

Required actions

Update your projects accordingly to include or remove these files.

IRQ priority level change

The integration with the nRF5 SDK v15.2 caused the following changes:

Required actions

Stack separation on high frequency and low frequency time domains

Stack has been divided into two time frequency domains:

Additionally, app_timer API can be used in an application as-is. However, the SDK app_timer abilities are not sufficient for managing the stack functionality. Extended app_timer with modifications has been added in external/app_timer. Modified version will be compiled and linked to applications (based on stack build system) instead of SDK app_timer. SDK app_timer API header file should be used as well.

Required actions

The following define that turns on app_timer in the building process must be added to app_config.h to make these changes work:

    #define APP_TIMER_ENABLED 1

Initialization and start phase changes

In the initialization phase of the examples, the mesh_softdevice_init module has been replaced with the BLE SoftDevice support module.

In the start phase of the examples, the execution_start() function has been removed.

Required actions

Use the function ble_stack_init() to initialize the SoftDevice Handler and the BLE stack, and to register the Mesh handler for SoC events.

Make sure the function mesh_stack_start() is called at the end of the start phase (see start() function in the Light Switch Server code as an example). After calling mesh_stack_start(), all mesh API interaction must happen at the IRQ priority level specified in the call to mesh_stack_init(). Calling mesh functions at wrong IRQ priority levels after enabling the stack can cause unpredictable behavior (see Setting interrupt priority levels for details).

Only one segmented message from an element to a destination address at a time

The nRF Mesh SDK is now enforcing the Bluetooth Mesh Profile Specification (MshPRFv1.0.1) rule that disallows multiple simulatneous segmented messages from a source address to the same destination.

This change means that models must wait until their previous segmented message is finished sending before they can send another. If multiple models on the same element have the same publish address, they have to coordinate their publishing as well.

If the application attempts to publish two simultaneous segmented messages with the same source and destination, the second publish call gets rejected with error code NRF_ERROR_INVALID_STATE.

Required actions

Models that previously scheduled multiple segmented messages in the same context must instead subscribe to NRF_MESH_EVT_TX_COMPLETE events or set up timers for sending to avoid the error code.

Note
This change only affects segmented messages, that is messages with access_message_tx_t::force_segmented set to true or messages that are longer than NRF_MESH_UNSEG_PAYLOAD_SIZE_MAX. Unsegmented messages can be interleaved with both segmented and unsegmented messages of any source and destination.

Device compile time configuration changes

Compile time configuration for supported features of the device changed, which makes DEVICE_FEATURES, MESH_FEATURE_GATT, GATT_PROXY macros outdated.

Required actions

Make sure you apply the following changes to your code:

New provisioning parameter

There is a new parameter attention_duration_s for the nrf_mesh_prov_provision() function in mesh/prov/api/nrf_mesh_prov.h. This parameter is required in the provisioning process.

Required actions

Update all uses of the nrf_mesh_prov_provision() function with the additional attention_duration_s argument.


Migration from v2.0.1 to v2.2.0

New source files

The following source files have been added in this release:

Core

Models

Removed source files

The following source files have been removed in this release:

Core

Models

Backwards-compatible changes to model API

simple_on_off_client.h
pb_remote_client.h
pb_remote_server.h
health_client.h
config_client.h

Use of the nRF5 SDK's section variables

As of v2.2.0, the nRF5 SDK for Mesh makes use of the nRF5 SDK's section variable module Section variables.

The required changes for supporting section variables are already in place in the example applications, but any user applications carried over from the previous release might require modifications to work correctly, depending on the toolchain used:

Segger Embedded Studio

The Segger Embedded Studio projects base their section placement on the bundled flash_placement.xml file. The example projects in version 2.2.0 contain updated flash_placement files. If you did not do any modifications to this file in your migrated project, you can safely replace the existing flash_placement file with the one in CMake/SES/flash_placement.xml.

If you modified the file, perform the migration manually by adding the following ProgramSection to the FLASH MemorySegment:

<ProgramSection alignment="4" keep="Yes" load="Yes" name=".nrf_mesh_flash" inputsections="*(SORT(.nrf_mesh_flash.*))" address_symbol="__start_nrf_mesh_flash" end_symbol="__stop_nrf_mesh_flash"/>

and the following ProgramSection to the RAM MemorySegment:

<ProgramSection alignment="4" keep="Yes" load="No" name=".nrf_mesh_ram" inputsections="*(SORT(.nrf_mesh_ram.*))" address_symbol="__start_nrf_mesh_ram" end_symbol="__stop_nrf_mesh_ram"/>

Restart Segger Embedded Studio after saving your changes and clean the solution before rebuilding (Build->Clean Solution).

GCC

When building with GCC, the section variables must be registered in the application's linker script so that they end up in the right memory area.

All section variables used by mesh go into two new memory sections (one in RAM and one in flash). These memory sections must be added to the linker script.

The nrf_mesh_ram-section must be added to the sections marked with INSERT AFTER .data:

SECTIONS
{
. = ALIGN(4);
/* ...Any other sections */
.nrf_mesh_ram :
{
PROVIDE(__start_nrf_mesh_ram = .);
KEEP(*(SORT(.nrf_mesh_ram.*)))
PROVIDE(__stop_nrf_mesh_ram = .);
} > RAM
} INSERT AFTER .data

The nrf_mesh_flash-section must be added to the sections marked with INSERT AFTER .text:

SECTIONS
{
. = ALIGN(4);
/* ...Any other sections */
.nrf_mesh_flash :
{
PROVIDE(__start_nrf_mesh_flash = .);
KEEP(*(SORT(.nrf_mesh_flash.*)))
PROVIDE(__stop_nrf_mesh_flash = .);
} > FLASH
} INSERT AFTER .text

ARMCC

When building with ARMCC, no further action is required.

Mesh runtime options

The mesh runtime options API (Mesh options) has been deprecated in favor of Mesh options API. The new API uses the new mesh_config module to store options persistently, so once set, the options do not have to be reset for the lifetime of the device.

The following options have been migrated to the new API:

Old option New option
NRF_MESH_OPT_PROV_ECDH_OFFLOADING mesh_opt_prov_ecdh_offloading_set
NRF_MESH_OPT_NET_RELAY_ENABLE mesh_opt_core_adv_set
NRF_MESH_OPT_NET_RELAY_RETRANSMIT_COUNT mesh_opt_core_adv_set
NRF_MESH_OPT_NET_RELAY_RETRANSMIT_INTERVAL_MS mesh_opt_core_adv_set
NRF_MESH_OPT_NET_RELAY_TX_POWER mesh_opt_core_tx_power_set
NRF_MESH_OPT_NET_NETWORK_TRANSMIT_COUNT mesh_opt_core_adv_set
NRF_MESH_OPT_NET_NETWORK_TRANSMIT_INTERVAL_MS mesh_opt_core_adv_set
NRF_MESH_OPT_NET_NETWORK_TX_POWER mesh_opt_core_tx_power_set

Note that the transport-layer options are still only present on the old nrf_mesh_opt API. They will be migrated in the next release.


Migration from v1.0.1 to v2.0.0

This guide describes the migration process from nRF5 SDK for Mesh version 1.0.1 to version 2.0.0.

Initialization

In v1.0.1, the nrf_mesh_sdk and nrf_mesh_node_config modules could both be used for initializing a mesh device, and they had partly overlapping functionality. They have now been replaced by a single set of non overlapping modules:

The initialization code of the examples has now been restructured into an initialization phase and a start phase, following the same pattern as the nRF5 SDK examples. We strongly advise user applications to do the same. We have also added an execution_start() function to avoid the risk of race conditions during the start phase.

Error handling

Following the same pattern as the nRF5 SDK, weak implementations of app_error_fault_handler (in examples/common/src/app_error_weak.c) and mesh_assertion_handler (in examples/common/src/assertion_handler_weak.c) have been provided. Instead of installing error handlers as callbacks, these functions are now used directly by the nRF5 SDK for Mesh error handling. They can be overloaded by the user application if needed.

nRF5 SDK

Files from the nRF5 SDK are no longer included as part of the nRF5 SDK for Mesh release. Instead, the user is supposed to download the nRF5 SDK separately and provide a link to the nRF5 SDK folder when building the mesh code. See Retrieve nRF SDK for more details.

Non backwards compatible API changes

These are API changes that will break an existing application if ignored.

access.h

access_reliable.h

device_state_manager.h

nrf_mesh.h

nrf_mesh_events.h

nrf_mesh_prov.h

nrf_mesh_prov_events.h

config_client.h:

health_client.h:

simple_on_off_client.h

nrf_mesh_config_app.h

Backwards compatible API changes

These changes are API additions that will not break an existing application if ignored.

device_state_manager.h

nrf_mesh.h

nrf_mesh_events.h

config_client.h:

health_client.h:

simple_on_off_client.h

simple_on_off_server.h

access_config.h


Documentation feedback | Developer Zone | Subscribe | Updated