Introducing the RISC-V coprocessor of the nRF54L Series

Sebastian Viviani
Introducing the RISC-V coprocessor of the nRF54L Series

The SoCs of the nRF54L Series combine an efficient MCU with ultra-low-power wireless connectivity. At the heart is a 128 MHz Arm® Cortex®-M33. Next to that heart is also a 128 MHz RISC-V coprocessor, which can be a great way to enhance, boost, or simplify your designs and products.

In this blog post, we will discuss some general aspects of the RISC-V architecture and the implementations, which should help you to better understand its possibilities and how to make the best use of it.

For the rest of the blogpost, we will use the nRF54L15 SoC as leading part, but all concepts should apply to other parts of the nRF54L Series that have a RISC-V coprocessor, like the nRF54LM20A SoC for example

Table of Contents

Some RISC-V background

RISC-V (“risk-five”) is an open standard instruction set architecture (ISA). The architecture has experienced significant growth since its launch in May 2011, thanks to its modular and license-free approach, making it a very attractive option for both hardware vendors and developers.

Although initially created at the University of California, Berkeley, the specifications of the instruction set are available on the RISC-V Foundation website. Nordic Semiconductors is a strategic member of this organization, a global non-profit entity responsible for driving the adoption of the RISC-V ISA.

As the name implies, it follows the Reduced Instruction Set Computer (RISC) principle: this means it is designed with simple individual instructions that perform only one task, in a load/store model. The main goal is to achieve better performance with simple and fast instructions, running in an execution pipeline.

It is called “five” because it is the fifth generation, however, it is not directly related to the previous four iterations produced at the University of Berkeley in the 1980s.

The instruction set is organised in bases and extensions. Vendors can implement different combinations of these, and still call the processor RISC-V, so it’s important to understand what is inside.

Although reduced, the RISC-V instruction set is still quite comprehensive. For practical reasons, we will focus this blogpost in the bases and extensions that are used in the nRF54L Series coprocessor only - but that does not mean there are more options around.

Bases

The base defines a basic instruction set, designed to be sufficient to form a compiler target that supports a modern operating system environment. On top of the instructions, it also defines the number of registers, and their size. The coprocessor of the nRF54L15 uses the RV32E base. This defines a total of 16 32-bit registers, named x0 to x15, and an additional register for the program counter, called pc.

The x0 register is hardwired to the value of 0, and x1 to x15 are general-purpose registers. There is no dedicated stack pointer or subroutine return address link register - the instruction encoding allows any x register to be used for these purposes. RV32E contains 40 unique instructions.

RV32E is a reduced version of the RV32I, adapted for embedded products. As the reader can imagine, the naming convention uses RV for RISC-V, and then a number for the register width - and yes, you probably guessed it, the likes of RV64I and RV64E exist too.

Extensions

RISC-V extensions are groups of instructions that extend the base functionality. The coprocessor of the nRF54L15 implements the C and M extensions on top of the RV32E base.

  • C is for the compressed instruction set. It adds support for short 16-bit encoded instructions, reducing the code size and increasing the execution speed.

  • M is for the multiply&divide instruction set, to perform these operations between registers.

The B extension for bit-manipulation (bitmanip) contains several component extensions that are intended to provide code size reduction, performance improvement, and energy reduction. Each of these smaller extensions are grouped by common function and use case, and are published with its own Zb*-extension name. The RISC-V implementation of the nRF54L15 has a few of them implemented, to cover the basic bit manipulation tasks.

There are three extensions that support floating point instructions (F, D, and Q). The RISC-V coprocessor in the nRF54L15 does not have them implemented, which means it does not have native hardware support for floating-point operations.

The Fast Lightweight Processor

Inside the nRF54L15, the RISC-V coprocessor (base RV32E with M and C extensions) is called Fast Lightweight Processor, or FLPR (a.k.a. flipper). The name comes from the fact the coprocessor can use high speed virtual IOs (which are later routed to physical IO) to achieve performance close to native hardware peripherals.

FLPR runs in parallel to the application CPU, and can also access peripherals and memory, to run threads. Naturally, the concurrency can cause some resource contentions, which need to be considered at the design phase (see upcoming memory layout blogpost). The application CPU is responsible for configuring and starting the FLPR.

It’s important to keep in mind the nRF54L15 has an application CPU (Arm Cortex-M33), and a FLPR (RISC-V coprocessor) - the nRF54L15 does not have a main RISC-V CPU!

The projects that use the FLPR are likely to be multi-image, using sysbuild, with one image for the cpuapp target, and another one for the cpuflpr target. If you haven’t, it might be worth taking the excellent nRF Connect SDK Intermediate course at Nordic Developer Academy, and check out lesson 8 for more info about how this works.

