Developing with nRF5340 DK

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

See the nRF5340 DK User Guide for detailed information about the nRF5340 DK hardware. To get started with the nRF5340 DK, follow the steps in Getting started with nRF5340 DK. If you are not familiar with the nRF Connect SDK and its development environment, see Installation and Configuration and building documentation.

Note

The nRF5340 PDK has been deprecated with the introduction of the production-level nRF5340 DK. To determine if you have a PDK or DK, check the version number on the sticker on your kit. If the version is 0.11.0 or higher, the kit is an nRF5340 DK.

See the nRF Connect SDK v1.4.0 documentation for the last release supporting the nRF5340 PDK.

The nRF Connect SDK includes the nRF5340 Audio application, a complete project that integrates the LE Audio standard with custom reference hardware based on the nRF5340 DK. Given its complexity, the application uses custom building and programming procedures. Refer to its documentation for more information.

Introduction

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.

See the nRF5340 Product Specification for more information about the nRF5340 SoC. nRF5340 DK gives an overview of the nRF5340 DK 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. Use this core for radio communication and for real-time processing tasks involving low-level radio protocol layers.

The build target for the network core in Zephyr is nrf5340dk_nrf5340_cpunet.

Application core

The application core is a full-featured Arm Cortex-M33 processor including DSP instructions and FPU. Use this core for tasks that require high performance and for application-level logic.

The M33 TrustZone, one of Cortex-M Security Extensions (CMSE), divides the application MCU into Secure Processing Environment (SPE) and Non-Secure Processing Environment (NSPE). When the MCU boots, it always starts executing from the secure area.

In Zephyr, the firmware of the application core is built using one of the following build targets:

  • nrf5340dk_nrf5340_cpuapp for build targets with CMSE disabled.

  • nrf5340dk_nrf5340_cpuapp_ns for build targets that have CMSE enabled and have the SPE firmware alongside the NSPE firmware.

For information about CMSE and the difference between the two environments, see Processing environments.

Trusted Firmware-M (TF-M)

Trusted Firmware-M provides a configurable set of software components to create a Trusted Execution Environment. It has replaced Secure Partition Manager as the solution used by nRF Connect SDK applications and samples. This means that when you build your application with CMSE enabled, the TF-M is automatically included in the build. It is a framework for functions and use cases beyond the scope of Secure Partition Manager.

For more information about the TF-M, see Running applications with Trusted Firmware-M. See also TF-M Hello World for a sample that demonstrates how to add TF-M to an application.

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.

Execute in place (XIP) configuration

Execute in place (XIP) allows the application core to execute program code directly from the external flash memory device using the Quad Serial Peripheral Interface (QSPI). The external flash memory supports on-the-fly encryption and decryption. For more information, read the Execute in place page in the nRF5340 Product Specification.

For placing individual source code files into defined memory regions, check the Code relocation nocopy sample in Zephyr.

Indication of XIP performance

The XIP code execution performance measurement was conducted to evaluate the expected performance in different operating conditions.

The nRF Machine Learning application running on the nRF5340 DK was used for the testing. This particular application was used because its application design allows to move the Edge Impulse library to external memory. There is only one call to the library from the wrapper module, and therefore this call is used to measure the time of execution. Additional measurements of the current allowed to compare total energy used.

The following table lists performance numbers that were measured under different operating conditions.

Note

The numbers in the table refer to current consumed only by the nRF5340 SoC. For complete numbers, you must add the current used by external flash, which varies between manufacturers.

CPU frequency

Memory

Cache

QSPI speed

Mode

Time [ms]

Current @3.0V [mA]

Current @1.8V [mA]

Total energy @3.0V [µJ]

Total energy @1.8V [µJ]

64 MHz

Internal flash

Yes

n/a

n/a

63

3.2

5.1

605

578

64 MHz

External flash

Yes

48 MHz

Quad

68.9

5.63

8.51

1164

1055

64 MHz

External flash

Yes

24 MHz

Quad

73.7

5.58

8.44

1234

1120

128 MHz

Internal flash

Yes

n/a

n/a

31

7.65

12.24

711

683

128 MHz

External flash

Yes

96 MHz

Quad

34.1

8.99

14.1

920

865

128 MHz

External flash

No

96 MHz

Quad

88.5

9.15

12.95

2429

2063

128 MHz

External flash

Yes

48 MHz

Quad

36.4

8.85

13.9

966

911

Protocols and use cases

