Working with nRF5340

The nRF Connect SDK provides support for developing on the nRF5340 System on Chip (SoC) using the nRF5340 PDK (PCA10095).


nRF5340 is a wireless ultra-low power multicore System on Chip (SoC) with two fully programmable Arm Cortex-M33 processors: a network core and an application core. The nRF Connect SDK supports Bluetooth Low Energy communication on the nRF5340 SoC.

See the nRF5340 Product Specification for more information about the nRF5340 SoC. nRF5340 PDK gives an overview of the nRF5340 PDK support in Zephyr.

Network core

The network core is an Arm Cortex-M33 processor with a reduced feature set, designed for ultra-low power operation.

This core is used for radio communication. With regards to the nRF5340 samples, this means that the network core runs the radio stack and real-time procedures. Currently, the following solutions are available for the network core:

  • Bluetooth Low Energy Controller - compatible with several BLE samples. Both the BLE Controller from Zephyr and nRF Bluetooth LE Controller are supported.

  • The Radio Test sample that runs only on the network core and is used for testing the Radio peripheral. To start the network core, this sample requires any sample programmed on the application core. For example, you can use nRF5340: Empty firmware for application core for this purpose.

In general, this core should be used for real-time processing tasks involving low-level protocols and layers.

The board name for the network core in Zephyr is nrf5340pdk_nrf5340_cpunet.

Application core

The application core is a full-featured Arm Cortex-M33 processor including DSP instructions and FPU.

Currently, the nRF Connect SDK provides the following solutions for the application core:

  • high-level radio stack (the host part of the Bluetooth Low Energy stack) and application logic,

  • samples running only on the application core (for example, NFC samples with nRF53 support).

In general, this core should be used for tasks that require high performance and application-level logic.

The board name for the application core in Zephyr is nrf5340pdk_nrf5340_cpuapp.

The user application can run in the secure or non-secure domain. Therefore, it can be built for two different board targets:

  • nrf5340pdk_nrf5340_cpuapp for the secure domain,

  • nrf5340pdk_nrf5340_cpuappns for the non-secure domain.

When built for the nrf5340pdk_nrf5340_cpuappns board, the Secure Partition Manager is automatically included in the build.

Inter-core communication

Communication between the application core and the network core happens through a shared memory area. The application core memory is mapped to the network core memory map. This means that the network core can access and use the application core memory for shared memory communication.

Interprocessor Communication (IPC) is used to indicate to the other core that there is new data available to pick up. The actual data exchange is handled by Open Asymmetric Multi Processing (OpenAMP).

Zephyr includes the OpenAMP library, which provides a complete solution for exchanging messages between the cores. The IPC peripheral is presented to Zephyr as an Interprocessor Mailbox (IPM) device. The OpenAMP library uses the IPM SHIM layer, which in turn uses the IPC driver in nrfx.

FOTA upgrades

You can upgrade the firmware of the device over the air, thus without a wired connection. Such an upgrade is called a FOTA (firmware over-the-air) upgrade. FOTA upgrades can be used to replace the application.


It is currently only possible to upgrade the firmware on the application core. Also, there is currently no support for upgrading the bootloader (MCUboot) on the nRF5430.

To perform a FOTA upgrade, complete the following steps:

  1. Make sure that your application supports FOTA upgrades.

    To download and apply FOTA upgrades, the following requirements apply:

    • You must enable the mcumgr module, which handles the transport protocol over Bluetooth Low Energy. To enable this module in your application, complete the following steps:


      2. Call os_mgmt_register_group() and img_mgmt_register_group() in your application.

      3. Call smp_bt_register() in your application to initialize the mcumgr Bluetooth Low Energy transport.

      See the code of the SMP Server Sample for an implementation example. After completing these steps, your application should advertise the SMP Service with UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84.

    • To upgrade the application, you must use MCUboot as the upgradable bootloader (CONFIG_BOOTLOADER_MCUBOOT must be enabled).

  2. Create a binary file that contains the new image.

    To create a binary file for an application upgrade, make sure that CONFIG_BOOTLOADER_MCUBOOT is enabled and build the application as usual. The build will create several binary files (see Using MCUboot in nRF Connect SDK). The app_update.bin file is the file that must be downloaded to the device.

  3. Download the new image to a device.

    Use nRF Connect for Mobile or nRF Toolbox to upgrade your device with the new firmware.

    To do so, make sure that you can access the app_update.bin file from your phone or tablet. Then connect to the device with the mobile app and initiate the DFU process to transfer app_update.bin to the device.


    There is currently no support for the FOTA process in nRF Connect for Desktop.

