Nordic Q&A - Recent Threads

nRF5 SDK 17.1.0: Numeric Comparison pairing dialog on phone fails to dismiss after peripheral rejects pairing

David Duan — Wed, 09 Sep 2026 07:08:14 GMT

Hi DevZone,

My customer is using nRF5 SDK v17.1.0 with LESC Numeric Comparison pairing. They have encountered an issue during the pairing process: when the central (phone) initiates pairing, the

peripheral correctly displays the passkey. However, if the pairing request is rejected on the peripheral side, the pairing dialog box on the central side does not disappear. According to the

customer, BLE chips from other vendors do not exhibit this behavior.

I replicated and tested this issue using a standard nRF5 SDK v17.1.0 example on an nRF52832 DK.

The results confirmed that when the peripheral rejects the pairing, the pairing dialog box on the phone remains visible. Interestingly, when I ran the same test using NCS 3.4, the pairing dialog dismissed normally as expected.

After further investigation, I noticed that in NCS, if the peripheral rejects the pairing, it explicitly sends an SMP Pairing Failed packet. However, in the nRF5 SDK, even though the corresponding code logic triggers key_type = BLE_GAP_AUTH_KEY_TYPE_NONE, the device does not actually send the SMP Pairing Failed (Reason: 0x04 - Confirm Value Failed) command.

static ret_code_t num_comp_reply(uint16_t conn_handle, bool accept)
{
    uint8_t    key_type;
    ret_code_t err_code;

    if (accept)
    {
        NRF_LOG_INFO("Numeric match confirmed. Conn handle: %d", conn_handle);
        key_type = BLE_GAP_AUTH_KEY_TYPE_PASSKEY;
    }
    else
    {
        NRF_LOG_INFO("Numeric match rejected. Conn handle: %d", conn_handle);
        key_type = BLE_GAP_AUTH_KEY_TYPE_NONE;

        // Must be set before the reply: replying with BLE_GAP_AUTH_KEY_TYPE_NONE makes the
        // SoftDevice send an SMP Pairing Failed PDU (Numeric Comparison Failed) and raise
        // BLE_GAP_EVT_AUTH_STATUS, which in turn produces PM_EVT_CONN_SEC_FAILED.
        m_num_comp_rejected_locally = true;
    }

    err_code = sd_ble_gap_auth_key_reply(conn_handle, key_type, NULL);

    // Do NOT use APP_ERROR_CHECK() here: a failure must stay visible instead of
    // resetting the chip, because on an error nothing is transmitted and the SMP
    // request is still pending.
    if (err_code == NRF_SUCCESS)
    {
        NRF_LOG_INFO("sd_ble_gap_auth_key_reply(key_type=%d) OK", key_type);
    }
    else
    {
        m_num_comp_rejected_locally = false;
        NRF_LOG_ERROR("sd_ble_gap_auth_key_reply(key_type=%d) failed: 0x%x (%s)",
                      key_type, err_code, nrf_log_push((char *)nrf_strerror_get(err_code)));
        NRF_LOG_ERROR("Nothing was sent on air; the SMP request is still pending.");
        printf("\r\nauth_key_reply failed: 0x%lx\r\n", (unsigned long)err_code);
    }

    return err_code;
}

NCS 3.4 Test Result: When the peripheral rejects the pairing request, the pairing dialog box on the phone disappears normally.

devzone.nordicsemi.com/.../NCS_5F00_SDK_5F00_V1.mp4nRF5 SDK 17.10 Test Result: When the peripheral rejects the pairing request, the pairing dialog box on the phone fails to disappear.

devzone.nordicsemi.com/.../NRF5_5F00_SDK_5F00_V1.mp4

The test project for NRF5 SDK(nrf5sdk 17.10,SEGGER Embedded Studio for ARM v5.68)

devzone.nordicsemi.com/.../ble_5F00_app_5F00_uart_5F00_tst.7z

The test project on NCS3.4.0

devzone.nordicsemi.com/.../peripheral_5F00_lesc.7z

Question:
I would like to confirm whether the nRF5 SDK SoftDevice itself inherently does not support sending this SMP Pairing Failed command in this scenario?

nRF52840: QSPI pin configuration confirmation

Kaushik Thumar — Wed, 09 Sep 2026 06:43:23 GMT

Hi Team,

We are planning to use the following nRF52840 GPIOs for our current SPI interface, with the intention of migrating to QSPI in the future:

CSn: P0.08
CLK: P0.16
IO0 / MOSI: P0.15
IO1 / MISO: P1.08
IO2 / WPn: P0.04
IO3 / RESETn: P0.05

Could you please confirm if there are any restrictions when using these specific pins for standard SPI and subsequently QSPI?

Additionally, since the Nordic reference design recommends different default pins for QSPI, will using our custom pin assignment cause any side effects—such as limitations on maximum clock speed, potential RF/OTA degradation, or anything else?

Thanks and regards,

Kaushik Thumar

Cannot get whitelisted for ant-nrfconnect/sdk-ant github repository

Arthur C — Wed, 09 Sep 2026 06:34:39 GMT

Hello, since thisisant.com is no more, the process to get whitelisted for the ant-nrfconnect/sdk-ant github repository through the ANT Adopter process does not work. I have tried both using the Visual Studio nrf Connect SDK and using the command line to add +ant to my SDK version manifest and `west update` with the same results.

I'm a hobbyist trying to do some data translation to expose to a Garmin GPS using an nrf52840 SoC.

My github account is dyniper

Thanks for helping with this.

Increased current consumption on nrf54l15 + s145

Maciej — Wed, 09 Sep 2026 06:22:52 GMT

Hi all,

We're building a PoC of a simple BLE device with a following setup:

custom PCB with nrf54l15 rev2 and 32MHz oscillator
FreeRTOS + custom port
nrfx version 3.14.0
softdevice s145 version 10.0.0
our application layer

In order to handle the softdevice operation we're using some of the modules from nRF5 SDK (like nrf_sdh, nrf_sdh_ble etc.).

The baseline current consumption for now for most of the functionalities disabled and the mcu sleeping is 6uA. The moment the softdevice is enabled with

nrf_clock_lf_cfg_t const clock_lf_cfg =

{

.source = 0,

.rc_ctiv = 32,

.rc_temp_ctiv = 2,

.accuracy = 1,

.hfclk_latency = 1000,

.hfint_ctiv = 8,

};

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

the current consumption increases to about 140uA and stays on this level as long as the softdevice is enabled. The moment the softdevice is disabled with

sd_softdevice_disable() the level goes back to 6uA. That is the case even if no BLE functionalities are started.

If the NRF_CLOCK.TASKS_XOSTOP is triggered manually, the current level goes back to 6uA, but the softdevice stops working correctly.

On initialization the nrf_oscillators_hfxo_cap_set is called.

After a full power cycle the behaviour is the same.

For the builds with app protection off, if the device is reset by the debbuger - the moment the debugging session is closed and the debugger is disconnected, the current also goes back to 6uA even if the softdevice is still enabled (the debugging session is crucial not physically disconnecting the probe). After that, softdevice and the device itself are working correctly.

Is the clock configuration wrong? Some peripherals are handled incorrectly?

Regards,

Maciej

nrf54LM20A SPI_MOSI pin not working

Fred F — Tue, 08 Sep 2026 22:01:03 GMT

An SPI port is configured as a master, and all the signals seem to operate correctly except the SPI_MOSI.

The configuration is shown below. When the spi_transceive_dt() function is used, the CS and CLK likes operate as expected, but the MOSI line does not toggle. There is data in the TX buffer that is non-zero and data is read on the MISO line. Is there a configuration problem that is preventing the MOSI signal from working? Checking the configuration register for SPI21, the MOSI pin selection looks correct (0x02);

        spi21_default: spi21_default {
                group1 {
                        psels = <NRF_PSEL(SPIM_SCK, 1, 18)>,
                                <NRF_PSEL(SPIM_MISO, 3, 7)>,
                                <NRF_PSEL(SPIM_MOSI, 0, 2)>;
                };
        };

        spi21_sleep: spi21_sleep {
                group1 {
                        psels = <NRF_PSEL(SPIM_SCK, 1, 18)>,
                                <NRF_PSEL(SPIM_MISO, 3, 7)>,
                                <NRF_PSEL(SPIM_MOSI, 0, 2)>;
                 };
&spi21 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    cs-gpios =  <&gpio1 19 GPIO_ACTIVE_LOW>;    
    pinctrl-0 = <&spi21_default>;
    pinctrl-1 = <&spi21_sleep>;
    pinctrl-names = "default", "sleep";
    w5500device: w5500device@0 {
        compatible = "vnd,spi-device";   // raw/manual SPI access
        reg = <0>;
        spi-max-frequency = <4000000>;
     };
};

Problems flashing non-secure apps to nrf7002dk

cshaw — Tue, 08 Sep 2026 20:14:24 GMT