nRF5340 samples usually consist of two separate images: one that runs on the network core and one that runs on the application core. For specific use cases, you can use only one of the cores.

The following sections describe the recommended architecture for using different protocols on the nRF5340 and list the provided samples.

Bluetooth Low Energy

Network core

Application core

Bluetooth: HCI RPMsg
Bluetooth Low Energy samples
Bluetooth samples in Zephyr

Bluetooth: Host for nRF RPC Bluetooth Low Energy (supported for development)

Some Bluetooth Low Energy samples, for example, Bluetooth: Peripheral HIDS mouse, Bluetooth: Peripheral UART or Bluetooth: Central UART

When using Bluetooth® Low Energy on the nRF5340, you have two options:

  • Split the Bluetooth LE Controller and the host part of the Bluetooth LE stack and run them on different cores.

  • Run the full Bluetooth LE stack on the network core (currently supported for development only).

Split Controller and Host

When splitting the Bluetooth LE Controller and the Host, run the Bluetooth LE Controller on the network core and the host part of the Bluetooth LE stack and the application logic on the application core.

For the network core, 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 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 (in this case, the nRF5340 application core).

You can use either the SoftDevice Controller or the Zephyr Bluetooth LE Controller for this sample. See Bluetooth LE Controller for more information.

For the application core, the nRF Connect SDK provides a series of Bluetooth Low Energy samples, in addition to the Bluetooth samples in Zephyr. These samples are built for the application core and, by default, include the network core application as child image in a multi-image build (see Multi-image builds).

Note

Most of the provided Bluetooth LE samples should run on the nRF5340 DK, but not all have been thoroughly tested.

Full Bluetooth LE stack

To run the full Bluetooth LE stack on the network core, the nRF Connect SDK provides the Bluetooth: Host for nRF RPC Bluetooth Low Energy sample.

Note

The Bluetooth: Host for nRF RPC Bluetooth Low Energy sample is currently supported for development only. It does not support all Bluetooth Host APIs yet.

For the application core, use a compatible Bluetooth LE sample, for example, the Bluetooth: Peripheral HIDS mouse, Bluetooth: Peripheral UART or Bluetooth: Central UART sample.

Bluetooth mesh

Bluetooth mesh operates on Bluetooth Low Energy (LE), and is implemented according to Bluetooth Mesh Profile Specification v1.0.1 and Bluetooth Mesh Model Specification v1.0.1. For the application core, the nRF Connect SDK provides several Bluetooth mesh samples. In addition, you can find Bluetooth mesh samples with Bluetooth samples in Zephyr.

IEEE 802.15.4 (Thread and Zigbee)

Network core

Application core

nRF IEEE 802.15.4: Serialization RPMsg
Thread samples
Zigbee samples
Matter samples

When using IEEE 802.15.4 on the nRF5340, run the IEEE 802.15.4 radio driver on the network core and the high-level radio stack (the host part of the Thread and Zigbee stacks) and the application logic on the application core.

IEEE 802.15.4 Protocol architecture in multicore SoC

IEEE 802.15.4 Protocol architecture in multicore SoC

For the network core, the nRF Connect SDK provides the nRF IEEE 802.15.4: Serialization RPMsg sample. This Zephyr sample is designed specifically to enable the nRF IEEE 802.15.4 radio driver and its serialization library on a remote MCU using the RPMsg Messaging Protocol as a transport for the nRF 802.15.4 radio driver serialization. The sample implements the RPMsg transport using the OpenAMP library to communicate with the nRF IEEE 802.15.4 radio driver serialization host that runs on a separate core (in this case, the nRF5340 application core).

For the application core, the nRF Connect SDK provides a series of samples for the Thread, Zigbee, and Matter protocols. These samples are built for the application core and, by default, include the network core application as child image in a multi-image build (see Multi-image builds).

Multiprotocol (Thread or Zigbee in combination with Bluetooth LE)

Network core

Application core

nRF5340: Multiprotocol RPMsg
Thread samples
Zigbee samples

nRF5340 supports running another protocol in parallel with the SoftDevice Controller. When using Thread or Zigbee in parallel with Bluetooth LE, run the low-level radio protocol layers (thus the IEEE 802.15.4 radio driver and the Bluetooth LE Controller) on the network core and the high-level radio stack (the host part of the Bluetooth LE, Thread, and Zigbee stacks) and the application logic on the application core.

Bluetooth LE and IEEE 802.15.4 multiprotocol architecture in multicore SoC