Available samples

nRF5340 samples consist of two separate images: one that runs on the network core and one that runs on the application core.

Network samples

The nRF Connect SDK provides the following samples for the nRF53 network core:

  • Bluetooth: HCI RPMsg - a Zephyr sample that implements a Bluetooth Low Energy controller. This sample must be programmed to the network core to run standard Bluetooth Low Energy samples on nRF5340.

    You might need to adjust the Kconfig configuration of this sample to make it compatible with the peer application. For example:

    • CONFIG_BT_MAX_CONN must be equal to the maximum number of connections supported by the application sample.

    • If the application sample uses a specific Bluetooth LE functionality, this functionality must be enabled in the network sample as well. For example, you must modify the configuration of the network sample to make it compatible with the Bluetooth: Throughput sample:


      This configuration guarantees that the network sample can handle the Bluetooth LE DLE update procedure, which is used in the Bluetooth: Throughput sample.

  • Radio Test - an sample application used for testing available modes of the Radio peripheral.

Application samples

The nRF Connect SDK provides a series of Bluetooth Low Energy samples, in addition to the Bluetooth samples in Zephyr. Most of these samples should run on the nRF5340 PDK, but not all have been thoroughly tested. Samples that use non-standard features of the Bluetooth Low Energy controller, like the Bluetooth: LLPM sample, are not supported. Additionally, the nRF Connect SDK NFC samples are also available for nRF53 - they run only on the application core and do not require any firmware for the network core.

Some samples require configuration adjustments to the Bluetooth: HCI RPMsg sample as described in the Network samples section.

These samples must be programmed to the application core, in the secure domain.

Building and programming a sample

Depending on the sample, you must program only the application core (for example, when using NFC samples) or both the network and the application core.


On nRF53, the application core is responsible for starting the network core and connecting its GPIO pins. Therefore, to run any sample on nRF53, the application core must be programmed, even if the firmware is supposed to run only on the network core. You can use the Hello World sample for this purpose. For details, see the code in zephyr/boards/arm/nrf5340pdk_nrf5340/nrf5340_cpunet_reset.c.

Build and program both samples separately by following the instructions in Building with SES. Make sure to use nrf5340pdk_nrf5340_cpunet as board name when building the network sample, and nrf5340pdk_nrf5340_cpuapp when building the application sample.

Programming from the command line

To program a HEX file after building it with SEGGER Embedded Studio, open a command prompt in the build folder of the sample that you want to program and enter the following command:

west flash

If you prefer to use nrfjprog (which is part of the nRF Command Line Tools) instead, open a command prompt in the build folder of the network sample and enter the following commands to program the network sample:

nrfjprog -f NRF53 --coprocessor CP_NETWORK --eraseall
nrfjprog -f NRF53 --coprocessor CP_NETWORK --program zephyr/zephyr.hex

Then navigate to the build folder of the application sample and enter the following commands to program the application sample and reset the board:

nrfjprog -f NRF53 --eraseall
nrfjprog -f NRF53 --program zephyr/zephyr.hex

nrfjprog --pinreset

Getting logging output

When connected to the computer, the nRF5340 PDK emulates three virtual COM ports. In the default configuration, logging output of the application core sample is available on the third (last) COM port. The first two COM ports are silent.

Logging output on the network core

In the default configuration, you cannot access the logging output of the network core sample.

To get logging output on the second COM port, you must connect certain pins on the nRF5340 PDK. The following table lists which pins must be shorted:

1st connection point

2nd connection point





If you use flow control, you must also connect the RTS and CTS line as described in the next table:

1st connection point

2nd connection point