I'm running into issues when specifying non-secure for the build target, even for the basic Blinky sample. I created a build configuration with the nRF Connect SDK v3.4.0 and nRF Connect SDK Toolchain v3.4.0. The board target I'm trying to use is nrf7002dk/nrf5340/cpuapp/ns. I've left all the other options blank/default. I don't see any issues in the build output or flashing step that would indicate that the sample app would fail. Instead of a blinking LED, I only see the status LED lit up next to the IMCU.

Notably, flashing the exact same application as a secure app (nrf7002dk/nrf5340/cpuapp) works perfectly fine on this board, and I'm able to see the LED blink.

VS Code and the related SDKs and utilities are installed in a Ubuntu 22.04 distrobox while the host OS is Fedora Silverblue. I've also tested in a devcontainer with the same build configuration, toolchain, and SDK and ran into the same issue with non-secure apps.

Build output:

* Executing task: nRF Connect: Build configuration blinky/build for nrf7002dk/nrf5340/cpuapp/ns

Building blinky
west build --build-dir /var/home/cameronshaw/code/test-nrf/blinky/build /var/home/cameronshaw/code/test-nrf/blinky --pristine --board nrf7002dk/nrf5340/cpuapp/ns -- -DCONFIG_DEBUG_OPTIMIZATIONS=y -DCONFIG_DEBUG_THREAD_INFO=y

-- west build: generating a build system
Loading Zephyr module(s) (Zephyr base): sysbuild_default
-- Found Python3: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/python3.12 (found suitable version "3.12.4", minimum required is "3.12") found components: Interpreter
-- Cache files will be written to: /var/home/cameronshaw/.cache/zephyr
-- Found west (found suitable version "1.5.0", minimum required is "0.14.0")
-- Board: nrf7002dk, qualifiers: nrf5340/cpuapp/ns
Parsing /var/home/cameronshaw/ncs/v3.4.0/zephyr/share/sysbuild/Kconfig
Loaded configuration '/var/home/cameronshaw/code/test-nrf/blinky/build/_sysbuild/empty.conf'
Merged configuration '/var/home/cameronshaw/code/test-nrf/blinky/build/_sysbuild/empty.conf'
Configuration saved to '/var/home/cameronshaw/code/test-nrf/blinky/build/zephyr/.config'
Kconfig header saved to '/var/home/cameronshaw/code/test-nrf/blinky/build/_sysbuild/autoconf.h'
--
****************************
* Running CMake for blinky *
****************************

Loading Zephyr default modules (Zephyr base).
-- Application: /var/home/cameronshaw/code/test-nrf/blinky
-- CMake version: 4.2.1
-- Found Python3: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/python3.12 (found suitable version "3.12.4", minimum required is "3.12") found components: Interpreter
-- Cache files will be written to: /var/home/cameronshaw/.cache/zephyr
-- Zephyr version: 4.4.0 (/var/home/cameronshaw/ncs/v3.4.0/zephyr)
-- Found west (found suitable version "1.5.0", minimum required is "0.14.0")
-- Board: nrf7002dk, qualifiers: nrf5340/cpuapp/ns
-- Found host-tools: zephyr 1.0.1 (/var/home/cameronshaw/ncs/toolchains/fbf7391cab/opt/zephyr-sdk)
-- Found toolchain: zephyr 1.0.1 (/var/home/cameronshaw/ncs/toolchains/fbf7391cab/opt/zephyr-sdk)
-- Found Dtc: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /var/home/cameronshaw/ncs/v3.4.0/zephyr/boards/nordic/nrf7002dk/nrf7002dk_nrf5340_cpuapp_ns.dts
-- Generated zephyr.dts: /var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/zephyr.dts
-- Generated pickled edt: /var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/edt.pickle
-- Generated devicetree_generated.h: /var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/include/generated/zephyr/devicetree_generated.h

warning: Experimental symbol TFM_EXPERIMENTAL is enabled.

Parsing /var/home/cameronshaw/ncs/v3.4.0/zephyr/Kconfig
Loaded configuration '/var/home/cameronshaw/ncs/v3.4.0/zephyr/boards/nordic/nrf7002dk/nrf7002dk_nrf5340_cpuapp_ns_defconfig'
Merged configuration '/var/home/cameronshaw/code/test-nrf/blinky/prj.conf'
Merged configuration '/var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/misc/generated/extra_kconfig_options.conf'
Merged configuration '/var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/.config.sysbuild'
Configuration saved to '/var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/.config'
Kconfig header saved to '/var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/include/generated/zephyr/autoconf.h'
-- Found GnuLd: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/opt/zephyr-sdk/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd (found version "2.43.1")
-- The C compiler identification is GNU 14.3.0
-- The CXX compiler identification is GNU 14.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/opt/zephyr-sdk/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Found Python3: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/python3.12 (found version "3.12.4") found components: Interpreter
-- Could NOT find Threads (missing: Threads_FOUND)
-- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS
-- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Success
-- Using ccache: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/bin/ccache
-- Found gen_kobject_list: /var/home/cameronshaw/ncs/v3.4.0/zephyr/scripts/build/gen_kobject_list.py
-- Configuring done (6.4s)
-- Generating done (0.3s)
-- Build files have been written to: /var/home/cameronshaw/code/test-nrf/blinky/build/blinky
-- Configuring done (9.4s)
-- Generating done (0.0s)
-- Build files have been written to: /var/home/cameronshaw/code/test-nrf/blinky/build
-- west build: building application
[1/263] Preparing syscall dependency handling

[5/263] Generating include/generated/zephyr/version.h
-- Zephyr version: 4.4.0 (/var/home/cameronshaw/ncs/v3.4.0/zephyr), build: ncs-v3.4.0
[7/263] Generating ../../tfm/CMakeCache.txt
-- Found Git: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/git (found version "2.52.0")
-- The C compiler identification is GNU 14.3.0
-- The CXX compiler identification is GNU 14.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/opt/zephyr-sdk/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Found Python3: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/python3.12 (found version "3.12.4") found components: Interpreter
-- Found Python3: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/python3.12 (found suitable version "3.12.4", minimum required is "3.12") found components: Interpreter
-- Cache files will be written to: /var/home/cameronshaw/.cache/zephyr
-- Found Python3: /var/home/cameronshaw/ncs/toolchains/fbf7391cab/usr/local/bin/python3.12 (found version "3.12.4") found components: Interpreter
CMake Warning (dev) at /var/home/cameronshaw/ncs/v3.4.0/nrf/modules/trusted-firmware-m/tfm_boards/nrf5340_cpuapp/CMakeLists.txt:21 (install):
Policy CMP0177 is not set: install() DESTINATION paths are normalized. Run
"cmake --help-policy CMP0177" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.

-- Configuring done (0.7s)
-- Generating done (0.1s)
CMake Warning:
Manually-specified variables were not used by the project:

QCBOR_PATH
TFM_CREATE_SIGNING_LAYOUT_OBJECTS
T_COSE_PATH

-- Build files have been written to: /var/home/cameronshaw/code/test-nrf/blinky/build/blinky/tfm
[193/195] Linking C executable bin/tfm_s.axf
Memory region Used Size Region Size %age Used
FLASH: 130540 B 256 KB 49.80%
RAM: 50088 B 256 KB 19.11%
[19/263] Performing install step for 'tfm'
-- Install configuration: "Debug"
----- Installing platform NS -----
[263/263] Linking C executable zephyr/zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 31276 B 192 KB 15.91%
RAM: 4776 B 192 KB 2.43%
IDT_LIST: 0 B 32 KB 0.00%
Generating files from /var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/zephyr.elf for board: nrf7002dk/nrf5340/cpuapp/ns
[8/8] Completed 'blinky'

Flash output:
* Executing task: nRF Connect: Flash: blinky/build

Flashing build to nRF7002 DK
west flash -d /var/home/cameronshaw/code/test-nrf/blinky/build --dev-id 001050700558

-- west flash: rebuilding
[0/3] Performing build step for 'blinky'
[0/16] Performing build step for 'tfm'
ninja: no work to do.
[2/3] Performing install step for 'tfm'
-- Install configuration: "Debug"
----- Installing platform NS -----
[3/3] Completed 'tfm'
[2/3] No install step for 'blinky'
[3/3] Completed 'blinky'
-- west flash: using runner nrfutil
-- runners.nrfutil: reset after flashing requested
-- runners.nrfutil: Flashing file: /var/home/cameronshaw/code/test-nrf/blinky/build/blinky/zephyr/tfm_merged.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Erasing address ranges touched by firmware
-- runners.nrfutil: Programming image
-- runners.nrfutil: Verifying image
-- runners.nrfutil: Reset
-- runners.nrfutil: Board(s) with serial number(s) 1050700558 flashed successfully.
* Terminal will be reused by tasks, press any key to close it.

tcp sendmsg() EAGAIN handling

dpf — Tue, 08 Sep 2026 17:56:21 GMT