Bluetooth LE and IEEE 802.15.4 multiprotocol architecture in multicore SoC

For the network core, the nRF Connect SDK provides the nRF5340: Multiprotocol RPMsg sample. It is a combination of the Bluetooth: HCI RPMsg sample (for Bluetooth LE) and the nRF IEEE 802.15.4: Serialization RPMsg sample (for IEEE 802.15.4). This means that it enables both the Bluetooth LE Controller and the nRF IEEE 802.15.4 radio driver and simultaneously exposes the functionality of both stacks to the application core using the RPMsg Messaging Protocol. Separate RPMsg endpoints are used to obtain independent inter-core connections for each stack.

For the application core, the nRF Connect SDK provides a series of samples for the Thread and Zigbee protocols. These samples are built for the application core and, by default, include the network core application as child image in a multi-image build (see Multi-image builds). See the Multiprotocol support user guide for instructions on how to enable multiprotocol support for Thread or Zigbee in combination with Bluetooth.

Direct use of the radio peripheral

Network core

Application core
Bluetooth: Direct Test Mode
Radio test (short-range)
MPSL timeslot

nRF5340: Empty firmware for application core

Note

The above list might not be exhaustive.

Samples that directly use the radio peripheral can run on the network core of the nRF5340. They do not require any functionality from the application core.

However, on nRF5340, the application core is responsible for starting the network core and connecting its GPIO pins (see CONFIG_BOARD_ENABLE_CPUNET and the code in zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpunet_reset.c). Therefore, you must always program the application core, even if the firmware is supposed to run only on the network core.

You can use the nRF5340: Empty firmware for application core sample for this purpose. Configure the network core application to automatically include this sample as a child image. This is the default configuration for the listed network core samples. For more information, see CONFIG_NCS_SAMPLE_EMPTY_APP_CORE_CHILD_IMAGE and Multi-image builds.

No radio communication

Network core

Application core

—
NFC samples
Crypto samples
TF-M Hello World
Low Power UART

Note

The above list might not be exhaustive.

Samples that do not need radio communication can run on the application core of the nRF5340. They do not require any firmware on the network core. Therefore, the network core can remain empty.

If you want to enable the network core anyway, set the CONFIG_BOARD_ENABLE_CPUNET option in the image for the application core.

Multi-image builds

If a sample consists of several images (in this case, different images for the application core and for the network core), you can build these images separately or combined as a multi-image build, depending on the sample configuration.

In a multi-image build, the image for the application core is usually 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.

Note

When using the nRF5340: Empty firmware for application core sample, the image hierarchy is inverted. In this case, the network core image is the parent image and the application core image is the child image.

Default build configuration

By default, the two images are built together for all Bluetooth LE, Thread, Zigbee, and Matter samples in the nRF Connect SDK. Samples that are designed to run only on the network core include the nRF5340: Empty firmware for application core sample as a child image. For other samples, the images are built separately.

The build configuration depends on the following Kconfig options that must be set in the configuration of the parent image:

The combination of these options determines which (if any) sample is included in the build of the parent image:

Enabled options

Child image sample for the network core

Child image sample for the application core

CONFIG_BT_RPMSG

Bluetooth: HCI RPMsg

—

CONFIG_NRF_802154_SER_HOST

nRF IEEE 802.15.4: Serialization RPMsg

—

CONFIG_BT_RPMSG and CONFIG_NRF_802154_SER_HOST

nRF5340: Multiprotocol RPMsg

—

CONFIG_NCS_SAMPLE_EMPTY_APP_CORE_CHILD_IMAGE

—

nRF5340: Empty firmware for application core

Configuration of the child image

When a network sample is built automatically as a child image in a multi-image build, you can define the relevant Kconfig options (if required) in a .conf file. Name the file network_sample*.conf, where network_sample is the name of the child image (for example, hci_rpmsg.conf). Place the file in a child_image subfolder of the application sample directory. See Image-specific variables for more information.

This way of defining the Kconfig options allows to align the configurations of both images.

For example, see the Bluetooth: Throughput child image configuration in nrf/samples/bluetooth/throughput/child_image/hci_rpmsg.conf.

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.

The steps differ depending on whether you work with Visual Studio Code or on the command line and whether you are doing a single or multi-image build.

Using Visual Studio Code

You can build and program separate images or combined images using the nRF Connect for VS Code extension.

Separate images

To build and program the application core, follow the instructions in How to build an application and use nrf5340dk_nrf5340_cpuapp or nrf5340dk_nrf5340_cpuapp_ns as the build target.

