Blogs - All Comments

RE: Introducing the RISC-V coprocessor of the nRF54L Series

Sebastian Viviani — Wed, 01 Apr 2026 22:18:38 GMT

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

RE: Meet the Axon NPU: Accelerating Edge AI on the nRF54L Series

StevenBos — Sat, 28 Mar 2026 01:17:01 GMT

Will LiteRT support also come to non-NPU models like the nRF54L15? If so, when can this be expected? Robin M Saltnes

RE: Introducing the RISC-V coprocessor of the nRF54L Series

Jack jpeng — Thu, 26 Mar 2026 09:26:56 GMT

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?

RE: Implementing MQTT over Wi-Fi on the nRF7002 Development Kit

SulikS — Fri, 20 Mar 2026 17:35:41 GMT

Hi guys,
Could somebody please provide the information about the power consumption for this example? Perhaps somebody can measure it with the power profiler kit?
I would be very grateful.

RE: DECT NR+: A technical dive into non-cellular 5G

ErMaqsood — Tue, 17 Mar 2026 16:25:36 GMT

Hi Heidi,

Greeting for the day.

I appreciate your support.

I currently have a DECT NR+ setup running on the nRF9151, based on the HELLO DECT PHY sample using nRF Connect SDK v3.3.0preview2. I am seeking your guidance on how to route data across a small NR+ cluster, specifically in the following topology:

[cluster1] Leaf (Node1) ⇄ Router (Relay) ⇄ Leaf (Node2) [cluster2]

Could you please advise on the correct approach, configuration, or APIs required to enable multi‑hop data routing between Leaf nodes through the Router?

Thank you.

RE: Testing Long Range (Coded PHY) with Nordic solution (It Simply Works)

MopHu — Wed, 11 Mar 2026 08:19:26 GMT

Hi, How to build a test project used for coded-phy distance testing base on nRF54L15 DK PCA10156.

RE: Evaluating Bluetooth®︎ Channel Sounding with our open-source Android app on Google Pixel 10

strat — Thu, 05 Mar 2026 10:25:58 GMT

The Pixel 10a is advertised as supporting BLE 6.0, does anybody know if it supports or will support Channel Sounding?

RE: Essential pin planning guidelines for the nRF54L Series

devangs33 — Tue, 03 Mar 2026 18:18:00 GMT

Is there a similar document for nRF54H20 ?

RE: How do I know where I should ask my question?

Suhas0 — Thu, 26 Feb 2026 12:50:55 GMT

Hi,

I am working on the nRF9151 DK (nrf9151dk_nrf9151ns) and need to use an additional UART for communication with an external ESP32.

Currently:

UART0 is used for console/debug.
UART1 is used by the LTE modem.

Therefore, I am attempting to enable UART2 for external communication.

After reviewing the board schematic, I found that P0.02 and P0.03 are not used by any active peripherals in my setup. These pins are routed to the Arduino header, and since no shield is connected, I assume they can be reassigned.

I have added the following overlay: nrf9151dk_nrf9151ns.overlay

&uart2 {
status = "okay";
current-speed = <115200>;
pinctrl-0 = <&uart2_default>;
pinctrl-names = "default";
};

&pinctrl {
uart2_default: uart2_default {
group1 {
psels = <NRF_PSEL(UART_TX, 0, 2)>,
<NRF_PSEL(UART_RX, 0, 3)>;
};
};
};

prj.conf
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_UART_NRFX=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_2_ASYNC=y
CONFIG_UART_2_NRF_HW_ASYNC=y

RE: Essential pin planning guidelines for the nRF54L Series

humankey — Fri, 06 Feb 2026 15:54:51 GMT

I am designing an external battery-operated device using the nRF54L10 QFN48. I am constrained by the limited number of pins on Port 0 (5 pins) and trying to strictly follow the rule to "Match peripherals to their domains."

• I am using TWIM30 (LP domain) for a sensor on P0.

• I need to gate power to this sensor using a GPIO to save energy.

• I have run out of P0 pins.

If I place the Sensor VDD control on a P1 GPIO (Peri Domain) while keeping the I2C lines on P0 (LP Domain), I am concerned about leakage.

Questions:
1. If the PERI domain (P1) is powered down in System OFF/Sleep, but the LP domain (P0) remains active for wake-up monitoring, will the P1 GPIO hold its state, or will it cause the sensor VDD to float/drop, creating a leakage path from the P0 I2C pull-ups through the sensor?

2. Is it recommended to move non-wakeup assets (like LEDs) to P1 to free up P0 for the Sensor VDD, ensuring the entire sensor interface remains within the LP domain?

RE: What’s new in Bluetooth®︎ Core 6.2: An overview

Valon.Shen — Thu, 11 Dec 2025 03:40:53 GMT

Hello, I have some questions. If we update the interval to the minimum value （375us）, what is the maximum amount of ACL data we can send?

If the data is too long (such as sending a control packet), will we encroach on the next interval?

If not, does that mean we can never send overly long packets? For example, for a CONNECTIN RATE IND , would we be unable to update the interval to a larger value?

RE: Evaluating Bluetooth®︎ Channel Sounding with our open-source Android app on Google Pixel 10

Cary.Hsu — Wed, 10 Dec 2025 09:22:11 GMT

nRF54L15 Could Initiator to work with multi Reflector? Just like 1 to 4.

RE: Next-level nRF54L Series: Cutting power consumption even further

Cary.Hsu — Wed, 10 Dec 2025 09:20:22 GMT

nRF54L15 Could Initiator to work with multi Reflector? Just like 1 to 4.

RE: Essential pin planning guidelines for the nRF54L Series

odin huang — Tue, 25 Nov 2025 03:10:13 GMT

Dear Nordic,

The peripheral-to-pin connection matrix for the nRF54L Series should be clearly presented in a matrix/table format within the datasheet. I cannot ascertain from the current datasheet that the PWM output pins are restricted to Port 1 (P1). It merely states that all P1 pins can be used, but fails to clarify why Port 0 (P0) and Port 2 (P2) cannot be used.

This usage and restriction represent a departure from previous nRF52/nRF53 series devices. Therefore, a clear and explicit Peripheral-to-Pin Configuration Matrix Table is needed on the very first page of the peripheral section in the manual for quick and easy reference. This is similar to the pin/peripheral matrix tables found in STM32 datasheets, which allow for rapid, clear distinction, helping to prevent errors in pin selection, especially when selecting peripherals that utilize shared pins.

RE: What’s new in Bluetooth®︎ Core 6.2: An overview

Emil Lenngren — Tue, 11 Nov 2025 14:04:34 GMT

The changes about legacy passkey pairing can be found in Table 2.8 in the Security Manager specification.

Notably, legacy passkey pairing is no longer considered "authenticated", meaning that it no longer satisfies Security Mode 1 Level 3.