# Coexistence with other Nordic SDKs

## nRF5 SDK integration

One way to utilize the Nordic nRF5 SDK projects with the mesh stack is to move the mesh stack repository into the Nordic nRF5 SDK examples folder and include the necessary source files in the desired Nordic nRF5 SDK project. The necessary changes needed are:
 - Add all `core`, `prov`, `access`, `dfu`, `nrf_mesh_weak.c`, relevant `model` and `example` files, and (if used) `serial` files, and their include paths to the Nordic nRF5 SDK project.
 - Remove all functions but `mesh_assert_handler` and `sleep_forever` from the `nrf_mesh_sdk` module if the Nordic nRF5 SDK application already uses the SoftDevice as they duplicate existing handlers in the Nordic nRF5 SDK.
 - Define `NRF_MESH_LOG_ENABLE` to be ` NRF_LOG_USES_RTT` in `nrf_mesh_config_core.h`, since the logging in the mesh stack relies on RTT.
 - Examples using the module `simple_hal` in the mesh stack may need to be updated to use the Nordic nRF5 SDK module `bsp`. It is possible to use both, in which case `GPIOTE_IRQHandler` needs to be removed from one of the files, and registration of callback functions made by only one of the modules.
 - If the Nordic nRF5 SDK uses the SoftDevice, make sure that the mesh stack is initialized and enabled after the SoftDevice is enabled. SoftDevice events also need to be forwarded to the mesh stack. See *SoftDevice events* section for more information.
    - If `intern_softdevice_events_execute` in `softdevice_handler.c` is used for processing the SoftDevice events (in most Nordic nRF5 SDK applications this is the case), then include `nrf_mesh.h` in `softdevice_handler.c`, and call `nrf_mesh_on_sd_evt(evt_id)` and `nrf_mesh_on_ble_evt((ble_evt_t*) mp_ble_evt_buffer)` from `intern_softdevice_events_execute` when `sd_evt_get` and `sd_ble_evt_get` return success.
 - Flash storage of network configuration is enabled by default in the mesh stack as well as in some of the Nordic nRF5 SDK applications. The flash areas used for this purpose may overlap and cause errors. In order to allow safe coexistence of flash storage module @ref FLASH_MANAGER in the mesh stack and the Nordic nRF5 SDK flash storage module `fstorage` add the code block below to `nrf_mesh_config_core.h`:
```
#include "fds.h"
#include "fds_internal_defs.h"
#include "section_vars.h"
#include "fstorage.h"
#include "fstorage_internal_defs.h"

#define FLASH_MANAGER_RECOVERY_PAGE ((uint32_t) FS_PAGE_END_ADDR - (FDS_PHY_PAGES + 1) * PAGE_SIZE)
```

If no particular Nordic nRF5 SDK example is used, but instead some of the Nordic nRF5 SDK modules are desired to be used then it may be simpler to move the desired Nordic nRF5 SDK modules into the mesh stack repository and create an example project using one of the methods provided by the mesh stack repository.

### Nordic nRF5 SDK NVM storage modules
Use of Nordic nRF5 SDK modules (such as `fstorage`, `pstorage` and `ble_flash`) for writing to flash  may be problematic due to long `timeslot` events occupied by the mesh stack. Use of the @ref FLASH_MANAGER  module provided by the mesh stack is recommended instead.

Furthermore, when writing to flash the users should be aware of not writing or erasing areas utilized by the mesh stack modules and the bootloader (if present). By default, the mesh modules utilize the last `x` number of pages before the start of the bootloader, if present, or the last `x` number of pages of the available flash on the Nordic SOC. The value of `x` depends on the configuration of the mesh stack, and can be calculated by:
`x = 1 + ACCESS_FLASH_PAGE_COUNT + DSM_FLASH_PAGE_COUNT + NET_FLASH_PAGE_COUNT`

## SoftDevice
### SoftDevice events
The mesh stack relies on receiving the events generated by the SoftDevice for proper functioning. The SoftDevice may generate events relevant only to the application, only to the mesh stack, or both for application and the mesh stack. Therefore it is important that the SoftDevice events reported via `SD_EVT_IRQHandler` and extracted via `sd_evt_get` and `sd_ble_evt_get` are processed by the mesh stack as well as the relevant application handlers.

The mesh stack implements its own `SD_EVT_IRQHandler` in `nrf_mesh_sdk`, while the Nordic nRF5 SDK implements the same handler in softdevice_handler.c as `SOFTDEVICE_EVT_IRQHandler`. It is advisable to disable the `SD_EVT_IRQHandler` in `nrf_mesh_sdk` (i.e. remove by deleting or commenting out), and first call `nrf_mesh_on_sd_evt` and `nrf_mesh_on_ble_evt` for every softdevice event received within the event processing function called by the `SOFTDEVICE_EVT_IRQHandler`, which is `intern_softdevice_events_execute` in  `nrf_mesh_sdk` in most Nordic nRF5 SDK applications.

### Concurrent SoftDevice and mesh activity
By design the SoftDevice activity is prioritized over mesh activity, thus it is recommended that the connection and advertisement intervals used by the SoftDevice are kept as large as possible (i.e. infrequent) when using BLE connections, and if scanning the scan duty cycle kept as low as possible. It is recommended that mesh activity is reduced while the SoftDevice is doing fast advertising and continue normal activity once a connection is established.