To build and program the network core, follow the instructions in How to build an application and use nrf5340dk_nrf5340_cpunet as the build target.

Multi-image build

If you are working with Bluetooth LE, Thread, Zigbee, or Matter samples, the network core sample is built as a child image when you build the application core image (see Multi-image builds above).

Complete the following steps to build and program a multi-image build to the nRF5340 application core and network core:

  1. Open Visual Studio Code.

    If you installed the nRF Connect SDK using the Installing automatically steps, you can click the Open VS Code button next to the version you installed.

  2. Complete the steps listed on the How to build an application page in the nRF Connect for VS Code extension documentation.

  1. Program the sample or application:

    1. Connect the nRF5340 development kit to your PC using a USB cable.

    2. Make sure that the nRF5340 DK and the external debug probe are powered on.

    3. Click Build in the Actions View to start the build process.

    4. Click Flash in the Actions View to program the resulting image to your device.

Using the command line

To build nRF5340 samples from the command line, use west. To program the nRF5340 DK from the command line, use either west or nrfjprog (which is part of the nRF Command Line Tools).

Note

Programming the nRF5340 DK from the command line (with west or nrfjprog) requires the nRF Command Line Tools v10.12.0 or later.

Separate images

To build and program the application sample and the network sample as separate images, follow the instructions in Building on the command line for each of the samples.

See the following instructions for programming the images separately:

  1. Open a command prompt in the build folder of the network sample and enter the following command to erase the flash memory of the network core and program the network sample:

    west flash --erase

  2. Navigate to the build folder of the application sample and enter the same command to erase the flash memory of the application core and program the application sample:

    west flash --erase

See Readback protection if you encounter an error.

Multi-image build

To build and program a multi-image HEX file, follow the instructions in Building on the command line for the application core sample.

To program the multi-image HEX file, you can use west or nrfjprog.

Enter the following command to program multi-image builds for different cores:

west flash

Readback protection

When programming the device, you might get an error similar to the following message:

ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

This error occurs when readback protection is enabled. To disable the readback protection, you must recover your device. See the following instructions.

Enter the following command to recover both cores:

west flash --recover

FOTA updates

You can update the firmware of the device over the air, thus without a wired connection. Such an update is called a FOTA (firmware over-the-air) update. You can also use FOTA updates to replace the application.

Note

For the possibility of introducing an upgradable bootloader, refer to Adding a bootloader chain.

FOTA over Bluetooth Low Energy

FOTA updates are supported using MCUmgr’s Simple Management Protocol (SMP) over Bluetooth. The application acts as a GATT server and allows the connected Bluetooth Central device to perform a firmware update. To use FOTA over Bluetooth LE, samples must support Bluetooth peripheral role (CONFIG_BT_PERIPHERAL).

The application supports SMP handlers related to:

  • Image management.

  • Operating System (OS) management used to reboot the device after the firmware upload is complete.

  • Erasing settings partition used to ensure that a new application is not booted with incompatible content in the settings partition written by the previous application.

To enable support for FOTA updates, do the following:

  • Enable the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU Kconfig option, which implies configuration of the following:

    • All of the SMP command handlers mentioned in the previous paragraph.

    • SMP BT reassembly feature.

    • The CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP Kconfig option automatically extends the Bluetooth buffers, which allows to speed up the FOTA transfer over Bluetooth, but also increases RAM usage.

Bluetooth buffers configuration introduced by the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP Kconfig option is also automatically applied to the network core child image by the dedicated overlay file.

If necessary, you can modify any of the implied options or defaulted values introduced by the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU Kconfig option.

You can either add these Kconfig options to the configuration files of your application or have them inline in a project build command. Here is an example of how you can build for the Bluetooth: Peripheral LBS sample:

 west build -b build_target -- -DCONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

When you connect to the device after the build has completed and the firmware has been programmed to it, the SMP Service is enabled with the UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84. If you want to add SMP Service to advertising data, refer to the SMP Server Sample.

Testing steps

