Nordic Q&A - Recent Threads

Guidance Required for nRF9151 Antenna RF Certification Testing and VNA Validation

Milan Pipaliya — Sat, 13 Jun 2026 05:44:48 GMT

Hello Nordic Community,

We are developing a custom product based on nRF9151 using NCS SDK v3.1.0.

On the hardware side, we have already completed antenna matching and tuning activities, including component optimization of the matching network. We are currently performing VNA (Vector Network Analyzer) measurements to verify antenna performance (S11/Return Loss) across the required LTE frequency bands.

For RF validation and certification preparation, we would like guidance on the recommended testing methodology from Nordic.

We found the following modem RF test command:

AT%XRFTEST=1,1,28,7000,23,1,4,1,0,0,0,0

Example configuration:

Band 28
700 MHz
LTE-M (Cat-M1)
+23 dBm TX Power
CW Modulation

Our current validation approach includes:

Antenna tuning and matching network optimization.
VNA measurements (S11/Return Loss).
Firmware-based RF transmission testing using %XRFTEST.
Planned conducted and radiated measurements in an RF laboratory.

We would appreciate guidance on the following:

Is %XRFTEST the recommended and valid method for RF antenna testing and certification preparation on nRF9151?
Which firmware/modem firmware version is recommended for laboratory RF testing?
After VNA verification, what additional RF validation steps are recommended by Nordic before certification?
Are there specific Nordic procedures for:
- Conducted TX measurements
- Radiated antenna measurements
- Output power verification
- Band and frequency verification
- LTE-M certification pre-compliance testing
Can certification-related RF measurements be performed using firmware-controlled test commands such as %XRFTEST, or is there a dedicated Nordic test methodology that should be followed?
Are there any limitations of %XRFTEST when compared to certification lab test procedures?

We are looking for guidance on the complete validation flow, including antenna tuning, VNA measurements, firmware-based RF testing, and certification testing for an nRF9151-based design.

Thank you for your support and guidance.

Best Regards,
Milan

Fetching RSSI values while synced on a BIS

Ran531 — Fri, 12 Jun 2026 21:27:30 GMT

Hello,

We are trying to assess signal quality while synced to a BIS and we would like to use the RSSI values. RSSI values do show up when scanning and at least in the Auracast sample, scanning stops once we sync on the PA. Also, RSSI from advertisement values do not represent the actual LE Audio stream RSSI?

I know about the HCI command to read RSSI, but it requires a connection handle which I don't have? Does that even make sense in a broadcast scenario? If it does where can I find the relevant connection handle for the BIS or BIG if synced on more than one channel?

Request for Thermal Specifications and Thermal Validation Data of nRF54L15

yui1021 — Fri, 12 Jun 2026 17:23:34 GMT

Hi Nordic Team,

We are currently evaluating nRF54L15 for our product design and thermal verification process.

According to the public datasheet, we can find the operating ambient temperature range (TA) as well as package thermal resistance data (θJA and θJC). However, we could not find the following thermal specifications which are typically required for our thermal design review and reliability assessment.

Could you please provide:

1. Maximum Junction Temperature (TJ Max)

2. Maximum Case Temperature or TC Criteria

3. Thermal Simulation Report

4. Thermal Test / Validation Report

5. Any available thermal qualification or reliability documentation related to package thermal performance

6. Additional thermal parameters if available (e.g. ΨJT, ΨJB, θJB)

These thermal parameters are commonly required during system thermal analysis and component qualification.

If the information is not publicly available, please advise whether it can be provided under NDA.

Thank you for your support.

Configuration to write external flash memory using nrfutil tool

Alessio Lei — Fri, 12 Jun 2026 14:55:25 GMT

I'm setting up a script we will use at production time to write some data to an external flash module connected via SPI to a nRF54H20.

I used the following as reference document https://docs.nordicsemi.com/r/bundle/nrfutil/page/nrfutil-device/guides/programming_external_memory.html?tocId=VZmfjI%7E3lJLxXfQxc5L%7E7g

I am passing the following JSON to nrfutil 2.19.0 (i used the structure passed in the example for nRF54L15 in the page above)

