nRF5 SDK v17.0.0
Migration guide for nrfx drivers

With the transition of peripheral drivers from the SDK to a separate nrfx package, it was necessary to create a new namespace for the drivers and the related configuration settings.

When the nrfx was later integrated as an SDK module, a legacy layer was introduced to perform all the required name translations and cover differences in APIs and functionalities between the old and the new drivers, with the goal to allow the existing applications to use the drivers as before.

Because of these changes, you can either:

Note
The migration process is not required and often results in exactly the same functionality. Consider migration only if you want to take advantage of the new features offered by nrfx.

Continue using nrf_drv drivers

If you want to continue using the nrf_drv drivers, no changes are required. You can use the drivers as before, but without taking advantage of any new functionalities introduced to the nrfx drivers.

The old configuration entries are translated to the new NRFX_* format in the apply_old_config.h file located in integration/nrfx/legacy. In case you continue using the nrf_drv drivers, if you use any of the new NRFX_* entries in your configuration file that also contains old entries, the old entry settings take precedence.

Migrate nrf_drv to nrfx drivers

If you want to start using a new nrfx driver with the SDK to take advantage of its new functionality, you must migrate the driver usage in all occurrences within the source code (application, libraries, etc.) to ensure it works correctly.

The migration process depends on your application and the SDK version:

Note
  • Do not set the old *_ENABLED entry for a particular driver to 0. Doing so is not enough to make the NRFX_* entries work, as the apply_old_config.h file also translates the *_ENABLED macros.
  • When migrating the drivers, make sure you migrate the libraries too. An incomplete migration may cause unspecified behavior of the particular library.
    See Libraries and dependencies for the overview of what must be migrated.
  • An important change between nrf_drv and nrfx drivers is that passing NULL instead of pointing the driver configuration at initialization is no longer supported.
    You must always create a configuration structure and pass the pointer to it to the initialization function.

Migration scenarios

During the migration, three scenarios can occur:

Simple replacement

For most of the drivers, the legacy layer simply translates the nrfx_* names to nrf_drv_*. The following table lists drivers that can be replaced with the nrfx ones.

nrf_drv driver nrfx driver Notes
nrf_drv_comp nrfx_comp
nrf_drv_gpiote nrfx_gpiote
nrf_drv_i2s nrfx_i2s
nrf_drv_lpcomp nrfx_lpcomp
nrf_drv_pdm nrfx_pdm
nrf_drv_ppi nrfx_ppi No init function. Changed to allocator.
nrf_drv_pwm nrfx_pwm
nrf_drv_qdec nrfx_qdec
nrf_drv_qspi nrfx_qspi
nrf_drv_rtc nrfx_rtc
nrf_drv_saadc nrfx_saadc
nrf_drv_swi nrfx_swi No init function. Changed to allocator.
nrf_drv_timer nrfx_timer
nrf_drv_wdt nrfx_wdt

Complex replacement

The SDK included combined drivers for the peripherals with EasyDMA and without. The nrfx uses two separate drivers for these two types of peripherals, respectively:

nrf_drv_ drivernrfx driver (EasyDMA) nrfx driver (no EasyDMA)
nrf_drv_spi nrfx_spim nrfx_spi
nrf_drv_twi nrfx_twim nrfx_twi
nrf_drv_uart nrfx_uarte nrfx_uart

Replace the nrf_drv driver with the nrfx one based on the type of peripheral in use (with EasyDMA or without).

Migration not possible

The following drivers cannot be replaced in SDK by the nrfx ones because of their complex dependencies:

Libraries and dependencies

Only some libraries use the nrf_drv drivers. These libraries are all located in the nrf_drv_* namespace.

The following table shows all the libraries with the dependencies that must be resolved during migration.

Library nrf_drv direct dependencies and notes
atomic -
atomic_fifo -
atomic_flags -
balloc -
block_dev nrf_drv_qspi
bootloader nrf_drv_uart, nrf_drv_clock, nrf_drv_usbd
bsp -
button nrf_drv_gpiote
cli nrf_drv_usbd, nrf_drv_uart
crc16 -
crc32 -
crypto nrf_drv_rng
csense Indirect dependencies from csense_drv
csense_drv nrf_drv_comp, nrf_drv_ppi, nrf_drv_timer, nrf_drv_saadc
delay -
ecc nrf_drv_rng
libuarte Based on nrfx
experimental_log nrf_drv_uart
experimental_section_vars -
experimental_stack_guard -
experimental_task_manager -
fds -
fifo -
fstorage -
gfx -
gpiote nrf_drv_gpiote
hardfault -
hci -
led_softblink -
low_power_pwm -
mem_manager -
memobj -
mpu -
mutex -
pwm nrf_drv_timer, nrf_drv_ppi, nrf_drv_gpiote
pwr_mgmt -
queue -
ringbuf -
scheduler -
sdcard nrf_drv_spi
sensorsim -
serial nrf_drv_uart
sha256 -
simple_timer nrf_drv_timer
slip -
sortlist -
spi_mngr nrf_drv_spi
stack_guard -
stack_info -
strerror -
svc -
timer app_timer uses its own RTC driver implementation
twi_mngr nrf_drv_twi
twi_sensor Indirect dependencies from twi_mngr
uart nrf_drv_uart
usbd nrf_drv_usbd, nrf_drv_clock, nrf_drv_power
util -

Documentation feedback | Developer Zone | Subscribe | Updated