we have a 'long lived' tcp connection w/ regular data sends (1hz of 256 bytes for mqtt publishes) where sendmsg() sometimes returns EAGAIN. when trying again it usually works but sometimes we get the poll() read event and this indicates that the peer reset the connection.

i interpret this as there being an erro w/ the retry, an unexpected resend should be ok but only if it matches the previous send. are there conditions that the device-side where it could resend something different?

tcp mss vs mtu

dpf — Tue, 08 Sep 2026 17:35:25 GMT

our current network provider says that they have a restriction on their sim profile so that the mtu should be less than 1430. however things like pdn_dynamic_params_get() and at+cgcontrdp report differently (1500).

however, when we make a tcp connection (w/ tls) we see the tcp max-segment-size option set w/ 708. my reading of this option means that the modem's networking should restrict things so that it could have data outstanding but it's going to be restricted so that it doesnt get out of hand. the interfaces to the network stack dont allow for querying this (eg, getsockopt()) so asking how this value is getting set?

System clock stops permanently after a GRTC compare event is lost

Samuel0123 — Tue, 08 Sep 2026 16:14:56 GMT

nRF54L15: system clock stops permanently after a GRTC compare event is lost

Disclaimer

Claude Code (Opus 5) was used to assist with this investigation and with the drafting of this report. The failure itself was found by the author, on our own hardware. Every register capture, code path and conclusion below has been manually reviewed and verified by the author.

Summary

Under sustained BLE traffic the Zephyr system tick stops permanently. Every kernel timeout then stalls forever while the GRTC SYSCOUNTER keeps running.

We trace this to a race in the safe_setting branch of nrfx_grtc_syscounter_cc_abs_set(). That branch clears EVENTS_COMPARE in order to discard a stale event from the previous CC value; if the newly programmed compare fires between the counter sample and the clear, the clear destroys the legitimate event along with the stale one. Nothing regenerates it, and the driver is never called again to rewrite the CC, so the stall is permanent.

The state captured on the halted target is what identifies it:

Register	Value	Meaning
`CC[6].CCEN`	0	the compare fired
`EVENTS_COMPARE[6]`	0	its event is nevertheless gone
`INTEN2` bit 6	1	the interrupt was enabled the whole time

We built a standalone reproducer, attached as GRTC-CompareLoss-Reproduction.zip and described under Standalone reproduction. It destroys COMPARE events inside nrfx_grtc_syscounter_cc_abs_set() on demand, on a private channel, with a control pass that differs only in the safe_setting argument and loses nothing; it kills the Zephyr system tick through the ordinary timeout API, ending in the register signature above; and it measures the CCEN behaviour the diagnosis rests on directly, on hardware.

Our fix, described under Our fix, is in nrfx rather than in Zephyr: the safe_setting branch now clears the event before arming the channel, the ordering nrfx's own sibling entry point nrfx_grtc_syscounter_cc_absolute_set() already uses, so that no clear can follow the new CC going live and no event it generates can be destroyed. We are filing this because the code path is unchanged in Zephyr main and in nrfx 4.5.0, and because the fix belongs upstream rather than in every application's patch directory.

Environment


SoC	nRF54L15
Board	nRF54L15-DK (1.0.0, 2025.51)
SDK	nRF Connect SDK v3.3.0
Zephyr	`fd9204a02d5` (2026-04-20)
nrfx	4.2.1
Driver	`drivers/timer/nrf_grtc_timer.c`

Relevant configuration:

CONFIG_TICKLESS_KERNEL=y
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=1000000
CONFIG_SYS_CLOCK_TICKS_PER_SEC=31250        # CYC_PER_TICK = 32
CONFIG_NRF_GRTC_START_SYSCOUNTER=y
CONFIG_NRF_GRTC_TIMER_AUTO_KEEP_ALIVE=y
CONFIG_NRF_GRTC_TIMER_SOURCE_LFXO=y
CONFIG_BT=y                                 # SoftDevice Controller, peripheral
CONFIG_MPSL=y

GRTC devicetree:

&grtc {
    owned-channels       = <0 1 2 3 4 5 6 7 8 9 10 11>;
    child-owned-channels = <3 4 7 8 9 10 11>;   /* 7-11 = MPSL */
};

Allowed application channel mask is 0x67 = {0,1,2,5,6}. nrfx_flag32_alloc() returns the highest free bit, so the system clock owns channel 6.

On secure cpuapp GRTC_IRQ_GROUP = 2, so the relevant registers are INTEN2 / INTPEND2 and the relevant per-domain register is SYSCOUNTER[2]. Zephyr uses IRQ 228 (GRTC_2); MPSL uses IRQ 229 (GRTC_3).

Symptom

After a period of BLE communication testing the device stops making forward progress. Breakpoints in sys_clock_timeout_handler() are never hit, while the GRTC SYSCOUNTER continues to increment. Halting the debugger always lands in the idle thread at __WFI.

Frequency: roughly twice per hour of intensive BLE testing, with many connect/disconnect cycles. Observed onset times range from ~30 s to ~2 h of uptime.

Because the CPU is asleep rather than spinning, a watchdog configured with WDT_OPT_PAUSE_IN_SLEEP never fires either, so the failure presents as a completely silent, indefinite hang.

State captured at the hang

Two reproductions were captured, in separate runs. Note up front that they are not two views of one event: the driver statics below come only from run 1, and the CC/CCEN registers only from run 2.

Reproduction 1 — established that no software path had suppressed the interrupt

Item	Value	Note
CPU context	idle thread at `__WFI`	normal for `arch_cpu_idle()`
`PRIMASK`	1	normal, set by `arch_cpu_idle()` around WFI
`BASEPRI`	0	nothing masked
`VECTACTIVE`	0	thread mode, not stuck in an ISR
`ISER[7]`	`0x30`	IRQ 228 and 229 both enabled
`ISPR[7]`	`0x20`	only IRQ 229 pending (MPSL, fires during the halt, benign)
`INTEN2`	`0x40`	channel 6 interrupt is enabled
`INTPEND2`	`0x00`	no compare event pending -> `EVENTS_COMPARE[6] == 0`
SYSCOUNTER	`1:0xD9DC3163`	= 7,950,053,731 cycles ~= 2 h 12 min

nrf_grtc_timer.c statics:

Static	Value	Note
`cc_value`	57516636	= `0x036DA25C`
`expired_cc`	57516538	previous expiry, 98 cycles = 98 us earlier
`int_mask`	`0x67`	equals the allowed mask; no channel interrupt-locked

The 98-cycle figure is the distance from the previous expiry. Reconstructing the forward distance that was actually requested:

cc_value - expired_cc = last_elapsed + cyc - d = 98,  d = expired_cc - last_count,
d in [0, 32) because the handler advances last_count by whole ticks

=> cyc <= 98 + d < 130, so the request was AT MOST 4 TICKS (128 us) ahead.

So the driver's software state froze at t ~= 57.5 s while the hardware counter ran on to t ~= 7950 s, with channel 6 holding a compare the counter had passed two hours earlier and its interrupt enabled (we intentionally let it run for some time even when frozen).

Reproduction 2 — identified the mechanism

This run had CONFIG_NRF_GRTC_ALWAYS_ON=y (see What we ruled out):

Register	Value	Note
`SYSCOUNTER[2].ACTIVE`	`0x1`	the keep-awake request was in effect
`CC[6].CCL`	`0x01CE1AC1`	= 30,284,993, i.e. fired at ~30.28 s uptime
`CC[6].CCH`	`0x00000000`
`CC[6].CCEN`	0	the compare fired
`INTEN2` bit 6	1	interrupt still enabled
`INTPEND2`	`0x00`	`EVENTS_COMPARE[6] == 0`
SYSCOUNTER	far beyond `CC[6]`

CCEN is the reading the diagnosis rests on. Its behaviour is not described in the nRF54L15 Product Specification (see question 5), so phase A0 of the reproducer measures it, on a compare channel: it writes a CC and reads CCEN, then waits for the compare and reads CCEN and EVENTS_COMPARE again. On the DK, CCEN == 1 after the write, and CCEN == 0 with EVENTS_COMPARE == 1 after the compare fires. CCEN == 0 with EVENTS_COMPARE == 0 therefore means a fired-then-destroyed compare — we cannot construct another sequence that produces that pair — and the eliminations below that depend on it stand.

Mechanism

Confirmed directly, not merely reconstructed from the end state: phase A of the attached reproducer drives the race in isolation and counts the destroyed events, and phase B drives it through the ordinary Zephyr timeout API until the tick dies.

cc_value != expired_cc on entry to sys_clock_set_timeout() means the function ran twice with no expiry in between — a timeout was aborted and rescheduled. That takes the absolute path, and because prev_cc_val - now was under LATENCY_THR_TICKS, safe_setting was selected:

/* drivers/timer/nrf_grtc_timer.c - sys_clock_set_timeout() */
if (prev_cc_val < cc_value) {
    safe_setting = (int64_t)(prev_cc_val - now) < LATENCY_THR_TICKS;
}
nrfx_grtc_syscounter_cc_abs_set(ch, cc_value, safe_setting);