{
"firmware_config": {
"peripheral": "EXMIF"
},
"pins": {
"csn": 195,
"io0": 199,
"io1": 197,
"io2": 202,
"io3": 201,
"sck": 192
},
"flash_size": 8388608,
"page_size": 4096,
"sck_frequency": 6400000,
"address_mode": "MODE24BIT"
}

and i get the error

Device error: Failed to load the external flash config: Configuration file parsing failed: missing field `reset` at line 12 column 5 (Generic)

Is it possible to have the expected JSON structure or a link where to find it?

Thanks,

Alessio

nrf5340 BAP_BROADCAST_SOURCE sample region `RAM' overflowed occur.

orip — Fri, 12 Jun 2026 10:42:52 GMT

Bros, I had updated ncs sdk from v3.1.1 to v3.3.1 today, and when I rebuild an nrf5340 project found that NETAPP ram overflowed, and the error could be represented by build the bap_broadcast_source sample, the netapp only has 64k sram, so that means overflowed by 8k can't be settle by tuning parameter, so how to sovle it

c:/ncs/toolchains/936afb6332/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr_pre0.elf section `noinit' will not fit in region `RAM'
c:/ncs/toolchains/936afb6332/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `RAM' overflowed by 7796 bytes

nrf82540 Dongle - reducing consumption during sleep.

Jarostr — Fri, 12 Jun 2026 10:29:04 GMT

Hello.

I need some advice - I'm a beginner. I tested the transition to sleep mode via __WFI for the nrf52840 Dongle (VS code, SDK v3.3.0). I need some advice - I'm a beginner. For nrf52840 Dongle (VS code, SDK v3.3.0) I tested sleep mode via __WFI. Sleep mode works, but I had to disable interrupts from RTC1. I solve the wakeup with an interrupt from RTC0 - I attach an code. In sleep mode the consumption is about 1.6mA. Can you advise me what and how to turn off (setup) so that the consumption is as low as possible when SYSTEM ON. I'll need to go back after the circuit wakes up. Thank you.

devzone.nordicsemi.com/.../2234.main.c

Dynamic modification advertising public address

nanty — Fri, 12 Jun 2026 08:47:08 GMT

Hi,

I want to set my BLE advertising as public adress Dynamic, and can't work. I have try reboot,, and call "bt_ctlr_set_public_addr" before "bt_enable", It is working first time. In second time, the advertising was change successful, but the address in "bt_id_get(addrs, &count)" was different, and when I do pair with phone always fail, seems like the advertising address must same with SETTING?

nRF54L15: high current consumption after using FPU, need information about FPU_IRQn interrupt vector.

Frank Viganske — Fri, 12 Jun 2026 08:39:56 GMT

Hi,

i am working on a project using the nRF54L15.

Hardware: custom board with nRF54L15

Software:

Wirepas SDK (1.6.2)
nrfx drivers (version 3.9.0) with some customization to integrate it into the SDK
CMSIS DSP floating point libraries (Version 5.1)

I see in my current measurements that idle current increases by roughly 300µA after using the floating point unit. I already checked the developer zone for any similar tickets, and there are lots of them, though all are for other SoC, like nRF52 series.

Most of these tickets suggest the high current consumption comes from unhandled FPU interrupts. I was already able to confirm that this is indeed the reason for the increased current. Now i'm trying to implement a solution for this.

The suggested solution from other tickets is to do something like the code below:

__STATIC_INLINE void pwr_mgmt_fpu_sleep_prepare(void)
     {
        uint32_t original_fpscr;

        CRITICAL_REGION_ENTER();
        original_fpscr = __get_FPSCR();
        /*
         * Clear FPU exceptions.
         * Without this step, the FPU interrupt is marked as pending,
         * preventing system from sleeping. Exceptions cleared:
         * - IOC - Invalid Operation cumulative exception bit.
         * - DZC - Division by Zero cumulative exception bit.
         * - OFC - Overflow cumulative exception bit.
         * - UFC - Underflow cumulative exception bit.
         * - IXC - Inexact cumulative exception bit.
         * - IDC - Input Denormal cumulative exception bit.
         */
        __set_FPSCR(original_fpscr & ~0x9Fu);
        __DMB();
        NVIC_ClearPendingIRQ(FPU_IRQn);
        CRITICAL_REGION_EXIT();

        /*
         * The last chance to indicate an error in FPU to the user 
         * as the FPSCR is now cleared
         *
         * This assert is related to previous FPU operations 
         * and not power management.
         *
         * Critical FPU exceptions signaled:
         * - IOC - Invalid Operation cumulative exception bit.
         * - DZC - Division by Zero cumulative exception bit.
         * - OFC - Overflow cumulative exception bit.
         */
        ASSERT((original_fpscr & 0x7) == 0);
     }

That is, 1. clear the FPU exception bits in FPSCR, 2. clear the pending IRQ with NVIC_ClearPendingIRQ(FPU_IRQn);

Which brings me to my problem. I can't find any definition for FPU_IRQn for the nRF54L15, neither in the Nordic Documentation nor in any of the processor header files.

For other SoCs FPU_IRQn is defined as an enum value in IRQn_Type. For the nRF54L15, in nrf54l15_application.h there is a similar type definition for IRQn_Type, but it does not contain the FPU_IRQn.

Maybe it is just named differently?

So my question is: how do i clear the pending IRQ for the FPU on the nRF54L15?

Best regards

Frank Viganske

nRF54LM20A-CAAA PCB Library Verification

YOUNGKEE JUNG — Fri, 12 Jun 2026 08:34:02 GMT

Dear Nordic Support Teams,

Could you please verify that the nRF54LM20A-CAAA(CSP-61) PCB library has been drawn correctly?

The file was created using PADS Layout VX2.13.

Thanks,

Deega(YK) Jungdevzone.nordicsemi.com/.../NRF54LM20A_2D00_CAAA_5F00_CSP61_5F00_LIB.pcb

SUPL-C license has been denied

DzungLuu — Fri, 12 Jun 2026 06:50:27 GMT

Hello,

As the title says I was denied supl license. Really not sure why it was denied. Could someone check this out please?

Thanks,

DzungLuu

OTA Automatically Reset and Start the Application After Flashing a Merged Hex File

Embel_Tech — Fri, 12 Jun 2026 06:27:55 GMT

Hello Nordic Team,

I am working on the nRF52833 using nRF5 SDK 17.1.0 and i have implemented OTA DFU in our application. in OTA We have merged all firmware into a single HEX file and flashed it to the device. after flashing the merged HEX file. We need to manually reset or power-cycle the hardware for the application to begin running.

Our requirement is for the device to reset automatically through firmware/software after flashing is completed. We do not want to send a reset command manually or perform a hardware through reset.

I will share the scenario

Generated Bootloader DFU settings .hex file and stored it in: bl_settings.hex

Bootloader DFU Settings:
* File: bl_settings.hex
* Family: nRF52
* Start Address: 0x0007F000
* CRC: 0x41774DEA
* Settings Version: 0x00000002 (2)
* App Version: 0x00000001 (1)
* Bootloader Version: 0x00000001 (1)
* Bank Layout: 0x00000000
* Current Bank: 0x00000000
* Application Size: 0x0000F0E4 (61668 bytes)
* Application CRC: 0xD9F2EDB8
* Bank0 Bank Code: 0x00000001
* Softdevice Size: 0x00000000 (0 bytes)
* Boot Validation CRC: 0xE22406CE
* SD Boot Validation Type: 0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

C:\Users\admin>mergehex --merge s140_nrf52_7.2.0_softdevice.hex secure_bootloader_ble_s140_pca10100.hex Echo_UnderDash_II.hex bl_settings.hex --output final_dongle.hex
Parsing input files.
Merging file "s140_nrf52_7.2.0_softdevice.hex" into output.
Merging file "secure_bootloader_ble_s140_pca10100.hex" into output.
Merging file "Echo_UnderDash_II.hex" into output.
Merging file "bl_settings.hex" into output.
Storing merged file.

C:\Users\admin>nrfjprog --eraseall
Erasing user available code and UICR flash areas.
Applying system reset.

C:\Users\admin>nrfjprog --program final_dongle.hex --verify
[ #################### ] 3.035s | Program file - Done programming
[ #################### ] 2.965s | Verify file - Done verifying

i want After flashing, the device should reset automatically and start the application.

We do not want to send a reset command manually or perform a hardware reset.

We do not want to use the nrfjprog --reset command. The device should automatically reset and start the application through firmware/software after the flashing process is completed, without requiring any manual reset command or hardware reset.

Thanks,

Embel.Tech

How to Automatically Reset and Start the Application After Flashing a Merged Hex File in OTA

Rohit15 — Fri, 12 Jun 2026 04:51:33 GMT

Dear Nordic Team,

We are working with the nRF52833 using nRF5 SDK 17.1.0 and have implemented OTA DFU in our application.in OTA We have merged all firmware components (Application, Bootloader, and , SoftDevice ) into a single HEX file and flashed it to the device. that Currently, after flashing the merged HEX file. We need to manually reset or power-cycle the hardware for the application to begin running.

Our requirement is for the device to reset automatically through firmware/software after flashing is completed. We do not want to send a reset command manually or perform a hardware through reset

\Users\admin>nrfutil settings generate --family NRF52 --application Echo_UnderDash_II.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 bl_settings.hex

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: bl_settings.hex

C:\Users\admin>nrfjprog --eraseall
Erasing user available code and UICR flash areas.
Applying system reset.

C:\Users\admin>nrfjprog --program final_dongle.hex --verify
[ #################### ] 3.035s | Program file - Done programming
[ #################### ] 2.965s | Verify file - Done verifying

After flashing, the device should reset automatically and start the application.

We do not want to send a reset command manually or perform a hardware reset. The device should automatically reset through firmware/software after the flashing process is completed. i want reset automatic and start application.

How to read reset reason on nRF54H20 using nrfx API?

lammobile — Fri, 12 Jun 2026 02:07:05 GMT

Hi Nordic team,

I am working with the nRF54H20 and would like to programmatically read the reset reason after startup.

The product specification lists the following reset sources for the nRF54H20 on Figure 71: Reset sources

Which API or register should I use to read the reset reason on the nRF54H20? (e.g., nrfx_reset_reason_get() or nrf_reset_resetreas_get(NRF_RESET)?)

Thanks,

Series Resistor on VBUS

Arielle — Thu, 11 Jun 2026 21:48:18 GMT

Hi! Do people actually use the 2.2-4.7Ohm series resistor on the VBUS input to the nRF5340? It's just such a low resistance, I don't particularly see the point. Thanks!

"real-time" tracking with the NRF9151

m4rkw — Thu, 11 Jun 2026 20:16:59 GMT

I want to achieve as close as possible to real-time tracking with the nRF9151. Because of the shared RF path this is somewhat tricky, LTE and GNSS can't run simultaneously. Initially I was running into the carrier-side RRC timeout but figured out how to make RAI work to get around it.

I've now managed to get the GPS read -> send loop down to roughly one event per 2-3 seconds. I suspect this is probably at the limit of what's possible with this SIP because it looks like almost that entire interval is GPS but I thought I'd post here just in case there are some other tricks I've missed.

For reference I'm using my own server on a very fast connection and the traffic is using DTLS. Obviously I can batch the records to eliminate the gaps but I'm aiming for high resolution near-realtime tracking. With an older device that had a GPS chip that was separate from the modem real-time 1Hz was possible, still hoping there might be a way to get near this with the nRF9151.

Thanks,
Mark

trying to send and receive the data through can bus moduler using with nrf9160 and esp32 controller (using SPI)

Vivek01 — Thu, 11 Jun 2026 19:51:18 GMT

Hi,

can anyone help me with this situations that i'm facing from a 1 month so i'm connecting esp32 controller to seengreat RS485 Dual CAN Bus moduler and the other hand i'm connecting nrf9160 to seengreat RS485 Dual CAN Bus moduler but i can't send or receive any messages through this and i attach the both screenshot from nrf serial terminal and from esp32 controller terminal and also i attach my overlay code and my both project files. i tried with 125,250,500 KBPS bus speed but i didn't make it and this can bus moduler have 16MHZ and it has 120 ohm resister attached with the moduler and i tried spi-max-frequency = <125000>,<250000>, <500000>, <1000000>.devzone.nordicsemi.com/.../WACS-_2800_2_2900_.zip devzone.nordicsemi.com/.../WACS_5F00_esp32-_2800_2_2900_.zip

here is my overlay file code

// can mcp2515 drivers overlay

&pinctrl {

spi3_default: spi3_default {

group1 {

psels = <NRF_PSEL(SPIM_SCK, 0, 13)>,

<NRF_PSEL(SPIM_MOSI, 0, 11)>,

<NRF_PSEL(SPIM_MISO, 0, 12)>;

};

spi3_sleep: spi3_sleep {

group1 {

psels = <NRF_PSEL(SPIM_SCK, 0, 13)>,

<NRF_PSEL(SPIM_MOSI, 0, 11)>,

<NRF_PSEL(SPIM_MISO, 0, 12)>;

low-power-enable;

};

/ {

chosen {

zephyr,canbus = &mcp2515;

};

&spi3 {

compatible = "nordic,nrf-spim";

status = "okay";

pinctrl-0 = <&spi3_default>;

pinctrl-1 = <&spi3_sleep>;

pinctrl-names = "default", "sleep";

cs-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;

mcp2515: can@0 {

compatible = "microchip,mcp2515";

reg = <0>;

spi-max-frequency = <250000>;

int-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;

osc-freq = <16000000>;

bus-speed = <250000>;

status = "okay";

};

// UART overlay

&uart2 {

status = "okay";

current-speed = <115200>;

};

i spend too much time on this and still didn't get anything from this so please help me to get through with this and what else i can do for debugging cuz i change the wires many times and now i order new can bus moduler to get confirmation about that is the moduler don't have the problem or what, i don't know

thanks
vivek

Sanity-checking interest: nRF5340 board with integrated CMSIS-DAP debug + jumper-based current measurement, under the DK's price

whitehand110 — Thu, 11 Jun 2026 19:47:46 GMT

Hi all — I'm developing a custom nRF5340 development board (Raytac MDBT53-1M) and would value the community's honest read on whether it's worth producing.

The goal is a board optimized for the flash–debug–power-profile iteration loop, using open-source tooling.

Key features:
- Onboard CMSIS-DAP debugger (RP2040 + debugprobe firmware): full SWD flash and live debug over USB-C, working directly with probe-rs, OpenOCD, pyOCD, and the nRF Connect SDK / Zephyr toolchain.
- Current measurement without board modification
- LiPo charging with load-sharing power path for battery-powered prototyping.
- Arduino-compatible + dual GPIO headers, Qwiic, USB-C, NFC connection.

Intended price: ~$44*

To be clear, the DK is excellent. What I'm testing is whether out-of-the-box measurement, open CMSIS-DAP tooling, and battery charging are worth anything to people here, or whether the DK already meets your needs.

Would this fit into your workflow? What would you change or add? If you'd want one, I'd appreciate a note here or a signup on the waitlist so I can gauge whether to do a production run: forms.gle/V1ZPMtDSSYrA95TK9

Thank you for any feedback.

Guideline for nRF5340 network-core FOTA over MCUmgr (with app-core rollback)

SelracElosUarg — Thu, 11 Jun 2026 18:45:11 GMT

Environment

nRF Connect SDK: v3.2.1
Zephyr: 4.2.99 (NCS fork)
CMake (bundled): 3.21.0
Board: nrf5340dk_nrf5340_cpuapp
OS: Linux

What already works: application-core FOTA (image 0)

This has worked reliably for a long time:

mcumgr ... image upload -e -n 0 app.signed.bin
mcumgr ... image list          # note new hash in slot 1
mcumgr ... image test <hash>
mcumgr ... reset
mcumgr ... image confirm <hash>

Swap + revert behave exactly as expected.

Goal

Add network-core (hci_ipc) FOTA through MCUmgr in the same way (image 1), without losing the application core's swap/revert.

Config we added

# sysbuild
SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_NETCORE_APP_UPDATE=y
# application prj.conf
CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2

Network-core FOTA steps we follow

mcumgr ... image upload -e -n 1 signed_by_mcuboot_and_b0_hci_ipc.bin
mcumgr ... image list          # image=1 slot=1 appears, secondary magic=good
mcumgr ... image confirm <hash>
mcumgr ... reset               # -> device bricked, only recoverable with: nrfjprog --qspieraseall

What we have tried

In every combination below, staging works fine (image upload -n 1 → image=1 slot=1, magic=good), but the result is always the same: after image test/confirm + reset, the device bricks (reboot loop, only recoverable with nrfjprog --qspieraseall).

A) SECURE_BOOT_NETCORE + NETCORE_APP_UPDATE only (app core keeps BOOT_SWAP_USING_MOVE). → Brick on reset. RTT shows MCUboot validating image 1 OK, then abort() right after boot_verify_slot_dependencies. The net image seems to go through the app-core swap path. We noticed the network-core swap-skip in boot_slots_compatible() (swap_move.c) is guarded by #ifdef PM_S1_ADDRESS, which is undefined in this config.
B) Added SECURE_BOOT_APPCORE too (to define PM_S1_ADDRESS). → Build assert PM_S0_SIZE == PM_S1_SIZE; fixed by removing our explicit CONFIG_PM_PARTITION_SIZE_MCUBOOT so PM sizes S0/S1 equally. The device still bricks on reset — now apparently later, possibly during the PCD copy to the network core.
We have not switched MCUboot to OVERWRITE_ONLY (used by the NCS ref_smp_svr_ext_flash sample for nRF53), because it removes the application core's revert capability, which we need to keep.

So we seem to be missing a config combination: every variant we tried either bricks immediately or bricks "later", always around the network-core update on reset.

Question

Is there a documented minimal configuration for nRF5340 network-core FOTA over MCUmgr (image 1) that coexists with application-core image swap + revert — i.e. without forcing MCUboot into OVERWRITE_ONLY? Does enabling network-core update with BOOT_SWAP_USING_MOVE on the app core require application-core secure boot (B0), or is there a supported combination we are missing?

A reference set of Kconfig options for this exact case would be ideal.

SoftSIM flexibility

Konstantin Klitenik — Thu, 11 Jun 2026 18:33:26 GMT

Hello,

We are building an application with NRF54 as the host MCU and NRF9151 as a serial modem. We are considering using a SoftSIM from Monogoto. Our main concern is how easy it is to swap it out in caseMonogoto goes out of business.

My understanding is that the SoftSIM is provisioned by flashing it onto the NRF91 directly. After it is flashed with the SoftSIM, are there any ways to change the profile or update it in any way, either using AT commands or some other over-the-air method?

When we askedMonogoto, they said that in case they go out of business, they would provide us with some keys. I am not familiar with exactly how SIMs operate, so I do not know exactly what that means. We will follow up with them separately, but I wanted to understand what is available on the NRF91 side to help us mitigate any potential issues with the carriers and potentially swapping SIM profiles or even swapping carriers.

Thanks.

GPIO base addresses different for S (sense) and NS (no sense)

ProfRob — Thu, 11 Jun 2026 16:17:55 GMT

The last years I have developed a lot software (low level) for the nRF52840. I like this MCU very much, especially the SHORTS-Registers and EasyDMA are powerful for real short latency time with the peripherals.

I do not like the RTOS. I have (a lot) Arduino Nano BLE 33 Sense with MbedOS, trying to bypass the OS wherever possible. I just finished a project for audio analysis with a lot of digital filters (mixed low pass and band pass) running in the background on the interrupt of the PDM-periphery (20 kHz scanning frequency). There is some jitter which may be caused by the OS.

Now I want to switch to the Seeed XIAO nRF54L15 Sense for 2 reasons: 1. the higher speed which would allow to double my number of filters and 2. the possibility to avoid the RTOS (https://github.com/lolren/nrf54-arduino-core).

I started the evaluation with the GPIOs (I use them with direct register access to measure the timing of interrupt handlers) and I have problems to understand the documentation. While it is very clear for the 52840, there are two base addresses for the ports of the 54L15, S for sense and NS for no sense. Why? If i read the description correct, this selection is done via the CNF-Registers. And which is the correct base address? (I will use NS, but that points to 0x4....... and from 52840 I expect 0x5.......).

Surely it is easy for the Nordic experts to explain these two base addresses for the GPIO ports. Thanks in advance ...

Update: Though the AI answer is really helpful, I will post this question anyway. Because otherwise this forum does not make any sense, it will be empty if the AI has learned enough. Hopefully the AI answer is published here.

lis2mdl registers are changed after reboot

Arebhi — Thu, 11 Jun 2026 13:52:03 GMT

Hello everyone,

I have a question regarding the LIS2MDL sensor.

When I configure Register A, it correctly takes the value that I set. However, after the sensor initialization and boot sequence, Register A returns to its default value, even though I am not modifying it anywhere else in the code (the initial driver that change to contiunous mode etc etc) ......

As suggested, I added some debug messages (displayed in red for better visibility), and they confirm that the register is correctly configured at first, but later it unexpectedly reverts to its default value.

Has anyone encountered this behavior before, or could there be a step during initialization/boot that resets the register configuration?

Thank you.

Lis2mdl_registers have change after reboot

Arebhi — Thu, 11 Jun 2026 13:39:00 GMT

nRF54LM20B - KMU unable to provision key

iotdeveloper — Thu, 11 Jun 2026 12:49:39 GMT

Hello,

I'm having trouble saving signing keys to the KMU on the nRF54LM20-DK.

I'm using the build for the nRF54LM20B, as recommended here, so the KMU should be used for this processor:

Exercise 2 - DFU with custom keys - Nordic Developer Academy

https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/device_guides/nrf54l/dfu_config.html

I generated the ED25519 key, and my sysbuild.conf looks like this:

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_PM_MCUBOOT_PAD=0x800
SB_CONFIG_MCUBOOT_MODE_SWAP_USING_MOVE=y

SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="${APP_DIR}/keys/mcuboot_private.pem"
SB_CONFIG_BOOT_SIGNATURE_TYPE_ED25519=y
SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=y
SB_CONFIG_MCUBOOT_GENERATE_DEFAULT_KMU_KEYFILE=y

However, unfortunately, after flashing with the –erase option, I get this message:

Flashing file: ...\build_lm20b_ns_ota_330\merged.hex
Provisioning key file: ...\build_lm20b_ns_ota_330\keyfile.json
Erasing non-volatile memory (ERASEALL)
Programming image
Verifying image
KEY Provision
Keys [242] failed provisioning

Please suggest a solution on how to properly enable storage in the KMU.
(As an alternative, I tried "Store it in the MCUboot bootloader image itself," where it worked fine) – after the OTA update, it only accepted a properly signed image.

Thank you

nRF7002 drops downlink in power save / RPU powers down RX while still advertising PM=0 (no PM=1 Null), so the AP delivers directly and the frame is lost

ValentinKunti — Thu, 11 Jun 2026 11:55:22 GMT

Hello all !

Summary

While in power save the nRF7002 RPU powers down its receiver without sending a PM=1 (Null) frame first, so from the AP point of view the station is still in active mode (PM=0). The AP therefore delivers downlink frames (for example a TCP SYN-ACK) directly instead of buffering them. Since the receiver is off the frame is never ACKed, and the AP retransmits it at the MAC layer (retry=1) around 40 times into a dead receiver. The result is intermittent failure of connection setup (TCP handshake, DHCP-ACK, DNS / gateway ARP) ending in the usual 3 s socket timeout, recovered only by a retry or reconnect. First attempt connections are unreliable on perfectly healthy APs.

Environment

nRF7002 (companion radio) + nRF5340 host (MDBT53-P1M)
nRF Connect SDK v3.2.4 (Zephyr 4.2.99), nrf_wifi driver
CONFIG_NRF_WIFI_LOW_POWER=y, legacy PS (WIFI_PS_MODE_LEGACY), WIFI_PS_PARAM_STATE=enabled
WPA2-PSK, normal infrastructure AP, 2.4 GHz ch 6, beacon interval 100 TU, DTIM period 1, STA AID = 1

Evidence

1. TCP handshake, decrypted (server 20.107.35.42:443, STA 192.167.14.97)

13.342  STA → server   52809 → 443 [SYN]
13.364  server → STA   443 → 52809 [SYN, ACK]                       +22 ms, server is healthy
13.367  server → STA   [TCP Retransmission] [SYN, ACK]   ┐
13.375  server → STA   [TCP Retransmission] [SYN, ACK]   │  ~17 copies of the SAME
  ...                                                    │  SYN-ACK in ~66 ms
13.430  server → STA   [TCP Retransmission] [SYN, ACK]   ┘
14.022  STA → server   [TCP Retransmission] 52809 → 443 [SYN]  ×7
   SYN-ACK retransmit count per connection (4 cycles): 39, 3, 3, 5

2. Same window at the raw 802.11 layer (no decryption), this is the key part

time     dir         frame      retry  PM
13.342   STA → AP    QoS Data   0      0     the SYN (STA awake to transmit)
13.364   AP  → STA   QoS Data   0      -     SYN-ACK, 1st delivery
13.367   AP  → STA   QoS Data   1      -     ┐
13.375   AP  → STA   QoS Data   1      -     │ ~17× the SAME frame, wlan.fc.retry=1
  ...                                        │ = 802.11 MAC retransmission (no ACK from STA)
13.430   AP  → STA   QoS Data   1      -     ┘
   STA "Null PM=1" frames seen at: 12.460 … 15.020   → NONE in between (the whole handshake)

Every SYN-ACK copy has wlan.fc.retry = 1, so the AP is re-sending one un-ACKed frame. This is not TCP RTO.
The STA sends no PM=1 Null during the handshake. It advertises active mode the whole time, yet does not ACK, so its receiver must be off.

3. Beacon TIM: the AP never buffers it (so it is not a "missed DTIM" problem)

STA AID = 1
beacon during the storm:  dtim_count=0  dtim_period=1  multicast=0  bitmap=0x78bb07
   0x78 = 0b01111000 → AIDs 3,4,5,6 have buffered data;  AID 1 (our STA) is NOT set

The PS buffering and TIM signalling on the AP side works fine, it flags other AIDs. Our STA's reply is simply never queued, because the STA never told the AP it was asleep.

4. Same failure on DHCP and DNS (device console, separate runs)

DHCP:  Received dhcp [op=0x2 flags=0x80]        OFFER received (broadcast)
       send request dst=255.255.255.255 ...
       DHCP timeout after 3 retries             broadcast ACK never arrived → DHCP failed -7

DNS:   submitting DNS query (server = gateway 192.167.1.1)
       Query timeout ; DNS attempt 1/5 failed (ret=-101)   -ENETUNREACH: gateway ARP reply
       ... ×5 → DNS resolution failed                      missed, so the query is unsendable

What we tried (none of it fixes it)

WIFI_PS_PARAM_TIMEOUT (post-TX wake window): applied successfully, no observable change.
CONFIG_NRF70_RPU_PS_IDLE_TIMEOUT_MS: tried 10 / 25 / 100 ms, identical residual.
WIFI_PS_PARAM_EXIT_STRATEGY = EVERY_TIM: improves the buffered legs (DHCP/DNS) but not the TCP SYN-ACK, since nothing is buffered there, the AP delivers it directly.
Only WIFI_PS_PARAM_STATE = disabled (Constantly Awake Mode) eliminates it: the receiver stays on, the STA ACKs normally, retransmits drop to single digits or zero.

Questions

Is it expected that, with CONFIG_NRF_WIFI_LOW_POWER=y, the RPU powers the receiver down without sending a PM=1 Null first? Per 802.11 a STA in active mode (PM=0) must keep its receiver on; to sleep it must announce PM=1 so the AP buffers.
If this is by design: is there a way to make the RPU announce PM=1 before sleeping (so the AP buffers and TIM-signals the reply), or to keep the RX up while a recently active flow may still receive an immediate reply (for example during a TCP handshake)?
If not by design, this looks like an RPU firmware defect, please advise.

Best regards and thank you in advance !

RTT Viewer connecting to nrf5340 cpunet core will trigger a mass erase and afterwards one needs to recover the core

C.Thilo — Thu, 11 Jun 2026 11:53:14 GMT

Hi all!

I need to see the printks and log messages from the b0n and cpunet app in RTT Viewer.

The problem is, whenever I connect with the SEGGER RTT Viewer to the netcore, I do get the following error message:

CTRL-AP indicates that the device is secured.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash, SRAM and UICR of both the application and the network core.

In another ticket, Vidar answered me the following:

Hi Thilo,

It would better if you created a new ticket for this, but I will try to help here.
To troubleshoot this, please disable APPROTECT by using the nrfutil commands below (note: the order matters, netcore needs to be recovered first),
then try to connect the RTT viewer again to see if you get the same error (there will not be any logs).

nrfutil device recover --core network
nrfutil device recover --core application

Cheers

Vidar

Sadly that doesn't change anything. I execute the first command (recover netcore) and then connect via RTT Viewer and the same error message appears and the chip has no fw on it anymore.

Any other idea?

Cheers,
Thilo