To perform a FOTA update, complete the following steps:

  1. Generate the DFU package by building your application with the FOTA support over Bluetooth Low Energy. You can find the generated dfu_application.zip archive in the following directory <build_dir>/zephyr.

    Note

    For each image included in the DFU-generated package, use a higher version number than your currently active firmware. Otherwise, the DFU target may reject the FOTA process due to a downgrade prevention mechanism.

  2. Download the dfu_application.zip archive to your device. See Building FOTA images for more information about the contents of update archive.

    Note

    nRF Connect for Desktop does not currently support the FOTA process.

  3. Use the nRF Connect Device Manager mobile app to update your device with the new firmware.

    1. Ensure that you can access the dfu_application.zip archive from your phone or tablet.

    2. In the mobile app, scan and select the device to update.

    3. Switch to the Image tab.

    4. Tap the SELECT FILE button and select the dfu_application.zip archive.

    5. Tap the START button.

    6. Initiate the DFU process of transferring the image to the device:

      • If you are using an Android device, select a mode in the dialog window, and tap the START button.

      • If you are using an iOS device, tap the selected mode in the pop-up window.

    7. Wait for the DFU to finish and then verify that the application works properly.

FOTA update sample

The SMP Server Sample demonstrates how to set up your project to support FOTA updates.

The sample documentation is from the Zephyr project and is incompatible with the Multi-image builds. When working in the nRF Connect SDK environment, ignore the part of the sample documentation that describes the building and programming steps. In nRF Connect SDK, you can build and program the SMP Server Sample as any other sample using the following commands:

 west build -b build_target -- -DOVERLAY_CONFIG=overlay-bt.conf
 west flash

Make sure to indicate the overlay-bt.conf overlay configuration for the Bluetooth transport like in the command example. This configuration was carefully selected to achieve the maximum possible throughput of the FOTA update transport over Bluetooth with the help of the following features:

Consider using these features in your project to speed up the FOTA update process.

FOTA in Bluetooth mesh

When performing a FOTA update when working with the Bluetooth mesh protocol, use one of the following DFU methods:

  • DFU over Bluetooth mesh using the Zephyr Bluetooth mesh DFU subsystem. The specification that the Bluetooth mesh DFU subsystem is based on is not adopted yet, and therefore this feature should be used for experimental purposes only.

  • Point-to-point DFU over Bluetooth Low Energy as described in FOTA over Bluetooth Low Energy above.

For more information about both methods, see Performing Device Firmware Updates (DFU) in Bluetooth mesh.

Note

Point-to-point DFU over Bluetooth Low Energy is supported by default, out-of-the-box, for all samples and applications compatible with Thingy:53. See Updating firmware image for more information about updating firmware image on Thingy:53.

FOTA in Matter

To perform a FOTA upgrade when working with the Matter protocol, use one of the following methods:

  • DFU over Bluetooth LE using either smartphone or PC command-line tool. Both options are similar to FOTA over Bluetooth Low Energy.

    Note

    This protocol is not part of the Matter specification.

  • DFU over Matter using Matter-compliant BDX protocol and Matter OTA Provider device. This option requires an OpenThread Border Router (OTBR) set up either in Docker or on a Raspberry Pi.

For more information about both methods, read the Performing Device Firmware Upgrade in the nRF Connect examples page in the Matter documentation.

FOTA over Thread

Thread does not offer a proprietary FOTA method.

FOTA over Zigbee

You can enable support for FOTA over the Zigbee network using the Zigbee FOTA library. For detailed information about how to configure the Zigbee FOTA library for your application, see Configuring Zigbee FOTA.

Simultaneous multi-image DFU

The simultaneous update of multiple images is available for testing since nRF Connect SDK v1.7.0. It allows the updating of both the application core and the network core in one go.

To enable the simultaneous update of multiple images in the MCUboot, set the following options:

  • CONFIG_BOOT_UPGRADE_ONLY - The simultaneous update of multiple images does not support network core image reversion, so you need to disable application image reversion.

  • CONFIG_PCD_APP - Enable commands exchange with the network core.

  • CONFIG_UPDATEABLE_IMAGE_NUMBER - Enable support for multiple update partitions by setting this option to 2.

Note

The application core can be reverted, but doing so bricks the network core upon revertion, as the reversion process fills the network core with the content currently in the RAM that pcd uses. To enable this, define the USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY Kconfig option in the project-level Kconfig file. When this is option is defined, you can enable it by setting :kconfig:option`CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY`.

The CONFIG_NRF53_MULTI_IMAGE_UPDATE option selects this feature by default if these options and all its other dependencies are asserted.

To enable the simultaneous update of multiple images in the application, in addition to enabling the MCUboot support, set the following options:

Additionally, the memory partitions must be defined and include:

  • mcuboot_primary and mcuboot_secondary partitions for the application core image slots.

  • mcuboot_primary_1 and mcuboot_secondary_1 partitions for the network core image slots.

  • pcd_sram partition used for command exchange between the application core and the network core (see CONFIG_PCD_APP).