/* nrfx_grtc.c - the safe_setting branch */
nrfy_grtc_sys_counter_cc_set(NRF_GRTC, channel, val);          /* CCEN <- 1 */
if (nrfy_grtc_sys_counter_compare_event_check(NRF_GRTC, channel)) {
    now = nrfx_grtc_syscounter_get();                          /* sample     */
    if (val > now) {
        nrfy_grtc_sys_counter_compare_event_clear(NRF_GRTC, channel);  /* wipe */
    }
}

The clear exists to discard a stale event left by the previous CC value. Between sampling now and executing the clear, the SYSCOUNTER can cross the newly programmed val; hardware then sets EVENTS_COMPARE and clears CCEN, and the clear wipes that legitimate event along with the stale one. In run 1 both CC values were in play within ~100 us of each other (the reschedule was at most 128 us ahead), which is what makes the overlap likely rather than exotic.

Independent of which interleaving occurred, the structural defect is plain in the code: the branch never verifies, after the write, that the CC still lies ahead of the SYSCOUNTER, nor that an event it is about to clear had not just been generated legitimately. It clears unconditionally on the strength of a counter sample taken before the clear.

Why it is permanent

Once the counter is past the CC with the event flag clear, nothing regenerates it. The handler never runs, so sys_clock_announce() never runs, so sys_clock_set_timeout() is never called again — the driver never gets a chance to rewrite the CC and recover. With a 52-bit SYSCOUNTER there is no wrap-around to save it either (~142 years at 1 MHz).

This is the structural difference from nrf_rtc_timer.c on earlier parts, where a lost compare self-heals after the 512 s RTC wrap.

Standalone reproduction

Attached as GRTC-CompareLoss-Reproduction.zip:

Item	Contents
`grtc_bug_reproduction/`	standalone Zephyr/NCS application
`nrfx_grtc-clear-before-write.patch`	our fix, as quoted under Our fix

The application needs no Bluetooth, no MPSL and none of our own firmware. It is console-only and tickless on a stock nrf54l15dk/nrf54l15/cpuapp board target, built against an unmodified NCS v3.3.0:

west -z "$ZEPHYR_BASE" build -b nrf54l15dk/nrf54l15/cpuapp -d build
west flash -d build

Console is the DK's default UART at 115200 8N1. Its README.md carries the full derivation and the expected output; CMakePresets.json has one preset per configuration. The two phases are independent, each behind its own Kconfig symbol, and both reproduce.

Phase A — the nrfx race in isolation (`CONFIG_GRTC_REPRO_ISOLATED`)

Calls nrfx_grtc_syscounter_cc_abs_set(ch, val, true) directly, on a channel allocated to the application with no interrupt enabled, and classifies every attempt from the hardware registers alone: event present (fine), CCEN still set after the deadline (the compare never fired — a different anomaly, counted separately), or CCEN == 0 with EVENTS_COMPARE == 0, i.e. an event the hardware generated and the driver destroyed.

Each attempt first leaves a stale event on the channel — the state the safe_setting path exists to clean up — and then programs a new CC a swept 0..31 us ahead of a freshly read SYSCOUNTER, with interrupts locked across the call so the only window in play is the one inside nrfx. The identical loop then runs again with safe_setting = false as a control. The two passes differ in nothing else. The race pass destroys events; the control pass destroys none.

That isolates the loss to the event clear in the safe_setting branch, with the Zephyr timer driver, our firmware, BLE and MPSL all out of the picture.

Phase A0 additionally settles the two hardware properties the analysis needs and the PS does not state: the CCEN state machine (see State captured at the hang), and whether a CC written into the past generates an event at all. It does.

Phase B — the tick stall through the public API (`CONFIG_GRTC_REPRO_TICK_STALL`)

Reproduces the user-visible symptom with nothing but k_timer and k_sleep, and ends in the field signature: CCEN = 0, EVENTS_COMPARE = 0, INTEN bit set, CC far in the past, SYSCOUNTER running on, no thread ever scheduled again.

Working out how to reach the race from the timeout API also answers why the failure is rare in the field and absent from most applications. Three constraints must hold at once:

now must be stale. now = last_count + last_elapsed, and last_elapsed is only refreshed through sys_clock_elapsed(). kernel/timeout.c's elapsed() returns 0 while announce_remaining != 0, so for the whole of sys_clock_announce() now stays frozen at the announce base while the SYSCOUNTER runs on. Every call from thread context samples the counter first and lands a full tick ahead of it, out of reach.
It must be the last CC write before the compare would have fired; any later write re-arms CCEN and silently repairs the damage. Since sys_clock_announce() always ends with sys_clock_set_timeout(next_timeout(0), false), a call from a timer callback is always followed by that one and can never be fatal. The fatal call is the closing one itself.
That closing call must take the absolute path with safe_setting = true, which needs next_timeout() to be larger at the closing call than it was at an abort earlier in the same announce (z_abort_timeout() being the only thing that calls sys_clock_set_timeout() from a callback, since z_add_timeout() is suppressed while announce_remaining != 0).

Constraint 3 is why the obvious "start two timers and abort the earlier one" pattern reproduces nothing: z_abort_timeout() removes the timeout before evaluating next_timeout(), and remove_timeout() hands the removed entry's dticks to its successor, so next_timeout() is unchanged and the closing call rewrites the same cc_value with safe_setting = false. The exception is aborting a timeout whose dticks is 0 — one sharing the currently firing deadline. It contributes nothing to its successor, next_timeout() returns 0, cyc becomes 0, and the driver's relative path forces cyc = 1: CCADD += 1 puts the CC one microsecond in the past, which the hardware turns into an EVENTS_COMPARE immediately. That is the stale event the race needs. With a second timeout also on that deadline, the announce loop pops it after the callback returns and next_timeout() then jumps up to the surviving timeout, so the closing call sees

prev_cc_val = expired_cc + 1     one microsecond above the frozen announce base
cc_value    = now + N ticks      now being that same frozen base

i.e. prev_cc_val < cc_value with prev_cc_val - now == 1: absolute path, safe_setting true, EVENTS_COMPARE already set, and no CC write behind it.

The application constructs that state deliberately from four k_timers (one carrying the pattern, three no-op shields of which two share its deadline), then busy-waits until the SYSCOUNTER is a swept distance short of the CC the closing call is about to program, so that the counter crosses it in the few cycles between nrfx's sample and its clear. The distance is swept across a 0..40 us window in single busy-loop iterations, subdivided by NOPs so no offset is skipped; a full sweep takes roughly half a second, which makes this a sweep rather than a lottery. A per-round self-check confirms the abort really was the dticks == 0 one, so a run that does not reproduce can be told apart from a run that never reached the right call.

Two practical notes:

k_uptime_get() is not a stall detector. sys_clock_tick_get() adds sys_clock_elapsed(), which samples the free-running SYSCOUNTER, so uptime keeps advancing perfectly correctly right through the stall. Everything that merely reads the time looks healthy; only the fact that no callback runs any more exposes the failure. Phase B therefore detects the stall from a watchdog on a private GRTC channel, armed through z_nrf_grtc_timer_set() — which routes to the race-free nrfx_grtc_syscounter_cc_absolute_set(), so the watchdog cannot lose its own event — and reports from its ISR, since by then no thread will ever run again.
Both phases require a stock nrfx_grtc.c, and phase B additionally a stock drivers/timer/nrf_grtc_timer.c — our fix removes the race outright, so there is nothing left to observe. The build warns at configure time if it detects either patch in the workspace.

What we ruled out

Software suppression of the interrupt

Fatal error / assert halt — arch_system_halt() spins with interrupts locked, which would show non-zero BASEPRI and a PC inside the halt loop. BASEPRI is 0 and the CPU is in the idle thread.
Interrupts masked by a leaked lock — BASEPRI 0; PRIMASK 1 is explained by arch_cpu_idle(); VECTACTIVE 0.
Stuck or starving ISR — VECTACTIVE 0, thread mode.
Channel interrupt disabled by compare_int_lock() — INTEN2 = 0x40, and int_mask = 0x67 agrees that all allowed channels are enabled.
NVIC interrupt disabled — ISER[7] = 0x30, IRQ 228 enabled.
Empty timeout queue (legitimate tickless idle) — the application always has pending timeouts: a 250 ms watchdog tick timer and a 500 ms main-loop sleep.

SYSCOUNTER sleep / CC latch latency — ruled out by experiment

CONFIG_NRF_GRTC_ALWAYS_ON=y (keeping the SYSCOUNTER continuously active, so a CC write can never race a sleep/wake transition) does not prevent the hang: reproduction 2 ran with it enabled, and the hang still reproduced, with SYSCOUNTER[2].ACTIVE = 0x1 confirming the keep-awake request was in effect throughout.