Although the FLPR can execute code from NVM, the recommended scenario is to run the code from SRAM. This means the code for the FLPR must be copied from NVM (where it’s stored as part of the multi-image build) to SRAM during the system bootstrap process, and the FLPR pc should be pointed to the entry point on it, once the copying is finished. This might sound complicated, but the multi-image build will take care of it, so no need to worry about it for now.

What can the FLPR do?

There are two scenarios where the FLPR can unlock a new range of options and possibilities for users of the nRF54L Series:

As a separate, standalone system

The FLPR can work as a separate, standalone system inside the SoC, performing time-sensitive tasks, for example. No matter how hard realtime is the system, or short the hardware interruptions can be, it’s possible for some products to be very sensitive to any kind of interruption (at the wrong time). The Bluetooth LE stack runs in the application CPU, and due to the wireless nature of the SoC, it’s impossible to guarantee no interruption will be happening at that wrong time (yes, they can be temporarily disabled, which brings other side effects)

The only way customers can ensure that will never happen is by performing those time-sensitive tasks in another IC or MCU, on the same PCB. With the associated design and manufacturing cost that adds.

As the FLPR is a separate core, it can be used to integrate those tasks and protect them, while keeping them inside the same SoC - less components, smaller PCBs, without a major design overhauling!

As a SoftPeripheral

The FLPR can also be used to run precompiled binary images, to add software peripherals that are not present in the current nRF54L15 SoC. This can extend the range of applications the SoC can be used, without adding extra cost.

These precompiled binaries will be transparent to the application CPU, which will call the driver APIs, without knowing if it’s using a real hardware peripheral or the FLPR. If the user needs direct access, or simply prefers, the SoftPeripheral APIs can be called directly.

Examples

Let’s explain these use cases with some real-life examples, starting with the SoftPeripherals.

SoftPeripheral binaries are supplied by Nordic Semiconductor, and as of the latest nRF Connect SDK release (at the time of writing, of course), there are two options supported: sQSPI and sEMMC. Both support the nrfx driver API interface, with a special nrf_s naming convention. For sQSPI, the integration with Zephyr will work out of the box.

The GPIOs used are defined in the source code of the FLPR, referenced as vIOs. It’s important not to forget to have them allocated to the FLPR in the main app DTS overlay

The SoftPeripheral use case is likely to be related to situations where you need to extend the capabilities of the nRF54L15, although in an internal way - i.e. might not be directly related to an end feature of your product.

What about a standalone use case? This one has more freedom, as it is entirely up to the developer’s imagination and needs. We used an LED panel in the demo project, but we would have faced a similar scenario for implementing a BLDC motor driving algorithm, for example. Also, if instead of driving outputs, the requirement was to read inputs. Think of smart industrial sensors installed in high-speed production lines that cannot afford to time a signal incorrectly. Or in precision handheld devices, as our customer Reekon shared in their success story.

Closing

The RISC-V coprocessor of the nRF54L15 opens a world of possibilities for existing and new designs. It is a powerful and energy efficient architecture, implemented in a very cost effective way, thanks to the 22 nm process of the nRF54L15.

Naturally the saying “with great power, comes great responsability” also applies. Enabling a second execution unit requires attention to some details, and also creates concurrency scenarios that were not present before. These topics will be covered in future blogposts.

Want to learn more?

We will be hosting a webinar on Thursday 05/Mar/2026, you can subscribe at the Nordic Webinars page

  • Hello!, I have a custom PCB where I have meshed up the spi00 pins by interchanged MISO/MOSI lines. Can RISC-V processor come to rescue? .

  • Hi Jack,
        probably best to create a support ticket for this, as this seems to be something related to sysbuild.

  • Hello! I’m currently looking to use the M33 on the nRF54L15 for range-finding calculations, whilst the RISC-V VPR coprocessor handles some feature processing. I’m currently using NCS v3.2.1, and I’ve built two images. The one below is for the RISC-V VPR coprocessor; here is the CMake file for RISV.

    # uwb_merge/sysbuild.cmake
cmake_minimum_required(VERSION 3.20.0)

ExternalZephyrProject_Add(
    APPLICATION cpuflpr
    SOURCE_DIR  ${APP_DIR}/cpuflpr
    BOARD       nrf54l15dk/nrf54l15/cpuflpr
    BUILD_ONLY  y                          
)

add_dependencies(${DEFAULT_IMAGE} cpuflpr)

    Currently, the PM script continues to add `cpuflpr` to the `--images` list, even though there is no corresponding entry in `partitions.yml`, causing the Python script to crash. (The `BUILD_ONLY y` option does not take effect in the `partition_manager.cmake` file for NCS v3.2.1.) The purpose of `BUILD_ONLY y` is to allow sysbuild to compile this image, but not to hand it over to the Partition Manager for management; instead, cpuapp is responsible for loading it into SRAM and booting it at runtime. Is there a good solution to fix this?

Terms of service