Note

The application core does not have direct access to the network core flash memory. The update image is passed indirectly using RAM. Because of this, the mcuboot_primary_1 must be stored in ram_flash region. To enable providing such region on the device, see CONFIG_FLASH_SIMULATOR.

Samples and applications built for Thingy:53 enable simultaneous update of multiple images by default. To learn more about Thingy:53, see Developing with Thingy:53.

MCUboot’s serial recovery of the networking core image

In addition to the recovery of the application core image, also the networking core image can be recovered. When you build MCUboot for the nRF5340 DK or the Thingy:53, you can use this feature with one of the following options:

  • CONFIG_NRF53_MULTI_IMAGE_UPDATE - Simultaneous multi-image DFU.

  • CONFIG_NRF53_RECOVERY_NETWORK_CORE - Serial recovery for the network core in the one image pair mode, where CONFIG_UPDATEABLE_IMAGE_NUMBER is set to == 1.

To upload the networking image, use the following command:

./mcumgr image upload <build_dir_path>/zephyr/net_core_app_update.bin -e -n 3 -c serial_conn

serial_conn is the serial connection configuration. For more information on MCUmgr image management, see Image Management

To enable the serial recovery of the network core while the multi-image update is not enabled in the MCUboot, set the following options:

Additionally, define and include the following memory partitions:

  • mcuboot_primary and mcuboot_secondary - Partitions for the application core image slots.

  • mcuboot_primary_1 - Partition for the network core image slot.

  • pcd_sram - Partition used for command exchange between the application core and the network core (see CONFIG_PCD_APP).

Note

When using MCUboot with the CONFIG_NRF53_RECOVERY_NETWORK_CORE option enabled, the application core does not have direct access to the network core flash memory. Due to this, mcuboot_primary_1 must be used as the RAM partition mediator.

Container for firmware update binaries

The build system will automatically place both the application core and the network core update binaries (app_update.bin and net_core_app_update.bin) into a container package named dfu_application.zip. This container package can be used by update tools to pass both images during the simultaneous update of multiple images.

Debugging

See Debugging an application for information about how to debug your application.

Getting logging output

When connected to a computer, the nRF5340 DK emulates virtual COM ports. The number of COM ports depends on the DK version you are using.

nRF5340 DK v2.0.0 COM ports

When connected to a computer, the nRF5340 DK v2.0.0 emulates two virtual COM ports. In the default configuration, they are set up as follows:

  • The first COM port outputs the log from the network core (if available).

  • The second COM port outputs the log from the application core.

nRF5340 DK v1.0.0 COM ports

When connected to a computer, the nRF5340 DK v1.0.0 emulates three virtual COM ports. In the default configuration, they are set up as follows:

  • The first COM port outputs the log from the network core (if available).

  • The second (middle) COM port is routed to the P24 connector of the nRF5340 DK.

  • The third (last) COM port outputs the log from the application core.

To use the middle COM port in the nRF5340 DK v1.0.0, complete the following steps:

  1. Map RX, TX, CTS and RTS pins to four different pins on the development kit, using, for example, devicetree overlays. See the following example, using the nordic,nrf-uarte bindings.

    &pinctrl {
   uart0_default_alt: uart0_default_alt {
      group1 {
         psels = <NRF_PSEL(UART_TX, 0, 20)>,
                 <NRF_PSEL(UART_RX, 0, 21)>,
                 <NRF_PSEL(UART_RTS, 0, 18)>,
                 <NRF_PSEL(UART_CTS, 0, 16)>;
      };
   };

   uart0_sleep_alt: uart0_sleep_alt {
      group1 {
         psels = <NRF_PSEL(UART_TX, 0, 20)>,
                 <NRF_PSEL(UART_RX, 0, 21)>,
                 <NRF_PSEL(UART_RTS, 0, 18)>,
                 <NRF_PSEL(UART_CTS, 0, 16)>;
         low-power-enable;
      };
   };
};

&uart0 {
   status = "okay";
   compatible = "nordic,nrf-uarte";
   current-speed = <115200>;
   pinctrl-0 = <&uart0_default_alt>;
   pinctrl-1 = <&uart0_sleep_alt>;
   pinctrl-names = "default", "sleep";
};

  2. Wire the previously mapped pins to TxD, RxD, CTS, and RTS on the P24 connector.