Note the correct register: nrfx_grtc_active_request_set() writes GRTC_SYSCOUNTER.ACTIVE, which is SYSCOUNTER[NRF_GRTC_DOMAIN_INDEX] = SYSCOUNTER[GRTC_IRQ_GROUP] = SYSCOUNTER[2] on secure cpuapp. SYSCOUNTER[0] belongs to another domain and reads 0 regardless of this setting.

This is consistent with the actual mechanism: the race is between the CPU and the free-running counter, so counter sleep/wake latency is irrelevant to it.

CC written into the past, or lost in the CCL -> CCH write window — ruled out by the CCEN reading

Both are candidate mechanisms by which the compare might never fire at all, and both are excluded by CC[6].CCEN = 0: a compare that never matched would leave CCEN at 1 (the CCEN state machine as measured by phase A0). The past-CC candidate is doubly excluded: A0 also shows the hardware raises EVENTS_COMPARE for a CC written into the past, so that is not a way for a compare to go missing.

Other channel owners disabling CCEN on channel 6 — excluded by inspection of the source for this build configuration

nrf_sys_event — CONFIG_NRF_SYS_EVENT is not set, so USE_SYS_EVENT is undefined and the GRTC-channel path in soc/nordic/common/nrf_sys_event.c is compiled out.
The CONFIG_POWEROFF channel sweep in z_nrf_grtc_wakeup_prepare(), which disables every allowed channel except its own — CONFIG_POWEROFF is not set.
The 802.15.4 platform glue, which calls z_nrf_grtc_timer_abort() — CONFIG_NRF_802154_RADIO_DRIVER is not set.
The Zephyr LL's radio.c / cntr.c — this build uses CONFIG_BT_LL_SOFTDEVICE, and those files use channels 10/11 in any case.
nrfx_grtc_uninit() via sys_clock_disable() — it would leave SYSCOUNTER[2].ACTIVE = 0, which reads 1.

MPSL interference — only partly excluded

The pending IRQ 229 is enabled and serviced normally, its channels 8/9 are in MPSL's reserved block, and CONFIG_BT_UNINIT_MPSL_ON_DISABLE is not set, so bt_disable() does not tear down MPSL's IRQ. But MPSL ships as a binary library, so unlike the cases above we cannot inspect it to confirm it never touches channel 6 or the group-2 registers. We have no positive evidence that it does; we simply cannot rule it out the way we ruled out the others, and the correlation with BLE traffic is the one thing that would be equally well explained by MPSL involvement. If you can confirm from the MPSL side that channel 6 is untouched, that would close the last alternative we are aware of.

The reproducer has no Bluetooth and no MPSL in the image, so MPSL is not needed to explain the failure — it remains possible as a second contributor to the field failures, but not as an alternative explanation.

Silicon anomalies

L15_22 / L15_24 / L15_25 — these cover EVENTS_COMPARE[n] on the TIMER peripheral, not the GRTC (per Nordic in DevZone 127458).
L15_30 ("CLOCK, GRTC: GRTC operates incorrectly at low temperature") — describes GRTC frequency drift when the system runs on HFINT. The failure here is a single lost compare event, not a drifting time base. Please confirm this is not a contributing factor.

Open points

Collected here rather than left buried in the prose above, so you can see exactly where the analysis is load-bearing and where it is not.

We did not measure the width of the window between the counter sample and the event clear, and cannot bound it from the documentation. The reproducer sweeps its offset until it hits the window instead of measuring it. What we can say is that phase A locks interrupts across the call, so the window is wide enough to lose events with nothing widening it.
MPSL cannot be inspected, so it alone is excluded by inference rather than by reading the code. Not being needed to reproduce the defect does not close it out as a second contributor in the field.
The two field captures are from different runs, so for the field failures "the CC was too close AND the event was lost" still joins two observations by argument. In the reproducer both halves are present in a single run.
Whether the interleaving the reproducer forces is the one that fires in the field. It is the same mechanism ending in the same register state, but the field path is necessarily inferred: our firmware does not construct that timer pattern deliberately, it arrives there under BLE load.
Whether the retry in our fix is necessary. That a spurious COMPARE event on this path would be misinterpreted is read off Zephyr's sys_clock_timeout_handler() (see Our fix); we have not provoked one and watched the clock jump. The retry costs nothing when no event is pending, so we kept it either way.

Our fix

Applied locally as a patch to modules/hal/nordic/nrfx/drivers/src/nrfx_grtc.c. It supersedes a stopgap of ours in drivers/timer/nrf_grtc_timer.c, which detected the lost event after the fact (CCEN == 0 with EVENTS_COMPARE == 0) and re-raised it; that one recovered the system clock only, whereas the race is in nrfx and reaches every caller of nrfx_grtc_syscounter_cc_abs_set().

Status: the hang stopped reproducing under the BLE test load that previously triggered it within minutes to a couple of hours, first under that stopgap and since under this fix, and neither phase of the reproducer reproduces against it. The soak on this fix is still running; given the fault was intermittent we will report back if it recurs.

if (safe_setting)
{
    bool retry;

    do
    {
        nrfy_grtc_sys_counter_compare_event_clear(NRF_GRTC, channel);
        nrfy_grtc_sys_counter_cc_set(NRF_GRTC, channel, val);

        retry = nrfy_grtc_sys_counter_compare_event_check(NRF_GRTC, channel) &&
                (val > nrfx_grtc_syscounter_get());
    } while (retry);
}

Clearing before arming is the ordering nrfx_grtc_syscounter_cc_absolute_set() already uses, and it is what removes the defect: no clear can follow the new CC going live, so no event the new CC generates can be destroyed. It also needs no assumption about hardware timing.

The loop is there because the reordering alone would trade the lost event for a spurious one, and for this caller that is not a benign trade. The previous CC is still armed while the clear runs — that is precisely the situation safe_setting exists for — so it can expire between the clear and the CC write and leave behind an event that does not belong to the new CC. The nrfx ISR passes the handler m_cb.cc_value[], which this function has already advanced to the new value, so sys_clock_timeout_handler() would announce the whole new timeout immediately and set last_count past the SYSCOUNTER, after which counter_sub() in sys_clock_elapsed() underflows. A lost compare stops the clock; an unrepaired spurious one throws it forward.

The loop resolves that without reopening the original window:

An event present after the CC write is either generated by the new CC — val is already in the past, the event is due, keep it — or left by the previous CC.
The two are told apart by reading the SYSCOUNTER after the event check, not before: val > now then proves the counter had not reached val at the moment the event was observed, so that event cannot belong to the new CC and is safe to clear. This is the ordering the original branch got wrong.
Every clear is immediately followed by a CC write that re-arms the channel, so no iteration can leave a fired compare without an event — the state that stalls the clock is unreachable from inside the loop.
It terminates: after the first CC write only val itself can generate an event, and such an event implies now >= val on the next pass.

Cost, on the path where nothing is pending, is one extra register write — the clear — and no SYSCOUNTER read, so the optimisation the safe_setting path exists for is kept. We did not add a critical section around the clear/write pair, since the function is documented as "must be called with interrupts locked"; nrfx_grtc_syscounter_cc_absolute_set() takes one, and if that is deliberate rather than defensive the same should be done here.

The alternative we did not take: phase A0 confirms the hardware raises EVENTS_COMPARE for a CC written into the past, so a lost compare can also be recovered by rewriting the CC. That is still a recovery after the fact, and it rests on a hardware property we measured on one DK rather than one that is documented, so we preferred the ordering fix.

Upstream status (checked 2026-09-08)

Zephyr

Upstream main still has the same call into the safe_setting path and no post-write verification. Commits to drivers/timer/nrf_grtc_timer.c after the revision in NCS v3.3.0:

Commit	Date	Change
`f4a2a270715`	2026-06-10	kernel: timeout: make the system clock tick interface unsigned -> `sys_clock_set_timeout(uint32_t ticks, ...)`
`48f35d88c68`	2026-06-23	drivers: timer: clean up tick clamps for the unsigned interface -> for GRTC, only an `(int32_t)` cast removed
`aad2c65d69e`	2026-07-31	release LFCLK before GRTC uninit
`839c682963f`	2026-08-21	`__ASSERT_ON` migration

None touches the compare path.

nrfx

NCS v3.3.0 ships nrfx 4.2.1. Upstream master is at 4.5.0 (2026-07-23), three releases newer. The GRTC entries in between are:

Release	GRTC entry
4.3.0	"Fixed extended channel mask definition for devices supporting MINTERVAL feature in the GRTC driver." — unrelated, build-time mask definition
4.4.0	(no GRTC changes)
4.5.0	(no GRTC changes)

More directly: nrfx_grtc_syscounter_cc_abs_set() on nrfx master is byte-for-byte identical to the 4.2.1 copy quoted above. The safe_setting branch is unchanged. Upgrading nrfx will not fix this.

History

