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 and NFC communication on the nRF5340 SoC.
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 nRF Connect SDK provides the following solutions for the network core:
Bluetooth LE Controller (both the SoftDevice Controller and the Zephyr Bluetooth LE Controller)
Samples that directly use the radio peripheral
See Network samples for more information.
In general, this core should be used for real-time processing tasks involving low-level radio protocol layers.
The board name for the network core in Zephyr is
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 nRF5340 support)
See Application samples for more information.
In general, this core should be used for tasks that require high performance and for application-level logic.
The M33 TrustZone divides the application MCU into secure and non-secure domains. When the MCU boots, it always starts executing from the secure area. The secure bootloader chain starts the Secure Partition Manager sample, which configures a part of memory and peripherals to be non-secure and then jumps to the main application located in the non-secure area.
In Zephyr, nRF5340 PDK is divided into two different build targets:
nrf5340pdk_nrf5340_cpuappfor the secure domain
nrf5340pdk_nrf5340_cpuappnsfor the non-secure domain
When built for the
nrf5340pdk_nrf5340_cpuappns board, the Secure Partition Manager sample is automatically included in the build.
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.
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.
To upgrade firmware on the network core, perform the steps for FOTA upgrade described below, replacing
app_update.bin (file used when upgrading firmware on the application core) with
In addition, ensure that
CONFIG_PCD is enabled for the MCUBoot child image.
For more details, see nRF5340: Network core bootloader.
To perform a FOTA upgrade, complete the following steps:
- 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:
img_mgmt_register_group()in your application.
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.
- Create a binary file that contains the new image.
To create a binary file for an application upgrade, make sure that
CONFIG_BOOTLOADER_MCUBOOTis enabled and build the application as usual. The build will create several binary files (see Using MCUboot in nRF Connect SDK). The
app_update.binfile is the file that must be downloaded to the device.
- Download the new image to a device.
To do so, make sure that you can access the
app_update.binfile from your phone or tablet. Then connect to the device with the mobile app and initiate the DFU process to transfer
app_update.binto the device.
There is currently no support for the FOTA process in nRF Connect for Desktop.
nRF5340 samples usually consist of two separate images: one that runs on the network core and one that runs on the application core.
Most samples that support nRF5340 are not dedicated exclusively to this device, but can also be built for other chips that have the radio peripheral (for example, the nRF52 Series). The following subsections give a general overview of what samples can run on nRF5340.
The nRF5340 network core supports samples that directly use the radio peripheral, for example, Radio Test.
For Bluetooth Low Energy, the nRF Connect SDK provides the Bluetooth: HCI RPMsg sample. This Zephyr sample is designed specifically to enable the Bluetooth LE Controller functionality on a remote MCU (for example, the nRF5340 network core) using the RPMsg Messaging Protocol as a transport for Bluetooth HCI. The sample implements the RPMsg transport using the OpenAMP library to communicate with a Bluetooth Host stack that runs on a separate core (for example, the nRF5340 application core).
This sample must be programmed to the network core to run standard Bluetooth Low Energy samples on nRF5340. You can choose whether to use the SoftDevice Controller or the Zephyr Bluetooth LE Controller for this sample. See Bluetooth LE Controller for more information.
You might need to adjust the Kconfig configuration of this sample to make it compatible with the peer application. For example:
CONFIG_BT_MAX_CONNmust be greater than or equal to the maximum number of connections configured for the Bluetooth Host in the application core firmware.
If the application sample uses specific Bluetooth LE functionalities, these functionalities 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.
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.
Additionally, the nRF Connect SDK provides NFC samples that are available for nRF5340. These samples run only on the application core and do not require any firmware for the network core.
When programming any of these samples to the application core, configure
CONFIG_BOARD_ENABLE_CPUNET to select whether the network core should be enabled.
When radio protocols (Bluetooth LE, IEEE 802.15.4) are used, this option is enabled by default.
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 nRF5340, the application core is responsible for starting the network core and connecting its GPIO pins.
Therefore, to run any sample on nRF5340, the application core must be programmed, even if the firmware is supposed to run only on the network core, and the firmware for the application core must set
You can use the nRF5340: Empty firmware for application core sample for this purpose.
For details, see the code in
To program only the application core, follow the instructions in Building with SES and use
nrf5340pdk_nrf5340_cpuappns as build target.
When programming both the application core and the network core, you can choose whether you want to build and program both images separately or combined as a multi-image build.
In a multi-image build, the image for the application core is the parent image, and the image for the network core is treated as a child image in a separate domain. For this to work, the network core image must be explicitly added as a child image to one of the application core images. See Defining and enabling a child image for details.
The network sample Bluetooth: HCI RPMsg is automatically added to all Bluetooth Low Energy samples in the nRF Connect SDK.
CONFIG_BT_RPMSG_NRF53 is set to
y (the default), the build system automatically includes the sample as a child image in the
If the image in the network core is not added to the application core build, you can build and program both samples separately by following the instructions in Building with SES.
Make sure to use
nrf5340pdk_nrf5340_cpunet as build target when building the network sample, and
nrf5340pdk_nrf5340_cpuappns when building the application sample.
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:
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
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.
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