nrfx 3.12.0 (2025-06-02) — "Added functions for setting compare value in an optimized way in the GRTC driver." This is where nrfx_grtc_syscounter_cc_abs_set() first appears, with the safe_setting branch as quoted.
Zephyr af3c8b973ed (2024-05-22) — "drivers: timer: nrf_grtc_timer: Fix for random system hangs" restored an early return in sys_clock_timeout_handler(), noting that without it "some stress tests which were using system timers heavily started to hang".
Zephyr d6fb9384ebf (2025-03-31) — "drivers: timer: nrf_grtc_timer: Optimize to reduce register access" introduced cc_value, expired_cc, LATENCY_THR_TICKS and the safe_setting path. Its commit message names the exact scenario that fails here:

If value in CC is earlier than the new CC value (if earlier timeout was aborted) then there is a risk of COMPARE event happening while it is being overwritten. That case requires long and safer procedure of setting CC.

The safer procedure prevents a spurious event. Nothing on either side prevents or detects a lost one.

The closest public report, DevZone 127458 ("NRF54L15 Timer interrupt not generating after few cycles"), describes the same shape and remains unanswered with no root cause.

Questions

Is the read-modify-write in the safe_setting branch of nrfx_grtc_syscounter_cc_abs_set() considered safe as written? It samples the SYSCOUNTER, decides, and then clears an event register that the hardware can set in between. Phase A settles the empirical half, so what is left is what nrfx intends here. Specifically: is the clear-before-write ordering under Our fix — the one nrfx_grtc_syscounter_cc_absolute_set() already uses, plus the retry that repairs an event left by the previous CC — acceptable as a fix, and is our reading correct that the retry is needed, i.e. that a spurious event on this path would be misinterpreted by the Zephyr system clock rather than tolerated?
Is there a documented minimum distance between a CC write and the SYSCOUNTER value at which the compare is guaranteed to fire? nrf_rtc_timer.c cites such a figure for RTC ("when the current counter value is N, a value of N+2 written to the CC register is guaranteed to trigger a COMPARE event at N+2"), and that driver additionally loops, re-reading the counter and re-arming until the CC verifiably lands in the future. We can find no equivalent statement for GRTC — the GRTC chapter of the nRF54L15 Product Specification resolves to register and SPU navigation only, with no functional description of compare-event generation or CC write latching. Phases A0 and B0 measure that a CC written into the past raises EVENTS_COMPARE anyway (including via the CCADD += 1 form the Zephyr driver emits for cyc == 0), but that is a measurement on one DK rather than a guarantee we can rely on.
Is LATENCY_THR_TICKS = 200 intended to bound this case? Despite the name it is compared against a cycle difference (prev_cc_val - now, in 1 MHz units), so it is a 200 us threshold, not 200 ticks (6.4 ms). Intended?
Should sys_clock_set_timeout() enforce a minimum forward distance on the absolute path? It currently computes now = last_count + last_elapsed, a software estimate rather than a hardware read, and on the path out of sys_clock_announce() that value is the expiry time of the timeout that just fired — stale by the interrupt latency plus every callback the announce loop ran. Combined with ticks == 0 being reachable, cc_value == now is expressible. The pre-d6fb9384ebf code read the counter at the point of the write and applied a MAX(..., 1) floor; both were removed.
Can the GRTC's CCEN behaviour be documented, or at least confirmed? The diagnosis above, and several of the eliminations, rest on it. Neither it, nor CC write latching, nor compare-event generation appears in the nRF54L15 Product Specification, and a measurement on a single DK is a thin foundation for a state machine.

devzone.nordicsemi.com/.../GRTC_2D00_CompareLoss_2D00_Reproduction.zip

Does single-cell location nrfcloud API work in India for Jio network?

anupamvarghese — Tue, 08 Sep 2026 14:05:38 GMT

Hi,

We are unable to get the correct location (even approximate) using the nrfCloud API for Location based on Single-Cell.
For the given
"mcc", "mnc", "tac" and "eci" combination, it seems to always return some location in Mumbai for a SIM being testing in Bangalore.

Could you please confirm Jio's NB-IoT tower network in India is mapped on your cloud?

Thanks.

- Anupam

nRF9151 DK: spi slave

Aparna Pacharne — Tue, 08 Sep 2026 09:51:11 GMT

I am using the nRF9151-DK as an SPI slave. The SPI communication is not working as expected, and the nRF9151-DK is not receiving any data from the SPI master.

I have configured SPIS3, but the SPI transfer callback is not receiving any data.

Environment:

Board: nRF9151-DK
nRF Connect SDK: v3.3.4
Zephyr: v4.3.99
Board target: nrf9151dk/nrf9151/ns
SPI peripheral: SPIS3

Programming external module over SWD using nrf7002dk

ccdev — Tue, 08 Sep 2026 06:30:41 GMT

I am using an nrf7002dk and my external modules have arrived. The external modules are Minewsemi MS12SF1, which is a combo of nrf5340 and nrf7002.

To start, I wanted to ensure that I am connecting the module correctly to the P20 custom SWD header on the dev kit. My goal is to flash the hello world sdk sample to the module. The problem I am having is that the module dopesnt appear to be connected, and I think I can confirm this using the JLinkExe (see output below).

I have things wired as follows:

P20 SWDIO -> module SWDIO

P20 SWDCLK -> module SWDCLK

P20 pin2 (VDD) -> module VCC

P20 pin3 (VTG) -> module VCC

P20 GND DETECT -> common GND

P1 GND ->common GND

module GND -> common GND

So as you can see, Im powering the module using the P20 pin2, as per the nordic documentation which states:

If it is inconvenient to have a separate power supply on the external board, the nRF7002 DK can supply power through pin 2 (VDD) of P20

(the full documentation for the nrf7002dk can be found here: https://www.farnell.com/datasheets/4628156.pdf)

I understand that the P20 pin2 will only provide 1.8v, so this feels like a catch22 situation because the MS12SF1 module requires ~3.v. If I power the module using the P20 header pin2, then it would seem Im not providing enough power to the module. Yet, if I power the module externally using a ~3v power supply, then there is a clear mismatch in voltage on the SWD line (1.8v vs 3v).

What can I do to solve this problem? My instinct tells me that I need to do one of the following:

1. logic level shifting on the swd line i.e 1.8v <> 3v

2. use a different dev kit that operates at 3v instead of 1.8v

3. just go ahead and try powering the module externally using 3v (and not simulataneously the 1.8v P20 pin2), and hope things dont get damaged.

What is the correct solution here?

FYI the reason I am confident that there is no connection being made between the dev kit and the module is that when i run JLinkExe, I always see the same output, whether the module is connected to the SWD line or not, i.e:

➜ hello_world_4 git:(master) ✗ JLinkExe
SEGGER J-Link Commander V9.74 (Compiled Sep 2 2026 12:36:32)
DLL version V9.74, compiled Sep 2 2026 12:35:17

Connecting to J-Link ...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Jun 11 2026 13:12:28
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 00m 07s
S/N: 1050780352
License(s): RDI,FlashBP,FlashDL,JFlash,GDB
USB speed mode: Full speed (12 MBit/s)
VTref=3.300V

Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: NRF5340_XXAA_APP
Type '?' for selection dialog

Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
T) cJTAG
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF5340_XXAA_APP" selected.

Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 6us
InitTarget() start
InitTarget() end - Took 3.32ms
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[1]: AHB-AP (IDR: Not set, ADDR: 0x00000000)
AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[3]: MEM-AP (IDR: Not set, ADDR: 0x00000000)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FE000
CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
Feature set: Mainline
Cache: No cache
Found Cortex-M33 r0p4, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
Security extension: implemented
Secure debug: enabled
CoreSight components:
ROMTbl[0] @ E00FE000
[0][0]: E00FF000 CID B105100D PID 000BB4C9 ROM Table
ROMTbl[1] @ E00FF000
[1][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
[1][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
[1][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
[1][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM
[1][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM
[1][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI
[0][1]: E0040000 CID B105900D PID 000BBD21 DEVARCH 00000000 DEVTYPE 11 TPIU

Memory zones:
Zone: "Default" Description: Default access mode
Cortex-M33 identified.

J-Link>mem32 0x00000000 16
00000000 = 200017A0 00000B81 000044A5 00000B6D
00000010 = 00000B6D 00000B6D 00000B6D 00000B6D
00000020 = 00000000 00000000 00000000 00000C51
00000030 = 00000B6D 00000000 00000DED 00000B6D
00000040 = 00000E65 00000E65 00000E65 00000E65
00000050 = 00000E65 00000E65

The last part always looks the same, which to me says that I am always reading the dev kit, even when the module is connected to the P20 header, i.e:

If the module was being detected, then i expect the output of this command would predictable change whether the module is connected or not because we would be reading memory from either the dev kit of the module.

nRF54L15: Can Direction Finding (AoA/AoD) and Channel Sounding both work on this chip?

Pravyuha — Tue, 08 Sep 2026 05:19:31 GMT

Hi,

Does the nRF54L15 support Direction Finding (AoA/AoD) and Channel Sounding together — i.e., can both features run on this specific chip, either simultaneously or at all?

I've seen Nordic staff confirm in other threads that AoA/AoD is "not supported" on the nRF54L series (e.g. case ID 343792), while Channel Sounding is supported. Can you confirm:

1. Does the nRF54L15 support AoA/AoD at all, currently or planned?
2. Does it support Channel Sounding? If yes, which NCS version/sample should I use to evaluate it?
3. If AoA/AoD is added in a future update, could it run alongside Channel Sounding on this same chip, or would the two be mutually exclusive on this silicon?
4. In the "AOA and AOD on nrf54L15" thread, a user mentioned they were able to add a CTE to advertising packets on the nRF54L15 (by adapting the direction_finding_connectionless_tx sample under NCS 3.1.1), and suggested this makes AoA work on this chip. Can you confirm whether this is genuinely functional, and if so, whether it would be reliable/accurate enough for practical AoA use, or if this is not officially supported/validated?

Problem installing CHIP tool

Jenzo — Mon, 07 Sep 2026 10:22:23 GMT

I am using SDK 2.7.0. When trying to install the CHIP tool, I get the error - view below.

I have tried everything - it seems that the OAuth client is hardcoded into the SDK. Could you please help with a remedy.

ERROR message:

BOOTSTRAP! Bootstrap may take a few minutes; please be patient.

Downloading and installing packages into local source directory:

Setting up CIPD package manager...[|]

Not logged in to CIPD and no anonymous access to the following CIPD paths:

fuchsia/third_party/zap

Attempting CIPD login

Getting a refresh token with following OAuth scopes:

* www.googleapis.com/.../userinfo.email

[P80629 11:42:32.287 client.go:357 W] RPC failed permanently: rpc error: code = PermissionDenied desc = OAuth client 446450136466-mj75ourhccki9fffaq8bc1e50di315po.apps.googleusercontent.com is not allowed {"host":"ci.chromium.org", "method":"CreateLoginSession", "service":"luci.auth.loginsessions.LoginSessions"}

Login failed: failed to create the login session: rpc error: code = PermissionDenied desc = OAuth client 446450136466-mj75ourhccki9fffaq8bc1e50di315po.apps.googleusercontent.com is not allowed

CIPD login failed

failed (3.9s)

Is AT%XMONITOR no longer supported with the serial modem app?

Daniel B. J. — Mon, 07 Sep 2026 09:50:52 GMT

Hi,

We use the nRF9151 modem and need the following data from it: Mobile Country Code (MCC), Mobile Network Code (MNC), Tracking Area Code (TAC), cell_id and rsrp.

We have used the AT%XMONITOR command for this before, but I can't seem to find anything other than a minor mention in an .obj and .a file with the serial modem app v2.0.0.

Is the AT%XMONITOR command no longer supported? And if so what would be the recommended command to get the information we need?

Thank you in advance.

Best regards,

Daniel.

nRF5340 LE Audio: Audio quality randomly good or degraded depending on connection with Google Pixel 7

Raphael01 — Mon, 07 Sep 2026 07:07:04 GMT

Hello,

we are currently developing a device based on the nRF5340 using LE Audio.

The device streams audio to a smartphone, where the corresponding Android application can record the incoming audio stream.

Our software is based on the nRF5340 Audio Unicast Server application from nRF Connect SDK v3.1.1.

Due to hardware constraints, the nRF5340 has to operate as an I2S slave. The external I2S source provides a sample rate of approximately 46.875 kHz, while the LE Audio/LC3 pipeline operates at 48 kHz.

To compensate for this difference, we implemented a resampling stage using the ratio 125:128, converting the incoming I2S audio to 48 kHz before passing it to the LC3 encoder.

With a Samsung Galaxy S25, the audio quality is consistently good.

With a Google Pixel 7, however, the behavior is different: after establishing the LE Audio connection, the audio quality is either good or noticeably degraded/“robotic”. Once the connection is established, the quality remains in that state for the entire connection. Reconnecting or restarting the device can result in either a good or a bad connection again.

This makes us suspect that the issue may not be caused by the resampling itself, but rather by something that is configured or initialized during LE Audio stream establishment.

Could this behavior be related to the negotiated BAP/ASE/CIS/QoS configuration, ISO timing, or another Android-specific LE Audio configuration?

Are there any known differences or issues with Pixel devices in this regard, or any LE Audio parameters/callbacks we should specifically check to determine why one connection starts in a good state while another starts in a degraded state?

Thanks in advance for your help.

Best regards,
Raphael

nRF52840 chip have SIL‑compliant

Sam01234 — Mon, 07 Sep 2026 05:29:11 GMT

Does the nRF52840 chip have SIL‑compliant functional safety libraries according to the IEC 61508 standard?

[Design Review] nRF52840 Custom Board - Schematic & Layout Check

Van Le — Mon, 07 Sep 2026 04:26:51 GMT

Hi Nordic Support Team,

I have designed a custom board based on the nRF52840 and would appreciate it if you could review my schematic and PCB layout before I proceed with manufacturing.

Here are the specifications of my design:
- Target IC: nRF52840-QFAA (Package: QFN-48 / WQFN-48, 6x6 mm)
- Power Supply: 3.7V LiPo battery charged via TP4056 with DW01S/FS8205A protection, regulated down to 3.3V via external LDO (AP2112K-3.3) feeding into VDD pins. (Normal Voltage Mode)
- DC/DC Regulators: Enabled (DC/DC mode using external inductors L1 = 10uH on DCC and L2 = 15nH on DEC4/DEC6)
- HF Clock: 32 MHz external crystal (X1: 3225 12pF with 12pF load capacitors)
- LF Clock: 32.768 kHz external crystal (X2: 3215 12.5pF with 12pF load capacitors)
- Antenna type: 2.4 GHz Meandered Inverted-F PCB Trace Antenna (MIFA) with an LC matching network (L3 = 4.7nH, C13 = 1pF, C14 = 1.2pF, L4 = 2.2nH)
- Additional RF: Integrated PCB NFC antenna coil tuned with 91pF capacitors (C24, C26)
- PCB Stackup:
* Total Layers: 2-layer
* Total Board Thickness: 1.6 mm (Standard FR-4, Er ~ 4.4, 1 oz copper)
* Distance from Top Layer to Bottom GND Reference Plane: ~1.5 mm

I have attached the design archive containing:
1. Schematic (PDF & native design files)
2. PCB Layout (Gerber files / native design files)
3. Bill of Materials (BOM)

Specific points I would like feedback on:
1. RF transmission line layout and matching network values for the 2.4 GHz MIFA antenna.
2. DC/DC regulator circuitry routing (DCC, DEC4/DEC6 inductors and caps).
3. Decoupling capacitor placement and ground return path integrity under the MCU.
4. NFC antenna trace geometry and tuning capacitor values.

Thank you very much for your support!

nRF54LM20A

z c — Mon, 07 Sep 2026 03:46:29 GMT

How much current budget should I provide for the VBUS pin of the nRF54LM20A?

nRF93M1: plans to expose LTE Timing Advance through the AT command interface?

ing-barbiz — Sun, 06 Sep 2026 21:23:14 GMT

Hello Nordic Support,

I am developing a cellular positioning solution using an nRF93M1 LTE Cat 1 bis module.

I currently use the following command to retrieve the serving cell and neighboring-cell measurements:

AT%BCINFO=3,20

The command provides:

- EARFCN
- PCI
- RSRP
- RSRQ
- MCC/MNC
- E-UTRAN Cell ID
- TAC

However, it does not appear to provide the LTE Timing Advance for the serving cell.

On the nRF91/nRF91x1 family, the %NCELLMEAS response includes a
<timing_advance> field and its measurement timestamp. I could not find an
equivalent documented command or response field in the current nRF93M1 AT
Commands Reference Guide.

Timing Advance would be useful for improving third-party cellular positioning
requests, for example when using APIs that accept the serving-cell Timing
Advance in addition to ECI, TAC, PCI, EARFCN, RSRP, and neighbor measurements.

Could you please clarify:

1. Is the serving-cell Timing Advance currently available through any nRF93M1
AT command or diagnostic interface?
2. If not, is support planned for a future nRF93M1 module firmware release?

Thank you

marco

Achieving pin retention in nRF54L15 GPIO without hardware pull-up through sys_reboot()

htownclyde — Fri, 04 Sep 2026 15:46:20 GMT

Hi,

I have encountered a challenge with the nRF54L15 that I am hoping someone might know a solution for!

My device has a power enable pin (on GPIO1) that must ideally *always* remain HIGH. Unfortunately, it has no HW pull-up and one cannot be added.

So through software, I would like to keep this pin HIGH through sys_poweroff(), jumping to MCUboot, and resetting out of MCUboot.

My finding so far: The nRF54L15 has automatic pin retention for all GPIOs, but *only* through sys_poweroff() as it appears to be mainly intended as a power-saving feature to mitigate current leakage.

My challenge: Dropping into MCUboot from appcode hits a warm sys_reboot() - which clears the pin for ~5ms, and is problematic in my design.

My solution so far is just to intercept all problematic sys_reboot() calls and instead use a scheduled GRTC wakeup + sys_poweroff() to keep pin retention, but ideally I don't want to have to do this.

TLDR: Is there any way to (without a dedicated HW pull-up) configure a GPIO on nRF54L15 to survive a sys_reboot() call?

Thank you!

PSA protected storage, encryption keys and FOTA

Tom01 — Fri, 04 Sep 2026 10:47:19 GMT

Dear Nordic team,

we are developing an application for a nRF9151 which will perform some HTTPS requests. For that purpose we want to encrypt and store an API key (string of max. 32 characters). We are working with the non-secure board target and SDK v3.3.0. Our application was initially based on the "https_client" sample which uses the minimal TF-M profile for the nRF9151 DK board. We are aware that PSA protected storage is only available for the non-minimal TF-M profile. Additionally, we are planning to implement a FOTA procedure using the available libraries. To plan ahead, we have some questions regarding the persistence of the protected storage, generated encryption keys and dependencies of the FOTA libraries.

Are PSA protected storage's key-value pairs persistent across firmware updates (e.g. FOTA) as long as the TF-M layout and its profile remain unmodified?
Are encryption keys (like the one generated in the "persistent_key" sample) persistent across firmware updates (e.g. FOTA) as long as the TF-M layout and its profile remain unmodified?
Is the PSA protected storage a valid place to store information like API keys?
Does FOTA support directly rely on using the non-minimal TF-M profile or could we stick with the minimal profile?

Best regards,

Tom

l0destar - ultra low-power open-source hardware and software vehicle tracker you can build at home

m4rkw — Fri, 04 Sep 2026 10:31:39 GMT

This isn't about a problem so I'm not sure if this is an inappropriate post to make here, if so please feel free to remove it, however there is no commercial incentive to this so hopefully it will be received positively.

I am building a completely open-source vehicle tracker that anyone can build at home - https://l0destar.com - making use of the nRF9151 SIP via the Makerdiary Connect Kit.

Thanks in part to the incredible power efficiency of the nRF9151 it currently achieves a sleep current of around ~120uA (yes, microamps) with the accelerometer armed and waking on movement or impact.

I have working prototypes and have tracked about 85 miles so far in my own car with no problems.

Anyone reading this and wishing to offer feedback, ideas, suggestions or anything else in relation to it would be most welcome 🙂

Mark

Clarification on CE RED Compliance of nRF52840 Variants

Gowsika — Fri, 04 Sep 2026 09:26:06 GMT

Hello Nordic Semiconductor Team,

I would like to clarify a component change in our Bluetooth device design.

In our previous product, we used the nRF52840-QIAA-R component, whereas in our new product we are using the nRF52840-QIAA-F-R component.

Could you please confirm whether both components have the same compliance status with respect to CE RED requirements, including EMC, RF, and Safety standards? We would like to understand if the component change has any impact on CE RED certification and compliance.

Thank you for your support.

Best regards,

Gowsika G

NRF_MODEM_LIB_MEM_DIAG_ALLOC Kconfig setting needs log but increments the failed allocs (which is not only used for logging statistics but for diagnosis as well).

Peter Horauer — Fri, 04 Sep 2026 07:30:13 GMT

I am using the SDK v3.4.0 LTS

for modem error debugging I included:

prj.conf

CONFIG_NRF_MODEM_LIB_MEM_DIAG=y

# depends on CONFIG_LOG=y
CONFIG_NRF_MODEM_LIB_MEM_DIAG_ALLOC=y

I am mapping errors depending on wether memory allocations failed.

I am fetching the stats with nrf_modem_lib_diag_stats_get() and checking wether the stats.library.failed_allocs and stats.shmem.failed_allocs have incremented since last check. But these values are always passed as 0 when CONFIG_NRF_MODEM_LIB_MEM_DIAG_ALLOC is not set to =y as the internal counter is only incremented when it the Kconfig is set.

nrf_modem_os.c

void *nrf_modem_os_alloc(size_t bytes)
{
	extern uint32_t nrf_modem_lib_failed_allocs;
	void * const addr = k_heap_alloc(&nrf_modem_lib_heap, bytes, K_NO_WAIT);

	if (IS_ENABLED(CONFIG_NRF_MODEM_LIB_MEM_DIAG_ALLOC) && !addr) {
		nrf_modem_lib_failed_allocs++;
	}

	return addr;
}

void *nrf_modem_os_shm_tx_alloc(size_t bytes)
{
extern uint32_t nrf_modem_lib_shmem_failed_allocs;

#if (CONFIG_SOC_SERIES_NRF92 && CONFIG_DCACHE)
/* Allocate cache line aligned memory. */
void * const addr = k_heap_aligned_alloc(&nrf_modem_lib_shmem_heap, CONFIG_DCACHE_LINE_SIZE,
ROUND_UP(bytes, CONFIG_DCACHE_LINE_SIZE), K_NO_WAIT);
#else
void * const addr = k_heap_alloc(&nrf_modem_lib_shmem_heap, bytes, K_NO_WAIT);
#endif

if (IS_ENABLED(CONFIG_NRF_MODEM_LIB_MEM_DIAG_ALLOC) && !addr) {
nrf_modem_lib_shmem_failed_allocs++;
}

return addr;
}

I have now implemented a workaround so CONFIG_LOG does not have to be used for this to work correctly with a custom Kconfig definition like the following:

Kconfig

config NRF_MODEM_LIB_MEM_DIAG_ALLOC
bool
default y if NRF_MODEM_LIB_MEM_DIAG

I do not understand why NRF_MODEM_LIB_MEM_DIAG_ALLOC depends on LOG, as it not only adds log functionality but also a counts the failed allocations inside the library. It seems like a bug to me that would not report the correct values for failed allocations if NRF_MODEM_LIB_MEM_DIAG_ALLOC is not used (which depends on LOG if not set otherwise like in my workaroung).

Nordic Q&A - Recent Threads

nRF5 SDK 17.1.0: Numeric Comparison pairing dialog on phone fails to dismiss after peripheral rejects pairing

nRF52840: QSPI pin configuration confirmation

Cannot get whitelisted for ant-nrfconnect/sdk-ant github repository

Increased current consumption on nrf54l15 + s145

nrf54LM20A SPI_MOSI pin not working

Problems flashing non-secure apps to nrf7002dk

tcp sendmsg() EAGAIN handling

tcp mss vs mtu

System clock stops permanently after a GRTC compare event is lost

nRF54L15: system clock stops permanently after a GRTC compare event is lost

Disclaimer

Summary

Environment

Symptom

State captured at the hang

Reproduction 1 — established that no software path had suppressed the interrupt

Reproduction 2 — identified the mechanism

Mechanism

Why it is permanent

Standalone reproduction

Phase A — the nrfx race in isolation (CONFIG_GRTC_REPRO_ISOLATED)

Phase B — the tick stall through the public API (CONFIG_GRTC_REPRO_TICK_STALL)

What we ruled out

Software suppression of the interrupt

SYSCOUNTER sleep / CC latch latency — ruled out by experiment

CC written into the past, or lost in the CCL -> CCH write window — ruled out by the CCEN reading

Other channel owners disabling CCEN on channel 6 — excluded by inspection of the source for this build configuration

MPSL interference — only partly excluded

Silicon anomalies

Open points

Our fix

Upstream status (checked 2026-09-08)

Zephyr

nrfx

History

Questions

Does single-cell location nrfcloud API work in India for Jio network?

nRF9151 DK: spi slave

Programming external module over SWD using nrf7002dk

nRF54L15: Can Direction Finding (AoA/AoD) and Channel Sounding both work on this chip?

Problem installing CHIP tool

Is AT%XMONITOR no longer supported with the serial modem app?

nRF5340 LE Audio: Audio quality randomly good or degraded depending on connection with Google Pixel 7

nRF52840 chip have SIL‑compliant

[Design Review] nRF52840 Custom Board - Schematic & Layout Check

nRF54LM20A

nRF93M1: plans to expose LTE Timing Advance through the AT command interface?

Achieving pin retention in nRF54L15 GPIO without hardware pull-up through sys_reboot()

PSA protected storage, encryption keys and FOTA

l0destar - ultra low-power open-source hardware and software vehicle tracker you can build at home

Clarification on CE RED Compliance of nRF52840 Variants

NRF_MODEM_LIB_MEM_DIAG_ALLOC Kconfig setting needs log but increments the failed allocs (which is not only used for logging statistics but for diagnosis as well).

Phase A — the nrfx race in isolation (`CONFIG_GRTC_REPRO_ISOLATED`)

Phase B — the tick stall through the public API (`CONFIG_GRTC_REPRO_TICK_STALL`)