Nordic Q&A - Recent Threads

Unable to detect external device when programming custom PCB with nrf5340 via JTAG and nrf5340DK

Marosh — Mon, 20 Jul 2026 21:33:56 GMT

Hi, I have previously posted issue with flashing that was already solved. Issues with flashing code on MDBT53V mounted on cusotm board

Unfortunately for some reasons I had to send the nrf52840DK module to my colleague and I have currently only nrf5340DK version 2.0.2 at hand.

The setup is same as with as in the issue linked above with the only exception of using different DK to flash the external board (running on 1.8V). The issue I am facing is the fact I am not even able to detect the external connected PCB so I am technicaly not able to flash it.Tried to supply 1.8V on VTG or Vioref, short and unshort SB19, use different version of nrf connect in vscode but all without success. Also following this issues didnt helped:
Unable to flash custom nRF5340 board with nRF5340DK
I can't program external board with nRF5340 2.0.2

Is there some difference between flashing with nrf52840DK and nrf5340DK I dont know about? Have I possibly damaged my dev board so it is no longer able to flash?

Regards,
Marosh

SVCALL(SD_POWER_GPREGRET_SET, uint32_t, sd_power_gpregret_set(uint32_t gpregret_id, uint32_t gpregret_msk));

Malcolm — Mon, 20 Jul 2026 10:23:18 GMT

There appears to be a bug in ths call SVCALL(SD_POWER_GPREGRET_SET, uint32_t, sd_power_gpregret_set(uint32_t gpregret_id, uint32_t gpregret_msk)); as it returns NRF_ERROR_SOFTDEVICE_NOT_ENABLED sometimes, but not always. As the application initialises softdevice and is using many calls to SD< this is an incorrect return.

As there appears to be no race conditions of gate on GPREGRET2 I instead make a direct call to nrf_power_gpregret_set, which works always, wether SD is enabled or not.

I am using SD 7.0.3

Channel Sounding: counter-intuitive repetition behavior + non-configurable event interval (nRF54L15)

ELavmap — Mon, 20 Jul 2026 09:58:23 GMT

Hello,

we are developing a Channel Sounding application starting from the Nordic samples "Channel Sounding Initiator with Ranging Requestor" and "Channel Sounding Reflector with Ranging Responder" (SDK v3.3.0). We are using the nRF54L15 development board.

ISSUE 1 - CS_CHANNEL_MAP_REPETITION counter-intuitive behavior
Comparing two configurations, single channel map repetition (72 steps, repetition=1) gives better accuracy results than repetition=2 with the same number of steps, contrary to the expectation that more repetitions (= more IQ samples) should improve the estimate. This behavior was confirmed also in an obstacle-free LOS environment, across repeated tests.

Config A (repetition=1) - result:

Config B (repetition=2) - result:

Questions:

Is this behavior plausible, or does it indicate a configuration error on our side?
Which other parameters significantly affect accuracy and should be varied to verify a potential benefit from repetition>1?
Any suggestions on how to set the CS parameters to obtain real benefits from multiple channel map repetitions?

ISSUE 2 - Event interval fixed at 2, not configurable
Regardless of the CS configuration set, the logs always show event interval = 2 after CS procedures enabled.

Why is this not controllable and does not go down to 1? This affects the procedure duration and therefore indirectly the power consumption of the application, so we would like to be able to reduce it.

We remain available for any further details, thank you in advance.

Emilio

Dual mode on nrf5340 - Receive Bluetooth classic/LE->12s, simultaneous with i2s->unicast to different device

Joe0123 — Mon, 20 Jul 2026 02:19:53 GMT

Hi,

I am just evaluating the nrF5340 for an audio bluetooth project. I am trying to find out if the nrf5340 can receive bluetooth audio (classic or LE) from one device and transfer it to i2s out, at the same time as receiving i2s input and transmitting that out as unicast to a different device (or auracast). This would be for basic 16/48 stereo.

My understanding is that the nrf5340 can accomplish these tasks (especially with sample applications), but was not sure if it has the capacity to do this in dual mode like this at the same time.

Secondly I know there has been discussion previously about slave mode not working for i2s on the part (due to drift compensation) - is this still the case, or has there been any update on this?

Thanks for your help.

Joe

nRF Cloud — account auth broken: REST API key (40100) AND device CoAP (-13)

drrh12 — Sun, 19 Jul 2026 00:58:39 GMT

On our nRF Cloud account/team "petakara", TWO independent authentication
surfaces reject valid credentials:

1. REST API: every generated API key returns HTTP 401
{"message":"No API Key found for token. Cannot continue.","code":40100}
2. Device (nRF9151) nRF Cloud CoAP: connection reaches the endpoint with a
valid DTLS session and network time, but nrf_cloud_coap_connect() returns
-13 (EACCES); transport logs "Error sending CoAP request: -22".

The device is claimed to the account and the portal shows "Device identity
has been securely authenticated." So the portal/session side works, but the
device-facing and REST-key auth backends do not. This looks like an
account/team backend activation issue rather than a client mistake.

--- ISSUE 1: REST API KEY (40100) -------------------------------------------

Request (Authorization header verified correct via curl -v):
GET api.nrfcloud.com/.../devices
Authorization: Bearer <API_KEY>

Response:
HTTP/2 401
{"message":"No API Key found for token. Cannot continue.","code":40100}

- Tried THREE separate keys, each freshly generated / regenerated from
User Account -> Team Details -> API Key. All return 40100.
- GET /v1/account returns 401 {"code":1004,"message":"Missing or invalid
Authorization header"} with the same Bearer header.
- The Authorization header is confirmed transmitted correctly (curl -v shows
"> Authorization: Bearer <key>").
- No unresolved incident shown on the nRF Cloud status page at the time.

--- ISSUE 2: DEVICE nRF CLOUD CoAP (-13 / EACCES) ---------------------------

Firmware built on NCS 3.4 with nrf_cloud_coap (CONFIG_NRF_CLOUD=y,
CONFIG_NRF_CLOUD_COAP=y, CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y,
CONFIG_MODEM_JWT=y). Runtime log over SoftSIM/LTE-M:

net: LTE connected (reg status 5)
main: network time: 2026-07-17T14:04:53Z (valid time)
main: nrf_cloud_coap_init -> 0 (OK)
nrf_cloud_coap_transport: Error sending CoAP request: -22
main: nrf_cloud_coap_connect -> -13 (EACCES)

- The device's modem keystore sec_tag 16842753 contains CA (type 0),
client cert (type 1), and private key (type 2) — factory-provisioned.
- The device was onboarded to the account by claiming its attestation token
(AT%ATTESTTOKEN) in the nRF Cloud portal; portal reports the identity as
"securely authenticated".
- DTLS + time succeed; only the nRF Cloud auth/CoAP step is rejected.

--- WHAT WE'VE RULED OUT ----------------------------------------------------

- Wrong auth scheme: docs confirm Bearer + api.nrfcloud.com/v1; verified.
- Bad key copy: three regenerated keys, verbose-confirmed transmission.
- Client time: device has valid network time before the CoAP auth.
- Connectivity: LTE data path works (third-party HTTPS POST returns 200).
- Client identity mismatch: client ID = internal UUID = the claimed device.

--- QUESTIONS / REQUEST -----------------------------------------------------

1. Why does every API key for team "petakara" return 40100 "No API Key found
for token"? Is REST API access not activated for this team, or is there a
backend provisioning step pending on the account?
2. Why is the claimed device's nRF Cloud CoAP auth rejected with -13 (EACCES)
despite the portal showing "securely authenticated"? Does the device need
account-specific credentials provisioned (vs. the factory cert), and if so
why does the portal claim not surface that?
3. Please activate/repair API + device auth for this team, or advise the
exact remaining onboarding step.

COEX0 load capacitance and VDD decoupling differences

yayalew — Fri, 17 Jul 2026 16:06:36 GMT

Hello,

I am developing a custom board using the nRF9151 and comparing the following Nordic sources:

nRF9151 DK PCA10171 hardware files, version 1.0.0 / board revision 1.0.1
Current nRF9151 Product Specification
Current nRF9151 Hardware Design Guidelines and recommended application schematic

I found two apparent discrepancies and would appreciate clarification on which implementation Nordic recommends for a new custom design.

1. COEX0 load capacitance

The current COEX hardware-design guidance states that the total load capacitance on the COEX pins, including routing parasitics, must not exceed 50 pF.

However, the nRF9151 DK schematic appears to connect COEX0 to discrete capacitance whose nominal total is greater than 50 pF.

Could Nordic please clarify:

Does the limit depend on how COEX0 is used—for example, coexistence signaling versus external GNSS LNA control?
Is the DK implementation a validated exception that should not be copied into a different layout?

2. VDD filtering and decoupling

The current recommended nRF9151 application schematic uses:

1 µF + 1 µF on the source side of the VDD ferrite bead
47 µF + 10 µF on the nRF9151 side
A 22 Ω at 100 MHz, 6 A, low-DCR ferrite bead

The VDD capacitor values and/or their placement around the ferrite bead appear different in the nRF9151 DK schematic:

Similarly, the Thingy91x shows something different as well:

My questions include:

Is the application schematic the preferred baseline for new product designs?
Which topology should be followed when powering nRF9151 from an nPM1300/VSYS rail and a single-cell Li-ion battery?

Unexplained current spikes during sleep

Will_20241202 — Fri, 17 Jul 2026 15:50:30 GMT

I am trying to track down the source of unexplained current spikes visible on the Power Profiler Kit 2 when the nRF52832 should be in sleep mode.

I have stripped the project down to as bare bones as possible (see below) and tried every possible solution from Google's AI (most of which were hallucinations...) to no avail.

 #include <zephyr/kernel.h>

int main(void) {
	for(unsigned int i = 0; i < 2000; i++) {
		k_msleep(1);
	}
	for(;;) {
		const unsigned int width = 250;
		k_msleep(5 * 1000 - width);
		for(unsigned int i = 0; i < width; i++) {
			k_msleep(1);
		}
	}
}

# prj.conf
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_BT=n
CONFIG_CLOCK_CONTROL=y
CONFIG_LOG=n
CONFIG_MCUMGR=n
CONFIG_PM_DEVICE=y
CONFIG_SERIAL=n
CONFIG_TICKLESS_KERNEL=y
CONFIG_TIMESLICING=n
CONFIG_UART_CONSOLE=n
CONFIG_WATCHDOG=n
CONFIG_SHELL=n

I am building using v3.2.3 of the SDK using the nRF Connect extension in VS Code

I'm using a custom board that does _NOT_ exhibit these spikes when using code built using v2.5.x of the SDK (not a hardware problem!!!)

The board uses an external crystal for the 32.768 kHz

Things I've already tried:

PPK2 is in "source" mode, no other connections to the board (including completely disconnecting the JTAG cable)
power cycling the board after programming and before capturing the plot of current
disabling all 20 PPI channels at the start of main (no effect on most, one actually causes the k_sleep to never wake up...)
stopping all 3 timers at the start of main
removing all mentions of peripherals (I2C, SPI, PWM, etc.) from the C code, prj.conf, and board files
switching from the DC/DC regulator to the LDO (again, same hardware does not show the problem with older SDKs!)
using the debugger to look for unexpected threads or IRQs
adding special code to main() to differentiate between legitimate wake behavior (and code resets) and the unexpected wakeups - the legit ones are the "fat" ones.

NCS subsys/esb: PTX never gets ACK from a receiver that ACKs LOGITacker's identical payload (DPL S1 bit)

arsenapple — Fri, 17 Jul 2026 13:24:32 GMT

Summary

I'm transmitting a raw Logitech Unifying pairing frame from the NCS standard ESB library (subsys/esb, ESB_PROTOCOL_ESB_DPL, 2 Mbps, PTX) on an nRF52840. The transmit runs, but I never get an ACK: ESB_EVENT_TX_SUCCESS never fires — only ESB_EVENT_TX_FAILED. Posting the full isolation + root cause here in case it saves someone the days it cost me.

What I verified (to rule everything else out)

Payload bytes are correct — byte-for-byte identical to a known-good reference implementation.
It's actually on air — a second nRF52840 running LOGITacker (pair sniff run) captures the exact bytes I'm sending.
The receiver is healthy — when LOGITacker (pair device run, forced pairing) sends the identical payload to the same receiver, it ACKs and completes pairing.

So content, transmission, and receiver are all fine — the fault is purely in my ESB receive/ACK-detection path.

Root cause — DPL S1 least-significant bit polarity

After tracing RADIO->STATE (RX ramp-up was fine: RXRU then RX) and ruling out ACK-wait timeout, TX power, and preamble length, the decisive difference was the least-significant bit of the S1 field in the DPL PDU header:

NCS subsys/esb computes it as pdu->type.dpl_pdu.ack = !noack → puts a 1 on an ACK-requesting transmit.
LOGITacker's Unifying-compatible path puts a 0 there.

The two stacks encode "I want an ACK" with opposite bit values, and this never surfaces at the API level (esb_write_payload()'s noack argument) — only in the raw on-air S1 bit.

Fix

Forcing NCS's S1 bit to match Unifying's raw convention (i.e. pdu->type.dpl_pdu.ack = noack for this Unifying use case) made ADDRESS / END / CRC events fire for the first time, and RSP1 started parsing immediately.

Full writeup (with the other walls I hit — LOGITacker not booting on this dongle, nrf_esb_illegalmod being sniffing-only, test-oracle traps, channel-search tuning): 👉 https://dev.to/arsenapple/porting-logitech-unifying-to-nrf-connect-sdk-why-esbwritepayload-gets-no-ack-and-4-other-walls-1mag

Hope this helps the next person searching "NCS esb no ACK Unifying".

nRF54L15 PWM precise frequency output for Active Stylus (470.970 kHz) – internal limitation analysis

moke0 — Fri, 17 Jul 2026 09:42:02 GMT

Environment:

SDK: nRF Connect SDK v3.2.4
SoC: nRF54L15
Application: Active Stylus (Capacitive Pen)

Description:

Hi Nordic Team,

I am developing an active stylus using the nRF54L15. The application requires generating a 470.970 kHz square wave to drive the pen tip electrode. The protocol tolerance is ±0.15 kHz (i.e., 470.820 kHz ~ 471.120 kHz).

Analysis performed:

The PWM peripheral is clocked at 16 MHz (HFCLK). In Up-counting mode:

plain

f_PWM = 16 MHz / (PRESCALER × COUNTERTOP)

For the target frequency:

plain

COUNTERTOP = 16,000,000 / 470,970 ≈ 33.97

Since COUNTERTOP must be an integer:

COUNTERTOP = 34 → 470.588 kHz, error = -0.382 kHz (outside tolerance)
COUNTERTOP = 33 → 484.848 kHz, error is even larger

I have also verified that the TIMER + GPIOTE + DPPIC approach is limited by the same 16 MHz clock source and yields identical discrete frequencies. All PRESCALER divider combinations (÷1 ~ ÷128) were checked; none produce a frequency within the required ±0.15 kHz window.

Questions:

Does the nRF54L15 provide any mechanism to fine-tune the HFCLK (e.g., via FLL, PLL, or alternative clock sources) so that the PWM base clock becomes an integer multiple of 470.970 kHz?

Thank you for your support!

NCS SDK v3.3.0 download is extremely slow and restarts before completion

Rahul0123 — Fri, 17 Jul 2026 07:21:10 GMT

Hi Nordic Team,

The download of the nRF Connect SDK (NCS) v3.3.0 through nRF Connect for Desktop is extremely slow.

Environment:

- Operating System: Ubuntu 24.04 LTS

- IDE: Visual Studio Code(1.128.0)

- NCS Version: v3.3.0

Issue Description:

- The download is progressing extremely slowly.
- We have been facing this issue consistently for the last 3–4 days.
- We verified our internet connectivity and also tried downloading using different networks, but the download speed remains very slow.
- I started the download in the morning and left my laptop running overnight. By the next morning, the download had only reached the progress shown in the screenshot below

- Another team member is also experiencing the same issue.

Could you please let us know:

1. Are there any known issues with the NCS v3.3.0 download servers?
2. Is there anything we should check from our side?

Any assistance would be greatly appreciated.

Thank you.

nRF9151: GCI searches returning limited results

JordanYates — Fri, 17 Jul 2026 05:21:59 GMT

I have an application that is attempting to use multi-cell positioning based on the results of %NCELLMEAS.
The application is following the flow of the NCS positioning module (EXTENDED_LIGHT -> GCI_DEFAULT -> GCI_EXTENDED_LIGHT).
I am observing that most of the time, the GCI scans are failing to find any cells apart from the currently serving cell.
Differing from other similar questions here, the application is in RRC idle for all of the scan requests.
The initial scan results in multiple neighbor cells found and measured, so it is not an issue of no other towers being nearby (I am ~10km from a city center)

[00:17:12.676,361] <err> modem_monitor:    State: Active
[00:17:23.825,866] <err> modem_monitor:    State: Idle
... Radio in RRC Idle
[00:18:00.633,056] <wrn> task_network_scan: Cell Scan: Mode 2 GCI_Count 0
[00:18:01.463,928] <inf> task_network_scan: Serving Cell Valid: Yes, Neighbour Cells: 3
[00:18:01.463,958] <inf> task_network_scan: Serving ECI: 147045644 (-106 dBm)
[00:18:01.463,958] <inf> task_network_scan: Neighbour: 337 (-118 dBm)
[00:18:01.463,989] <inf> task_network_scan: Neighbour: 238 (-120 dBm)
[00:18:01.463,989] <inf> task_network_scan: Neighbour: 70 (-129 dBm)
[00:18:01.464,141] <wrn> task_network_scan: Cell Scan: Mode 4 GCI_count 7
[00:18:01.836,669] <inf> task_network_scan: Global Cells: 1
[00:18:01.836,669] <inf> task_network_scan: Global ECI: 147045644 (-107 dBm)
[00:18:01.836,791] <wrn> task_network_scan: Cell Scan: Mode 5 GCI_count 7
[00:18:09.843,841] <inf> task_network_scan: Global Cells: 1
[00:18:09.843,872] <inf> task_network_scan: Global ECI: 147045644 (-107 dBm)
... Uplink here, transition to RRC Active
[00:18:12.688,781] <err> modem_monitor:    State: Active
[00:18:25.178,192] <err> modem_monitor:    State: Idle

While the lack of GCI cells is not a huge issue here with the multiple neighbors reported, the application also operates in regions where the network does not provide neighbor information, so the performance of the GCI scanning is critical.
Occasionally the `GCI_DEFAULT` search does find a second cell, but I am yet to see `GCI_EXTENDED_LIGHT` return useful information, despite searching for ~7.5 seconds each run.

I feel like I must be doing something wrong, but I have no idea what it could be.

           Model: nRF9151-LACA
        Firmware: mfw_nrf91x1_2.0.3
            Mode: LTE-M + GNSS (Prefer: No preference)

nRF9151 DK (LACA A1A) - UICC failure, card responds on I/O but modem reports NO ATR

David01234567 — Thu, 16 Jul 2026 19:46:00 GMT

Hello,
I'm working on a prototype device based on the nRF9151 DK.

HW: nRF9151 DK, nRF9151 LACA A1A
Tested with modem_shell sample app, NCS v3.4.0.

Symptom: on boot, "The modem reports a UICC failure. Is SIM installed?" / Network registration status: UICC fail.

Diagnostics:

AT%CSUS? --> 0 (physical UICC slot correctly selected)
AT+CFUN=4 --> +CFUN: 4; SIM_VCC on J5 C1 = 0 V (correct)
AT+CFUN=41 --> OK; SIM_VCC pulses ~360 ms with retries
Oscilloscope at the socket during activation: CLK clean 1.818 MHz (varies 200 kHz-1.8 MHz across retries), RST 2-3 pulses ~100 ms, I/O shows clean digital data - the card IS responding
AT%XSIM? --> 0
AT+CPIN? --> ERROR
AT+CEER --> +CEER: "UICC 0"

Ruled out:

SIM card: 1NCE, Onomondo, Conexa - all identical NO ATR
Modem FW: mfw_nrf91x1 2.0.4, 2.0.3 - all identical
Config: AT%XFACTORYRESET=1 performed, no change; %CSUS=0

Modem drives VCC/CLK/RST correctly and the card responds on I/O (visible on scope at SIM socket and P28), but the modem never receives a valid ATR.

devzone.nordicsemi.com/.../sim-1NCE_2C00_-trace_2D00_2026_2D00_07_2D00_16T18_2D00_04_2D00_57.255Z.mtrace

Does this look like a hardware fault to you, or did I miss something? If it is hardware, I'd like to proceed with an RMA.

Regards,

David

nRF54L15 + NCS v3.4.0: MCUboot fails with "Firmware has been invalidated: 0xffff0000" when using NSIB + MCUboot + BLE FOTA

Mathiyazhagan S — Thu, 16 Jul 2026 16:54:56 GMT

Hi Nordic Team,

I am trying to implement a secure boot chain on the nRF54L15 DK using NCS v3.4.0 (LTS) with the following configuration:

Board: nrf54l15dk/nrf54l15/cpuapp
NCS version: v3.4.0
Boot chain:
- NSIB
- MCUboot
Application:
- BLE SMP FOTA using MCUmgr

I followed the available Nordic documentation and DevZone recommendations to configure NSIB + MCUboot together.

sysbuild.conf:

# Enable two-stage boot chain
SB_CONFIG_SECURE_BOOT_APPCORE=y
SB_CONFIG_BOOTLOADER_MCUBOOT=y

# ED25519 keys
SB_CONFIG_SECURE_BOOT_SIGNATURE_TYPE_ED25519=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_ED25519=y

# Store MCUboot verification key in KMU
SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=y

# Signing keys
SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="${APP_DIR}/keys/nsib_priv.pem"
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="${APP_DIR}/keys/mcuboot_priv.pem"

# Generate KMU provisioning file
SB_CONFIG_MCUBOOT_GENERATE_DEFAULT_KEY_FILE=y

prj.conf:

CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_PRINTK=y
CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_BT_PERIPHERAL=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN=y

Flashing
I perform a full recover before programming: west flash --recover and
Programming completes successfully without any reported errors.

Relevant output:

-- west flash: rebuilding
[0/8] Performing build step for 'app'
ninja: no work to do.
[1/8] Performing build step for 'mcuboot'
ninja: no work to do.
[7/7] Completed 'mcuboot'
WARNING: Specifying runner options for multiple domains is experimental.
If problems are experienced, please specify a single domain using '--domain <domain>'
-- west flash: using runner nrfutil
Using board 001057728952
-- runners.nrfutil: Recovering and erasing all flash memory.
-- runners.nrfutil: Flashing file: app/build_v3.4.0_nrf54l15_/mcuboot/zephyr/zephyr.hex
-- runners.nrfutil: Provisioning key file: app/build_v3.4.0_nrf54l15_/keyfile.json
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Recover
-- runners.nrfutil: Programming image
-- runners.nrfutil: Verifying image
-- runners.nrfutil: KEY Provision
-- runners.nrfutil: Board(s) with serial number(s) 1057728952 flashed successfully.
-- west flash: using runner nrfutil
-- runners.nrfutil: reset after flashing requested
-- runners.nrfutil: Flashing file: app/build_v3.4.0_nrf54l15_/nRF_Evaluations/zephyr/zephyr.signed.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Programming image
-- runners.nrfutil: Verifying image
-- runners.nrfutil: Reset

Boot Log:

Fprotect disabled. No protection applied.
LCS-awareness disabled.
Attempting to boot slot 0.
Attempting to boot from address 0x10800.
E: Firmware has been invalidated: 0xffff0000.
Failed to validate, permanently invalidating!
Attempting to boot slot 1.
Attempting to boot from address 0x20800.
E: Firmware has been invalidated: 0xffff0000.
Failed to validate, permanently invalidating!
No bootable image found. Aborting boot.

I also use the following custom flash partition layout: nrf54l15dk_nrf54l15_cpuapp.overlay

&cpuapp_rram {
    partitions {
        b0_partition: partition@0 {
            compatible = "zephyr,mapped-partition";
            label = "b0";
            reg = <0x0 0xC000>;
        };

        provision_partition: partition@C000 {
            compatible = "zephyr,mapped-partition";
            label = "provision";
            reg = <0xC000 0x4000>;
        };

        s0_partition: partition@10000 {
            compatible = "zephyr,mapped-partition";
            label = "s0";
            reg = <0x10000 0x10000>;
        };

        s1_partition: partition@20000 {
            compatible = "zephyr,mapped-partition";
            label = "s1";
            reg = <0x20000 0x10000>;
        };

        slot0_partition: partition@30000 {
            compatible = "zephyr,mapped-partition";
            label = "image-0";
            reg = <0x30000 0xE4000>;
        };

        slot1_partition: partition@114000 {
            compatible = "zephyr,mapped-partition";
            label = "image-1";
            reg = <0x114000 0xE4000>;
        };

        storage_partition: partition@155000 {
            compatible = "zephyr,mapped-partition";
            label = "storage";
            reg = <0x155000 0x10000>;
        };
    };
};

Questions:

What does the message Firmware has been invalidated: 0xffff0000 actually indicate?
Is my overall NSIB + MCUboot configuration correct for NCS v3.4.0, or are there additional configuration steps required to enable a two-stage boot chain with BLE SMP FOTA?
Is there anything incorrect with my custom partition layout that could cause MCUboot to attempt booting from 0x10800 and 0x20800 instead of the expected application slot?

I would appreciate any clarification regarding this issue. Thank you for your support.

Best regards,
Mathiyazhagan S.

psa_aead_finish with CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y generates incorrect tag for AES-GCM

reavertm — Thu, 16 Jul 2026 14:11:42 GMT

As in subject, psa_aead_finish function generates incorrect tag for AES-GCM when Nordic proprietary library is used.

Works fine with Oberon backend.

Similar problem reported 3 years ago: RE: Enabling CONFIG_PSA_CRYPTO_DRIVER_CC3XX causes incorrect tag when using AES-GCM, there it was related to too short nonce.

Tested with NCS 3.3.0 and 3.4.0 on nRF5340.

Below code compares authentication tag generated by single-part and multi-part PSA Crypto API on the same iv, auth data, key, plaintext.

#define ASSERT_PSA(func, ...) \
    { \
        psa_status_t s = func(__VA_ARGS__); \
        if (s != PSA_SUCCESS) { \
            printk(# func " failed: %i\n", s); \
            goto exit; \
        } \
    }

void test()
{
    psa_key_id_t k_id = -1;

    {
        ASSERT_PSA(psa_crypto_init);

        uint8_t key[32];    
        ASSERT_PSA(psa_generate_random, key, sizeof(key));

        psa_key_attributes_t key_attr = PSA_KEY_ATTRIBUTES_INIT;
        psa_set_key_usage_flags(&key_attr, PSA_KEY_USAGE_ENCRYPT);
        psa_set_key_algorithm(&key_attr, PSA_ALG_GCM);
        psa_set_key_type(&key_attr, PSA_KEY_TYPE_AES);
        psa_set_key_bits(&key_attr, PSA_BYTES_TO_BITS(sizeof(key)));

        ASSERT_PSA(psa_import_key, &key_attr, key, sizeof(key), &k_id);

        uint8_t iv[12];
        ASSERT_PSA(psa_generate_random, iv, sizeof(iv));

        const uint8_t AUTH_DATA[] = {'T', 'e', 's', 't'};
        const uint8_t PLAINTEXT[] = "Lorem ipsum dolor sit amet, consectetur adipiscing elit";

        size_t encrypted_len;

        // single-part
        uint8_t ciphertext_single[sizeof(PLAINTEXT) + 16];
        ASSERT_PSA(psa_aead_encrypt, k_id, PSA_ALG_GCM,
            iv, sizeof(iv),
            AUTH_DATA, sizeof(AUTH_DATA),
            PLAINTEXT, sizeof(PLAINTEXT),
            ciphertext_single, sizeof(ciphertext_single),
            &encrypted_len);

        // muilti-part
        uint8_t ciphertext_multi[sizeof(PLAINTEXT)];
        psa_aead_operation_t op = PSA_AEAD_OPERATION_INIT;
        ASSERT_PSA(psa_aead_encrypt_setup, &op, k_id, PSA_ALG_GCM);
        ASSERT_PSA(psa_aead_set_nonce, &op, iv, sizeof(iv));
        ASSERT_PSA(psa_aead_update_ad, &op, AUTH_DATA, sizeof(AUTH_DATA));
        size_t in_offset = 0, out_offset = 0;
        ssize_t left = sizeof(PLAINTEXT);
        while (left > 0) {
            size_t to_encrypt = MIN(left, sizeof(ciphertext_multi) / 2), encrypted_len; // div by 2, to force at least two invocations
            ASSERT_PSA(psa_aead_update, &op, PLAINTEXT + in_offset, to_encrypt, ciphertext_multi + out_offset, sizeof(ciphertext_multi) - out_offset, &encrypted_len);
            in_offset += to_encrypt;
            left -= to_encrypt;
            out_offset += encrypted_len;
        }
        uint8_t tag[16];
        size_t tag_len;
        ASSERT_PSA(psa_aead_finish,&op, ciphertext_multi + out_offset, sizeof(ciphertext_multi) - out_offset, &encrypted_len, tag, sizeof(tag), &tag_len);
        if (tag_len != sizeof(tag)) {
            printk("Unexpected tag len %u != %u\n", tag_len, sizeof(tag));
            goto exit;
        }
        if (encrypted_len != (sizeof(ciphertext_multi) - out_offset)) {
            printk("Unexpected ciphertext_len %u != %u\n", encrypted_len, sizeof(ciphertext_multi) - out_offset);
            goto exit;
        }
        if (memcmp(ciphertext_single, ciphertext_multi, sizeof(ciphertext_multi)) != 0) {
            printk("Ciphertext mismatch\n");
            goto exit;
        }
        if (memcmp(ciphertext_single + sizeof(ciphertext_multi), tag, sizeof(tag)) != 0) {
            printk("Authentication tag mismatch\n");
            goto exit;
        }
    }
exit:
    if (k_id != -1) {
        psa_destroy_key(k_id);
    }
}

"Authentication tag mismatch" is raised when:

CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y

and works fine when backends are switched. Note that psa_aead_finish returns different tag even than psa_aead_encrypt in CC3XX, so it's just multi-part API impl that is broken in CC3XX.

Earlier when investigating this bug, I compared generated authentication tags by other implementations and they return the same tag as Oberon, or psa_aead_encrypt:

- OpenSSL (EVP_EncryptFinal_ex, EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag)

- Python cryptography (AESGCM) that on my Linux distro uses native Rust implementation as backend

nPM1100 ship mode

oqthm011 — Thu, 16 Jul 2026 14:07:38 GMT

Hi, I have a question with regard to the nPM1100 PMIC and entering ship mode (not exiting it).

If I am interpreting the datasheet correctly, the SHPHLD pin must be held HIGH prior to activating ship mode via SHPACT (correct me if I am wrong). The reference schematic in section 7.1 of the datasheet shows SHPHLD connected to VBAT via a 100k resistor and a switch connected to GND to pull it LOW when pressed.

In my scenario (no MCU involved) I want to be able to enter ship mode at the press of a button that sets SHPACT to HIGH (by connecting VSYS?), however, I don't need the switch with SHPHLD as I can exit ship mode bby connecting VBUS (the USB cable).

My questions are,

1. If I don't need the switch on SHPHLD, do I just connect SHPHLD directly to VBAT?

2. Do I still need the 100k resistor? Is there a significance to this value? The nPM1100 EK board uses two 10k resistors in series instead.

3. Under normal operation, isn't holding SHPHLD constantly HIGH, connected to VBAT, wasting battery life on the off-chance one needs to press the switch on SHPACT to enter ship mode?

4. If (3) is a yes, is there possibly another way to achieve entering ship mode by setting SHPHLD HIGH right before setting SHPACT HIGH?

Just to re-iterate, in my implementation no MCU is involved.

Thank you for your answers in advance

CS procedures never start after CS security enable — channel_sounding_ras_reflector stuck on nRF54L15DK with Android 17 (Pixel 10) + nRF Toolbox v4.3.2

Shreeyash17 — Thu, 16 Jul 2026 12:01:51 GMT

Category: Bluetooth / Channel Sounding

---
Hardware:
- Board: nRF54L15DK (nrf54l15dk/nrf54l15/cpuapp)
- nRF Connect SDK: v3.1.0
- Sample: nrf/samples/bluetooth/channel_sounding_ras_reflector
- Build command: west build -p -b nrf54l15dk/nrf54l15/cpuapp -- -DEXTRA_CONF_FILE=android_ranging.conf

Mobile device:
- Device: Google Pixel 10
- Android version: 17
- nRF Toolbox version: 4.3.2

---
Issue Description:

When connecting the channel_sounding_ras_reflector sample (built with android_ranging.conf) to a Pixel 10 running Android 17 via nRF
Toolbox v4.3.2, the CS setup phase completes successfully up to and including CS security enable. After that, no CS procedures ever start
and no ranging data is produced. The app appears stuck — no distance measurements are shown and there is no further activity.

---
Steps to Reproduce:

1. Build and flash channel_sounding_ras_reflector with android_ranging.conf on nRF54L15DK
2. Open nRF Toolbox v4.3.2 on Pixel 10 (Android 17)
3. Navigate to the Channel Sounding / Ranging tile
4. Connect to "Nordic CS Reflector"
5. Complete BLE pairing/bonding when prompted
6. Observe UART logs on nRF54L15DK and nRF Toolbox UI

---
Expected Behavior:

After CS security enable, the Android initiator sends LE CS Procedure Enable, CS subevents begin, ranging data flows through the RAS GATT
service (RRSP), and nRF Toolbox displays distance measurements.

---
Actual Behavior:

CS setup completes up to security enable and then stalls. UART log on nRF54L15DK:

I: Connected to XX:XX:XX:XX:XX:XX (random) (err 0x00)
I: CS capability exchange completed.
I: CS config creation complete. ID: 0
I: CS security enabled.
← stuck here, no further CS activity

No LE CS Procedure Enable appears to be sent by Android. No CS subevent results are generated. nRF Toolbox shows no ranging output. The
connection remains alive but idle indefinitely.

---
What Has Been Tried:

1. Full flash erase and fresh pairing — same result every time
2. Killing and restarting nRF Toolbox app — same result
3. Forgetting device on Android and reconnecting — same result
4. Added CONFIG_BT_GATT_SERVICE_CHANGED=y to android_ranging.conf — no change
5. Confirmed android_ranging.conf is applied correctly (bonding and CS security succeed, so base config is working)

---
Configuration:

prj.conf (relevant entries):
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_SMP=y
CONFIG_BT_BONDABLE=n
CONFIG_BT_MAX_CONN=1
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_RAS_MODE_3_SUPPORTED=n
CONFIG_BT_RAS_MAX_ANTENNA_PATHS=1
CONFIG_BT_CTLR_SDC_CS_MAX_ANTENNA_PATHS=1
CONFIG_BT_CTLR_SDC_CS_NUM_ANTENNAS=1
CONFIG_BT_CTLR_SDC_CS_STEP_MODE3=n
CONFIG_BT_CTLR_SDC_CS_ROLE_REFLECTOR_ONLY=y
CONFIG_BT_CHANNEL_SOUNDING=y
CONFIG_BT_RAS=y
CONFIG_BT_RAS_RRSP=y

android_ranging.conf:
CONFIG_BT_BONDABLE=y
CONFIG_BT_SETTINGS=y
CONFIG_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_BT_GATT_SERVICE_CHANGED=y
CONFIG_BT_RAS_MAX_ANTENNA_PATHS=2
CONFIG_BT_CTLR_SDC_CS_MAX_ANTENNA_PATHS=2

---
Questions:

1. Is nCS v3.1.0 channel_sounding_ras_reflector validated against Android 17? The android_ranging.conf header explicitly states "settings
required to run CS Ranging with Android 16 phones" — is there a known gap with Android 17?
2. After CS security enable completes on the reflector side, what is expected to trigger LE CS Procedure Enable from Android? Is there a
GATT operation (e.g., CCCD subscription to RAS characteristics) that must succeed first before Android sends the procedure enable?
3. Is there an additional Kconfig or code change needed for Android 17 support?
4. Is this a known issue with a fix in an upcoming nCS release?

Peripheral Registers Not Visible in Keil Debug Session (NRF52840)

Rani0 — Thu, 16 Jul 2026 09:58:48 GMT

Hi Nordic Support,

I am facing an issue where the peripheral registers are not visible in the Keil debugger during a debug session. Only the core registers are available, and I am unable to access peripheral registers through the System Viewer.

Development Environment:

IDE: Keil MDK-ARM (uVision) v5.43.1.0
Nordic SDK: nRF5 SDK v17.1.0
Debug Probe: J-Link
Device: nRF52840

Board Details:

Marking on PCB: 10056
Hardware Revision: 3.0.3

Issue Description:

The application builds, programs, and runs successfully.
During debugging, the peripheral registers are not visible in Keil's System Viewer/Peripherals window.
I expected to see peripherals such as GPIO, UART, TIMER, etc., but they are missing.

Could you please let me know:

Is there any additional configuration required in Keil to enable the peripheral register view?
Does this depend on a specific Device Family Pack (DFP) or SVD file?
Is this a known issue with this board or SDK version?

Any guidance would be appreciated.

Thank you!

nRF54LM20A USB HID device

john.liu — Thu, 16 Jul 2026 07:59:04 GMT

Hi:

Use nRF54LM20A_DK.

Use ncs 3.1.1.

And this is source code:

devzone.nordicsemi.com/.../4477.boards.zip

The following error occurred:

« *** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
Hello World! nrf54lm20dk/nrf54lm20a/cpuapp
HF clock started
W: Experimental DMA enabled
E: Failed to allocate net_buf 4095
E: Buffer for data|status is missing
E: Malformed setup packet
E: Failed to allocate net_buf 4095
E: Buffer for data|status is missing
E: Malformed setup packet
E: Failed to allocate net_buf 4095
E: Buffer for data
|status is missing
E: Malformed setup packet
E: Failed to allocate net_buf 4095
E: Buffer for data|status is missing
E: Malformed setup packet

How to connect two Keyboards with the Desktop sample

xue — Thu, 16 Jul 2026 02:43:32 GMT

Hello,
I use the NCS v3.3.0 (ncs\v3.3.0\nrf\applications\nrf_desktop).
Can the desktop dongle connect to two keyboards at the same time?
Development boards: two nrf54lm20‑dk (using the build for nrf54lm20b) and one nrf52840dongle (using the build for 52840dongle).
Initially, I configured both nrf54lm20‑dk boards as MOUSE devices. They could both connect to the nrf52840dongle simultaneously, and message reporting from both devices worked normally.
Later, I configured both nrf54lm20‑dk boards as keyboards and modified the prj.conf of the nrf52840dongle. I found that I could pair both keyboards, but they cannot stay online at the same time. If both are online concurrently, the nrf52840dongle freezes/crashes. Neither a long press nor a short press of SW1 has any effect, and no log is output. The only way to recover is to power cycle the dongle.
Logs and prj.conf of nrf52840dongle, as well as prj.conf of nrf54lm20dk are attached below for your reference.

Below is the prj.conf configuration of the nrf52840dongle:
CONFIG_DESKTOP_INIT_LOG_MOTION_EVENT=n
CONFIG_DESKTOP_INIT_LOG_HID_REPORT_EVENT=n
CONFIG_DESKTOP_INIT_LOG_HID_REPORT_SENT_EVENT=n
CONFIG_CAF_INIT_LOG_KEEP_ALIVE_EVENTS=n
CONFIG_CAF_BUTTONS=y
CONFIG_CAF_BUTTONS_POLARITY_INVERSED=y
CONFIG_CAF_BUTTONS_PM_KEEP_ALIVE=n
CONFIG_CAF_CLICK_DETECTOR=y
CONFIG_CAF_LEDS=y
CONFIG_CAF_LEDS_PWM=y
CONFIG_DESKTOP_ROLE_HID_DONGLE=y
CONFIG_DEPRECATION_TEST=y
CONFIG_DESKTOP_DEVICE_PID=0x52DC
CONFIG_DESKTOP_BLE_PEER_CONTROL=y
CONFIG_DESKTOP_BLE_PEER_CONTROL_BUTTON=0x0000
CONFIG_DESKTOP_BLE_NEW_PEER_SCAN_REQUEST=y
CONFIG_DESKTOP_BLE_NEW_PEER_SCAN_ON_BOOT=y
CONFIG_DESKTOP_BLE_PEER_ERASE=y
CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE=y
CONFIG_DESKTOP_CONFIG_CHANNEL_DFU_ENABLE=y
CONFIG_DESKTOP_BLE_QOS_ENABLE=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1536
CONFIG_ISR_STACK_SIZE=1280
CONFIG_MAIN_STACK_SIZE=840
CONFIG_BT_RX_STACK_SIZE=2048
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=1536
CONFIG_BOOT_BANNER=n
CONFIG_NCS_BOOT_BANNER=n
CONFIG_NUM_COOP_PRIORITIES=10
CONFIG_NUM_PREEMPT_PRIORITIES=15
CONFIG_HEAP_MEM_POOL_SIZE=8192
CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
CONFIG_SYSTEM_CLOCK_NO_WAIT=y
CONFIG_HW_STACK_PROTECTION=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_GPIO=y
CONFIG_SERIAL=n
CONFIG_BOARD_SERIAL_BACKEND_CDC_ACM=n
CONFIG_UART_INTERRUPT_DRIVEN=n
CONFIG_CONSOLE=n
CONFIG_REBOOT=y
CONFIG_SPEED_OPTIMIZATIONS=y
CONFIG_PWM=y
CONFIG_LED=y
CONFIG_LED_PWM=y
CONFIG_LED_GPIO=n
CONFIG_BT_PRIVACY=y
CONFIG_BT_CTLR_SDC_LLPM=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
CONFIG_BT_BUF_ACL_TX_SIZE=35
CONFIG_BT_CTLR_DATA_LENGTH_MAX=35
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=3000
CONFIG_ENTROPY_CC3XX=n
CONFIG_FW_INFO=y
CONFIG_FW_INFO_FIRMWARE_VERSION=1
CONFIG_ASSERT=y
CONFIG_ASSERT_LEVEL=2
CONFIG_DESKTOP_LOG=y
CONFIG_DESKTOP_LOG_UART=y
CONFIG_DESKTOP_LOG_RTT=y
CONFIG_DESKTOP_BLE_SCAN_KEYBOARD_LIMIT=2
CONFIG_DESKTOP_HID_DONGLE_BOND_COUNT=3
CONFIG_DESKTOP_HID_DONGLE_CONN_COUNT=3
CONFIG_BT_MAX_CONN=2
CONFIG_BT_HIDS_MAX_CLIENT_COUNT=2

Below is the prj.conf configuration of the nrf54lm20‑dk:
CONFIG_DESKTOP_INIT_LOG_MOTION_EVENT=n
CONFIG_DESKTOP_INIT_LOG_HID_REPORT_EVENT=n
CONFIG_DESKTOP_INIT_LOG_HID_REPORT_SENT_EVENT=n
CONFIG_CAF_INIT_LOG_KEEP_ALIVE_EVENTS=n

CONFIG_DESKTOP_ROLE_HID_PERIPHERAL=y
CONFIG_DESKTOP_PERIPHERAL_TYPE_KEYBOARD=y
CONFIG_DESKTOP_DEVICE_PID=0x52DD
CONFIG_DESKTOP_HID_BOOT_INTERFACE_KEYBOARD=y
CONFIG_DESKTOP_HID_KEYMAP_DEF_PATH="hid_keymap_def.h"
CONFIG_DESKTOP_HID_STATE_HID_KEYBOARD_LEDS_DEF_PATH="hid_keyboard_leds_def.h"
CONFIG_DESKTOP_HID_STATE_SUBSCRIBER_COUNT=2
CONFIG_CAF_BUTTONS=y
CONFIG_CAF_BUTTONS_POLARITY_INVERSED=y
CONFIG_CAF_BUTTONS_PM_KEEP_ALIVE=n
CONFIG_CAF_CLICK_DETECTOR=y
CONFIG_CAF_LEDS=y
CONFIG_CAF_LEDS_PWM=y
CONFIG_DESKTOP_USB_ENABLE=y
CONFIG_DESKTOP_USB_STACK_NEXT=y
CONFIG_DESKTOP_BLE_ADV_CTRL_ENABLE=y
CONFIG_DESKTOP_BLE_ADV_CTRL_SUSPEND_ON_USB=y
CONFIG_DESKTOP_BLE_USE_DEFAULT_ID=y
CONFIG_DESKTOP_BLE_PEER_CONTROL=y
CONFIG_DESKTOP_BLE_PEER_CONTROL_BUTTON=0x0000
CONFIG_DESKTOP_BLE_PEER_ERASE_ON_START=y
CONFIG_DESKTOP_BLE_SECURITY_FAIL_TIMEOUT_S=10
CONFIG_DESKTOP_BLE_LOW_LATENCY_LOCK=y
CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE=y
CONFIG_DESKTOP_CONFIG_CHANNEL_OUT_REPORT=y
CONFIG_DESKTOP_CONFIG_CHANNEL_DFU_ENABLE=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=3584
CONFIG_ISR_STACK_SIZE=2560
CONFIG_MAIN_STACK_SIZE=2816
CONFIG_BT_RX_STACK_SIZE=2048
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=1536
CONFIG_IDLE_STACK_SIZE=512
CONFIG_BOOT_BANNER=n
CONFIG_NCS_BOOT_BANNER=n
CONFIG_NUM_COOP_PRIORITIES=10
CONFIG_NUM_PREEMPT_PRIORITIES=15
CONFIG_HEAP_MEM_POOL_SIZE=2560
CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
CONFIG_SYSTEM_CLOCK_NO_WAIT=y
CONFIG_HW_STACK_PROTECTION=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_GPIO=y
CONFIG_REBOOT=y
CONFIG_SPEED_OPTIMIZATIONS=y
CONFIG_PWM=y
CONFIG_LED=y
CONFIG_LED_PWM=y
CONFIG_LED_GPIO=n
CONFIG_STREAM_FLASH=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_UDC_DWC2_DMA=n
CONFIG_BT_MAX_PAIRED=2
CONFIG_BT_ID_MAX=3
CONFIG_BT_CTLR_SDC_LLPM=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
CONFIG_SPI_NOR=n
CONFIG_NRF_RRAM_WRITE_BUFFER_SIZE=8
CONFIG_ASSERT=y
CONFIG_ASSERT_LEVEL=2
CONFIG_DESKTOP_LOG=y
CONFIG_DESKTOP_LOG_UART=y
CONFIG_DESKTOP_LOG_RTT=y
CONFIG_DESKTOP_DUAL_BUTTON_BOND_ERASE=y

Below is the log from the nrf52840dongle:
app_event_manager: e:module_state_event module:click_detector state:READY
[00000330] <inf> ble_state: Bluetooth initialized
[00000337] <wrn> usb_state: USB suspend
[00000338] <inf> ble_state: LLPM enabled
[00000368] <inf> app_event_manager: e:usb_state_event state:POWERED
[00000369] <inf> app_event_manager: e:usb_state_event state:SUSPENDED
[000[00153557] <inf> ble_scan: Scan stopped
[00153562] <inf> ble_scan: Address filter added EA:17:CB:45:6E:A7 (random)
[00153567] <inf> ble_scan: Address filter added CB:4E:91:DA:BD:F0 (random)
[00153568] <inf> ble_scan: Device name filters added
[00153586] <inf> ble_scan: Scan started
[00153588] <inf> app_event_manager: e:ble_peer_search_event inactive
[00153590] <inf> app_event_manager: e:ble_peer_search_event active
[00153592] <inf> app_event_manager: e:led_event led_id:0 effect:0x59378
[00153593] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00411801] <inf> ble_scan: Filters matched. EA:17:CB:45:6E:A7 (random) connectable
[00411836] <inf> ble_scan: Connecting done
[00413116] <inf> ble_state: Connected to EA:17:CB:45:6E:A7 (random)
[00413135] <inf> app_event_manager: e:ble_peer_event id=0x20004e08 CONNECTED reason=0
[00413138] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004e08 min=8 max=8 lat=0 timeout=400 (updated)
[00413139] <inf> ble_conn_params: Conn params for peer: 0x20004e08 updated.
[00413145] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00413147] <inf> app_event_manager: e:power_manager_restrict_event module "ble_state_pm" restricts to SUSPENDED
[00416184] <inf> ble_state: Security with EA:17:CB:45:6E:A7 (random) level 2
[00416188] <inf> app_event_manager: e:ble_peer_event id=0x20004e08 SECURED reason=0
[00416191] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00418153] <inf> ble_state: MTU exchange done
[00421423] <inf> ble_discovery: LLPM supported
[00426670] <inf> ble_discovery: HW ID: a8fdb1bc10a933cc
[00429943] <inf> ble_discovery: VID: 1915 PID: 52dd
[00434531] <inf> ble_discovery: HIDS discovery procedure succeeded
[00434534] <inf> app_event_manager: e: ble_discovery_complete_event
[00434535] <inf> hid_forward: Subscriber id found (0)
[00434548] <inf> hid_forward: Peripheral 0x20003030 registered and linked to 0x200069a0
[00434549] <inf> ble_scan: Scan stopped
[00434555] <inf> app_event_manager: e:ble_peer_search_event inactive
[00434566] <inf> ble_conn_params: Update conn params for peer: 0x20004e08 (LLPM, requested latency: 0, USB suspended: false)
[00434569] <inf> app_event_manager: e:led_event led_id:0 effect:0x59380
[00434573] <inf> app_event_manager: e:led_ready_event led_id:0 effect:0x59380
[00435078] <inf> ble_scan: Address filter added CB:4E:91:DA:BD:F0 (random)
[00435080] <inf> ble_scan: Device name filters added
[00435098] <inf> ble_scan: Scan started
[00435100] <inf> app_event_manager: e:ble_peer_search_event active
[00435102] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00436830] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004e08 min=d01 max=d01 lat=0 timeout=400 (updated)
[00436830] <inf> ble_conn_params: Conn params for peer: 0x20004e08 updated.
[00437446] <inf> hid_forward: Subscriber to rep id:2
[00437447] <inf> hid_forward: Subscriber to rep id:3
[00437449] <inf> hid_forward: Subscriber to rep id:4
[00437451] <inf> hid_forward: Subscriber to boot keyboard report
[00445970] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004e08 min=6 max=6 lat=0 timeout=400 (required)
[00445971] <inf> ble_conn_params: Request to update conn: 0x20004e08 latency to: 0
[00563113] <inf> ble_scan: Scan stopped
[00563122] <inf> ble_scan: Address filter added CB:4E:91:DA:BD:F0 (random)
[00563123] <inf> ble_scan: Device name filters added
[00563149] <inf> ble_scan: Scan started
[00563151] <inf> app_event_manager: e:ble_peer_search_event inactive
[00563156] <inf> app_event_manager: e:ble_peer_search_event active
[00563158] <inf> app_event_manager: e:led_event led_id:0 effect:0x59380
[00563161] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00894860] <inf> ble_state: Disconnected from EA:17:CB:45:6E:A7 (random) (reason 8)
[00894863] <inf> app_event_manager: e:ble_peer_event id=0x20004e08 DISCONNECTED reason=8
[00894863] <inf> hid_forward: Peripheral 0x20003030 disconnected
[00894875] <inf> ble_scan: Scan stopped
[00894880] <inf> app_event_manager: e:ble_peer_search_event inactive
[00894881] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00894883] <inf> app_event_manager: e:power_manager_restrict_event module "ble_state_pm" restricts to MAX
[00894885] <inf> app_event_manager: e:led_event led_id:0 effect:0x59378
[00894889] <inf> app_event_manager: e:led_ready_event led_id:0 effect:0x59378
[00895398] <inf> ble_scan: Address filter added EA:17:CB:45:6E:A7 (random)
[00895403] <inf> ble_scan: Address filter added CB:4E:91:DA:BD:F0 (random)
[00895404] <inf> ble_scan: Device name filters added
[00895422] <inf> ble_scan: Scan started
[00895425] <inf> app_event_manager: e:ble_peer_search_event active
[00895427] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00903502] <inf> ble_scan: Filters matched. CB:4E:91:DA:BD:F0 (random) connectable
[00903536] <inf> ble_scan: Connecting done
[00904647] <inf> ble_state: Connected to CB:4E:91:DA:BD:F0 (random)
[00904666] <inf> app_event_manager: e:ble_peer_event id=0x20004e08 CONNECTED reason=0
[00904670] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004e08 min=8 max=8 lat=0 timeout=400 (updated)
[00904670] <inf> ble_conn_params: Conn params for peer: 0x20004e08 updated.
[00904677] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00904679] <inf> app_event_manager: e:power_manager_restrict_event module "ble_state_pm" restricts to SUSPENDED
[00908212] <inf> ble_state: Security with CB:4E:91:DA:BD:F0 (random) level 2
[00908216] <inf> app_event_manager: e:ble_peer_event id=0x20004e08 SECURED reason=0
[00908218] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00910181] <inf> ble_state: MTU exchange done
[00913451] <inf> ble_discovery: LLPM supported
[00918698] <inf> ble_discovery: HW ID: b1074904bf97fe7d
[00921971] <inf> ble_discovery: VID: 1915 PID: 52dd
[00926558] <inf> ble_discovery: HIDS discovery procedure succeeded
[00926562] <inf> app_event_manager: e: ble_discovery_complete_event
[00926562] <inf> hid_forward: Subscriber id found (2)
[00926576] <inf> hid_forward: Peripheral 0x20003030 registered and linked to 0x200069b8
[00926577] <inf> ble_scan: Scan stopped
[00926583] <inf> app_event_manager: e:ble_peer_search_event inactive
[00926594] <inf> ble_conn_params: Update conn params for peer: 0x20004e08 (LLPM, requested latency: 0, USB suspended: false)
[00926597] <inf> app_event_manager: e:led_event led_id:0 effect:0x59380
[00926600] <inf> app_event_manager: e:led_ready_event led_id:0 effect:0x59380
[00927110] <inf> ble_scan: Address filter added EA:17:CB:45:6E:A7 (random)
[00927112] <inf> ble_scan: Device name filters added
[00927130] <inf> ble_scan: Scan started
[00927132] <inf> app_event_manager: e:ble_peer_search_event active
[00927134] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[00928858] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004e08 min=d01 max=d01 lat=0 timeout=400 (updated)
[00928858] <inf> ble_conn_params: Conn params for peer: 0x20004e08 updated.
[00929474] <inf> hid_forward: Subscriber to rep id:2
[00929475] <inf> hid_forward: Subscriber to rep id:3
[00929476] <inf> hid_forward: Subscriber to rep id:4
[00929478] <inf> hid_forward: Subscriber to boot keyboard report
[00937474] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004e08 min=6 max=6 lat=0 timeout=400 (required)
[00937475] <inf> ble_conn_params: Request to update conn: 0x20004e08 latency to: 0
[01055145] <inf> ble_scan: Scan stopped
[01055155] <inf> ble_scan: Address filter added EA:17:CB:45:6E:A7 (random)
[01055156] <inf> ble_scan: Device name filters added
[01055185] <inf> ble_scan: Scan started
[01055189] <inf> app_event_manager: e:ble_peer_search_event inactive
[01055194] <inf> app_event_manager: e:ble_peer_search_event active
[01055200] <inf> app_event_manager: e:led_event led_id:0 effect:0x59380
[01055201] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[01185434] <inf> ble_scan: Filters matched. EA:17:CB:45:6E:A7 (random) connectable
[01185474] <inf> ble_scan: Connecting done
[01187911] <inf> ble_state: Connected to EA:17:CB:45:6E:A7 (random)
[01187942] <inf> app_event_manager: e:ble_peer_event id=0x20004ed0 CONNECTED reason=0
[01187945] <inf> app_event_manager: e:ble_peer_conn_params_event peer=0x20004ed0 min=8 max=8 lat=0 timeout=400 (updated)
[01187946] <inf> ble_conn_params: Conn params for peer: 0x20004ed0 updated.
[01187952] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388
[01187955] <inf> app_event_manager: e:power_manager_restrict_event module "ble_state_pm" restricts to SUSPENDED
[01191229] <inf> ble_state: Security with EA:17:CB:45:6E:A7 (random) level 2
[01191233] <inf> app_event_manager: e:ble_peer_event id=0x20004ed0 SECURED reason=0
[01191236] <inf> app_event_manager: e:led_event led_id:0 effect:0x59388

DevAcademy : nRF Connect SDK Intermediate : Lesson 2 Exercise 4 : Need CONFIG_LOG=y

Len Chisholm — Thu, 16 Jul 2026 01:30:19 GMT

With SDK 3.3.1 I do not get the <inf> logging messages when building the Hello World app unless CONFIG_LOG=y is added to prj.conf.

Perhaps this is left as an exercise for the reader!

Nordic AI says "Note that in nRF Connect SDK, CONFIG_LOG (along with CONFIG_LOG_MODE_MINIMAL) is automatically enabled for all samples via CONFIG_NCS_SAMPLES_DEFAULTS." but this doesn't seem to apply for the Hello World sample.

mcuboot does not boot images after migrating to DTS partitioning when CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=y

reavertm — Thu, 16 Jul 2026 00:01:40 GMT

NCS: v3.4.0
Board: custom board based loosely on PAN1783
TF-M not used

Images:
- App core: mcuboot, Firmware (main app)
- Net core: b0n, ipc_radio

Summary of configuration: using sysbuild, DFU using uncompressed images (I am aware of regression NCSDK-38697), image signing. DFU only in mcuboot via serial recovery, nRF DFU done using mcuboot, image store in flash simulator, transferred via pcd to b0n, nothing custom here.

Everything works with Partition Manager:

[0:0:0.38,299] <inf> mcuboot: Starting bootloader
[0:0:0.43,487] <inf> mcuboot: LCS-awareness disabled, skipping LCS check
[0:0:0.51,300] <inf> mcuboot: Image index: 0, Swap type: none
[0:0:0.57,739] <inf> mcuboot: Image index: 1, Swap type: none
[0:0:0.911,468] <inf> mcuboot: Bootloader chainload address offset: 0x16000
[0:0:0.918,853] <inf> mcuboot: Image version: v0.1.0
[0:0:0.924,285] <inf> mcuboot: Jumping to the first image slot

After migrating to DTS partitions (following guide):

[0:0:0.42,602] <inf> mcuboot: Starting bootloader
[0:0:0.47,790] <inf> mcuboot: LCS-awareness disabled, skipping LCS check
[0:0:0.55,603] <inf> mcuboot: Image index: 0, Swap type: none
[0:0:0.62,42] <wrn> mcuboot: Cannot upgrade: slots have non-compatible sectors
[0:0:0.70,68] <wrn> mcuboot: Cannot upgrade: slots have non-compatible sectors
[0:0:0.924,652] <err> mcuboot: Binary in secondary slot of image 1 is not designated for the primary slot
[0:0:0.934,936] <err> mcuboot: Erasing image from secondary slot
[0:0:0.971,954] <err> mcuboot: Unable to find bootable image
[0:0:0.978,271] <inf> mcuboot: Enter the serial recovery mode

sysbuild.conf:

SB_CONFIG_PARTITION_MANAGER=y
SB_CONFIG_NETCORE_APP_UPDATE=y
SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE=...
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE=...
SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y
SB_CONFIG_DFU_ZIP=n

mcuboot.conf snippet:

CONFIG_BOOT_MAX_IMG_SECTORS_AUTO=y

# Software update via serial recovery
CONFIG_BOOT_SERIAL_IMG_GRP_IMAGE_STATE=y
CONFIG_BOOT_SERIAL_NO_APPLICATION=y
CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_DETECT_DELAY=100
CONFIG_MCUBOOT_INDICATION_LED=y
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_STATS=n
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY=n

Disabling CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS (and keeping CONFIG_MCUBOOT_CHECK_HEADER_LOAD_ADDRESS disabled) allows mcuboot to boot main app image, still reporting some "incompatible sectors" nonsense, that did not happen with PM:

[0:0:0.42,602] <inf> mcuboot: Starting bootloader
[0:0:0.47,790] <inf> mcuboot: LCS-awareness disabled, skipping LCS check
[0:0:0.55,603] <inf> mcuboot: Image index: 0, Swap type: none
[0:0:0.62,42] <wrn> mcuboot: Cannot upgrade: slots have non-compatible sectors
[0:0:0.70,68] <wrn> mcuboot: Cannot upgrade: slots have non-compatible sectors
[0:0:0.928,131] <inf> mcuboot: Bootloader chainload address offset: 0x16000
[0:0:0.935,546] <inf> mcuboot: Image version: v0.1.0
[0:0:0.940,948] <inf> mcuboot: Jumping to the first image slot

main app image looks like this:

(v3.4.0) bash-5.3$ ../../external/bootloader/mcuboot/scripts/imgtool.py dumpinfo Firmware/zephyr/zephyr.signed.bin 
Printing content of signed image: zephyr.signed.bin 

#### Image header (offset: 0x0) ############################
magic:              0x96f3b83d
load_addr:          0x16000
hdr_size:           0x200
protected_tlv_size: 0x0
img_size:           0x41a6c
flags:              ROM_FIXED (0x100)
version:            0.1.0+0
############################################################
#### Payload (offset: 0x200) ###############################
|                                                          |
|              FW image (size: 0x41a6c Bytes)              |
|                                                          |
############################################################
#### TLV area (offset: 0x41c6c) ############################
magic:     0x6907
area size: 0x97

Snippet from board file defining partitions:

#include <nordic/nrf5340_cpuapp_partition.dtsi>

/delete-node/ &boot_partition;
/delete-node/ &slot0_partition;
/delete-node/ &slot1_partition;
/delete-node/ &storage_partition;

&flash0 {
	partitions {
		boot_partition: partition@0 {
			compatible = "zephyr,mapped-partition";
			label = "mcuboot";
			reg = <0x0 0x16000>;
		};

		s0_partition: slot0_partition: partition@16000 {
			compatible = "zephyr,mapped-partition";
			label = "image-0";
			reg = <0x16000 0x6c000>;
		};

		s1_partition: slot1_partition: partition@82000 {
			compatible = "zephyr,mapped-partition";
			label = "image-1";
			reg = <0x82000 0x6c000>;
		};

		crash_storage: partition@ee000 {
			compatible = "zephyr,mapped-partition";
			label = "crash-storage";
			reg = <0xee000 0x10000>;
		};

		storage_partition: partition@fe000 {
			compatible = "zephyr,mapped-partition";
			label = "storage";
			reg = <0xfe000 0x2000>;
		};
	};
};

Diffs between .config files:

mcuboot:

--- rh-software-PM/Firmware/build/mcuboot/zephyr/.config        2026-07-15 22:56:49.353212143 +0200
+++ rh-software/Firmware/build/mcuboot/zephyr/.config   2026-07-16 01:58:58.905069184 +0200
@@ -5,7 +5,7 @@
 # CONFIG_BOOT_USE_MIN_PARTITION_SIZE is not set
 CONFIG_PM_PARTITION_SIZE_MCUBOOT_SCRATCH=0x1e000
 CONFIG_PM_PARTITION_SIZE_MCUBOOT_PAD=0x200
-CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x16000
+CONFIG_PM_PARTITION_SIZE_MCUBOOT=0xc000
 CONFIG_MCUBOOT_NRF_CLEANUP_PERIPHERAL=y
 CONFIG_BOOT_SIGNATURE_KEY_FILE="/home/maciek/Projects/ESA-PAD/rh-software/Firmware/priv.pem"
 # CONFIG_BOOT_NRF_EXTERNAL_CRYPTO is not set
@@ -142,6 +142,7 @@
 CONFIG_MULTITHREADING=y
 CONFIG_USB_DEVICE_PRODUCT="MCUBOOT"
 CONFIG_MCUBOOT_BOOTUTIL_LIB_OWN_LOG=y
+# CONFIG_MCUBOOT_CHECK_HEADER_LOAD_ADDRESS is not set
 CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=y
 CONFIG_NCS_MCUBOOT_IMG_VALIDATE_ATTEMPT_COUNT=1
 CONFIG_PM_APP_ALIGNMENT=0x4000
@@ -253,7 +254,6 @@
 CONFIG_GEN_ISR_TABLES=y
 # CONFIG_INIT_STACKS is not set
 CONFIG_TIMESLICE_SIZE=20
-CONFIG_FLASH_LOAD_OFFSET=0x0
 CONFIG_SYS_CLOCK_EXISTS=y
 CONFIG_INIT_ARCH_HW_AT_BOOT=y
 # CONFIG_BUILD_OUTPUT_S19 is not set
@@ -340,9 +340,8 @@
 # Bootloader
 #
 # CONFIG_SECURE_BOOT is not set
-CONFIG_PM_PARTITION_SIZE_PROVISION=0x280
+CONFIG_SB_IMAGE_BOOT_OFFSET=0x200
 # CONFIG_B0_MIN_PARTITION_SIZE is not set
-CONFIG_PM_PARTITION_SIZE_B0_IMAGE=0x8000
 # CONFIG_IS_SECURE_BOOTLOADER is not set
 CONFIG_IS_BOOTLOADER_IMG=y
 # CONFIG_SECURE_BOOT_CRYPTO is not set
@@ -511,15 +510,14 @@
 #
 # Partition Manager
 #
-CONFIG_PARTITION_MANAGER_ENABLED=y
-CONFIG_FLASH_MAP_CUSTOM=y
-CONFIG_SRAM_SIZE=448
-CONFIG_SRAM_BASE_ADDRESS=0x20000000
+# CONFIG_PARTITION_MANAGER_ENABLED is not set
+# CONFIG_FLASH_MAP_CUSTOM is not set
+CONFIG_SRAM_SIZE=440
+CONFIG_SRAM_BASE_ADDRESS=0x20002000
 
 #
 # Zephyr subsystem configurations
 #
-CONFIG_RPMSG_NRF53_SRAM_SIZE=0x10000
 # end of Zephyr subsystem configurations
 
 #
@@ -2615,7 +2613,7 @@
 # CONFIG_LINKER_ORPHAN_SECTION_PLACE is not set
 CONFIG_LINKER_ORPHAN_SECTION_WARN=y
 # CONFIG_LINKER_ORPHAN_SECTION_ERROR is not set
-CONFIG_FLASH_LOAD_SIZE=0x0
+CONFIG_FLASH_USES_MAPPED_PARTITION=y
 CONFIG_ROM_END_OFFSET=0
 CONFIG_LD_LINKER_SCRIPT_SUPPORTED=y
 CONFIG_LD_LINKER_TEMPLATE=y

main app:

--- rh-software-PM/Firmware/build/Firmware/zephyr/.config       2026-07-15 22:57:15.319652144 +0200
+++ rh-software/Firmware/build/Firmware/zephyr/.config  2026-07-15 23:51:19.051591796 +0200
@@ -91,7 +91,7 @@
 CONFIG_CLOCK_CONTROL=y
 CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768
 CONFIG_BUILD_OUTPUT_BIN=y
-CONFIG_ROM_START_OFFSET=0
+CONFIG_ROM_START_OFFSET=0x200
 CONFIG_KERNEL_ENTRY="__start"
 CONFIG_XIP=y
 CONFIG_HAS_FLASH_LOAD_OFFSET=y
@@ -121,7 +121,6 @@
 CONFIG_GEN_ISR_TABLES=y
 # CONFIG_INIT_STACKS is not set
 CONFIG_TIMESLICE_SIZE=20
-CONFIG_FLASH_LOAD_OFFSET=0x0
 CONFIG_SYS_CLOCK_EXISTS=y
 CONFIG_INIT_ARCH_HW_AT_BOOT=y
 # CONFIG_BUILD_OUTPUT_S19 is not set
@@ -233,9 +232,8 @@
 # Bootloader
 #
 # CONFIG_SECURE_BOOT is not set
-CONFIG_PM_PARTITION_SIZE_PROVISION=0x280
+CONFIG_SB_IMAGE_BOOT_OFFSET=0x200
 # CONFIG_B0_MIN_PARTITION_SIZE is not set
-CONFIG_PM_PARTITION_SIZE_B0_IMAGE=0x8000
 # CONFIG_IS_SECURE_BOOTLOADER is not set
 # CONFIG_NRF53_ENFORCE_IMAGE_VERSION_EQUALITY is not set
 
@@ -738,15 +736,14 @@
 #
 # Partition Manager
 #
-CONFIG_PARTITION_MANAGER_ENABLED=y
-CONFIG_FLASH_MAP_CUSTOM=y
-CONFIG_SRAM_SIZE=448
-CONFIG_SRAM_BASE_ADDRESS=0x20000000
+# CONFIG_PARTITION_MANAGER_ENABLED is not set
+# CONFIG_FLASH_MAP_CUSTOM is not set
+CONFIG_SRAM_SIZE=440
+CONFIG_SRAM_BASE_ADDRESS=0x20002000
 
 #
 # Zephyr subsystem configurations
 #
-CONFIG_RPMSG_NRF53_SRAM_SIZE=0x10000
 CONFIG_PM_PARTITION_SIZE_LITTLEFS=0x6000
 CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y
 CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE=0x2000
@@ -762,7 +759,7 @@
 CONFIG_PM_EXTERNAL_FLASH_ENABLED=y
 CONFIG_PM_EXTERNAL_FLASH_PATH="/soc/peripheral@50000000/qspi@2b000/w25q01jv@0"
 CONFIG_PM_EXTERNAL_FLASH_SIZE_BITS=1073741824
-# CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY is not set
+CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
 # CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK is not set
 CONFIG_PM_SRAM_BASE=0x20000000
 CONFIG_PM_SRAM_SIZE=0x80000
@@ -3423,7 +3413,7 @@
 # CONFIG_LINKER_ORPHAN_SECTION_PLACE is not set
 CONFIG_LINKER_ORPHAN_SECTION_WARN=y
 # CONFIG_LINKER_ORPHAN_SECTION_ERROR is not set
-CONFIG_FLASH_LOAD_SIZE=0x0
+CONFIG_FLASH_USES_MAPPED_PARTITION=y
 CONFIG_ROM_END_OFFSET=0xc6
 CONFIG_LD_LINKER_SCRIPT_SUPPORTED=y
 CONFIG_LD_LINKER_TEMPLATE=y
@@ -3517,7 +3507,6 @@
 # CONFIG_EMIT_ALL_SYSCALLS is not set
 # end of Build Options
 
-CONFIG_DEPRECATED=y
 CONFIG_WARN_DEPRECATED=y
 CONFIG_ENFORCE_ZEPHYR_STDINT=y
 # end of Build and Link Features

nRF54L15 DK + nRF7002 EB2 official Wi-Fi shell example problems

Tim012 — Wed, 15 Jul 2026 22:28:34 GMT

Hardware
--------
- nRF54L15 DK
- PCA10156
- nRF54L15_xxAA_REV2
- nRF7002 EB2
- pca63571 rev1

NCS version
-----------
- nRF Connect SDK v3.3.1
- Zephyr v4.3.99

Build
-----
Clean, unmodified NCS v3.3.1 tree.

Exact build command:

--sysbuild -- \
-DSHIELD=nrf7002eb2 \
-DSNIPPET=nrf70-wifi

Generated DTS confirmation
--------------------------
The generated DTS matches the documented nRF54L15 DK + nRF7002 EB2 mapping:

- nRF7002 node: okay
- SPI controller: spi22 / spi@c8000
- SCK: P1.11
- MOSI: P1.06
- MISO: P1.07
- CS: P1.10
- BUCKEN: P1.04
- IOVDDEN: P1.05
- HOST_IRQ: P1.14

Generated config confirms:

- CONFIG_NRF70_SCAN_ONLY is not set
- CONFIG_NRF70_SYSTEM_MODE=y
- CONFIG_NRF70_STA_MODE=y
- CONFIG_WIFI_NRF70=y
- CONFIG_WIFI_NRF7002=y

Observed behaviour
------------------
With the official build flashed, the board is not reaching a usable Wi-Fi shell state reliably.

At the current stage, the board appears to reset or lose the console when the nRF7002 EB2 is fitted.

I do not yet have a clean current UART log from the latest state. An earlier run of the same clean official build reached the Wi-Fi shell but failed nRF7002 bring-up with:

- RPU wakeup write ACK failed even after 10 ms
- RDSR2 failed
- Wi-Fi shell commands present, but `wifi version`, `wifi status`, and `wifi scan` failed

Current question
----------------
Before I continue debugging, I want to confirm whether the setup/build is obviously wrong or whether there is a known nRF54L15 DK + nRF7002 EB2 requirement that is easy to miss.

Questions
---------
Is there anything obviously wrong with this setup?

Is there a known requirement for the nRF54L15 DK + nRF7002 EB2 combination that is easy to miss?

Based on the build command and generated DTS/config above, what would you check next?

Here is the AI questions and responses

1. VCOM1 disabled?

Yes. VCOM1 is disabled in the nRF54L15 DK Board Configurator. Only VCOM0 is connected.

2. Console on VCOM0 / UART30?

Yes. The generated DTS routes the console and shell to UART30 (VCOM0).

3. Pin assignments correct?

Yes. The generated DTS matches the documented nRF7002 EB II pin mapping:

BUCKEN = P1.04
IOVDDEN = P1.05
MOSI = P1.06
MISO = P1.07
CS = P1.10
SCK = P1.11
IRQ = P1.14

4. Firmware blobs installed?

Yes. The nRF70 firmware blobs are present and the build is configured to use them.

5. Build command correct?

Yes. The build targets nrf54l15dk/nrf54l15/cpuapp with the nrf7002eb2 shield and nrf70-wifi snippet.

6. `shell_SHIELD` vs `SHIELD`?

Not an issue. The unscoped SHIELD and SNIPPET options resolve correctly, as confirmed by the generated DTS and configuration.

7. `SHEL:2372` applicable?

No evidence found. I cannot find this issue in the local NCS v3.3.1 documentation or source, so I have not considered it relevant.

nRF9151 (Thingy:91 X): GNSS never acquires satellites after AT+CFUN=1

SidTactacam — Wed, 15 Jul 2026 20:09:45 GMT

Hardware: Thingy:91 X (PCA20065), nRF9151
Firmware: nRF Connect SDK v3.3.0, TF-M non-secure build, mfw_nrf91x1_2.0.2 and mfw_nrf91x1_2.0.4
Config: CONFIG_LTE_NETWORK_MODE_LTE_M_GPS, MODEM_ANTENNA lib enabled with the Thingy:91 X defaults (%XCOEX0=1,1,1565,1586, %XMIPIRFFEDEV, %XMIPIRFFECTRL init/on/off/pwroff)
Network: LTE-M (AcT 7), US carrier, CEREG registers status 5
GNSS API: nrf_modem_gnss, event handler installed after nrf_modem_lib_init, 1 Hz PVT events arrive in all cases below

Problem:
Once AT+CFUN=1 has run, GNSS stops acquiring satellites. PVT frames keep coming at 1 Hz with zero tracked satellites, outdoors under open sky, for as long as we let it run (up to 420 s). This holds in LTE-M+GPS coexistence and also in GNSS-only mode entered afterward with AT+CFUN=31. The only recovery is a stop at AT+CFUN=0 followed by starting GNSS from AT+CFUN=31.

Reproduction:
Fails: reboot -> AT+CFUN=1 -> wait for +CEREG: 0,5 -> AT+CFUN=31 -> nrf_modem_gnss_start -> no satellites in 150 s.
Works: reboot -> AT+CFUN=31 -> nrf_modem_gnss_start -> fix in less than 25 seconds.

Full test matrix (open sky, 4+ satellites available):
boot -> CFUN=31 fix 22.6 s
boot -> CFUN=1 -> reg -> CFUN=31 no fix
boot -> CFUN=1 -> reg -> %XCOEX0 (returns OK) -> CFUN=31 no fix
boot -> CFUN=1 -> reg -> CFUN=0 -> CFUN=31 fix 35.0 s
boot -> CFUN=0 -> CFUN=1 -> reg -> GNSS start no fix
boot -> CFUN=1 -> A-GNSS inject -> CFUN=0 -> CFUN=1-> GNSS start no fix
fix, then seconds later GNSS start under CFUN=1 fix 2.3 s

Additional observations:
- %XCOEX0 written while CFUN=1 returns OK but has no observable effect, but written at CFUN=0 it behaves normally.
- Hot re-acquisition under LTE works, as indicated above. So the failure looks specific to cold/warm search, not to GNSS radio time-sharing as such. But I could be wrong
- One occurrence on 2.0.2: after repeated cycles of these tests the SiP stopped responding entirely (no UART, no AT) and only full power removal recovered it. The mfw_nrf91x1_2.0.3 release notes mention "In some cases with non-optimal application behavior, the modem could enter an unrecoverable state" under GNSS and LTE interoperability. So, we upgraded to 2.0.4 for that reason, but the failure above is unchanged.

Questions:
1. Is GNSS cold acquisition expected to work when GNSS is activated with AT+CFUN=31 after LTE has been active, without passing through AT+CFUN=0?
2. Is there a known issue matching this on mfw_nrf91x1 2.0.x?
3. What do you need to progress this? We can provide a modem trace of the failing and working sequences on request.

nRF Connect on iOS not receiving extended advertisements above ~120 bytes

Greg Strange — Wed, 15 Jul 2026 15:46:18 GMT

Hi,

We have been testing extended advertisements from both an existing product with a nRF52840, and using a Thingy53 dev kit. On the receiving end we have used nRF Connect on Android phones and three separate iPhones (iPhone 15, 15 Plus and 17 Pro running iOS 26 and 27 beta). nRF Connect on Android receives and displays the advertising data just fine. On the iPhones the advertisements are received and displayed fine until around 120 bytes. Anything larger than that does not get reported at all. I have seen mentions of a 124 byte limit on iOS, but those mentions tend to be very old (more than 5 years), and other sources on the internet seems to think it should work up to 250 bytes.

The nRF52840 is running the old nRF5 SDK (15.3.0 with soft device S140). The Thingy53 is running Zephyr. So it seems unlikely that it is a Nordic software issue on the device side unless we are configuring the advertisements incorrect in both cases.

Do you know of any limitations or reasons we would not see the advertisements on iOS when larger than ~120 bytes? Has Nordic tested extended advertisements > 125 bytes from a Nordic chip to iOS nrf Connect? Any suggestions on parameters we should be checking?

Thanks,

- Greg

HFXO (32 MHz crystal) never starts on nRF52840-CKAA (WLCSP), custom flex PCB — MPSL ASSERT: 5, 1013 while trying to initiate BLE (NCS v3.4.0)

plabon — Wed, 15 Jul 2026 10:27:28 GMT

Hardware

Custom flex PCB (smart-ring form factor), SoC: nRF52840-CKAA-R7 (WLCSP package)
Supply: nPM1100 buck (VOUTB) at 1.8 V, normal voltage mode
HFXO: 32 MHz crystal (X2) with 12 pF load capacitors on XC1/XC2 — exact crystal model and full schematic attached
Soldering and connectivity have been verified by X-ray inspection — the crystal and MCU balls show no opens, bridges, or head-in-pillow defects. This is not an assembly issue.
The identical firmware on our nRF52840-QFAA (QFN48) test board works normally — HFXO starts and BLE advertises.

Software

nRF Connect SDK v3.4.0 (Zephyr 4.4.0), SoftDevice Controller + MPSL, sysbuild
CONFIG_MPSL_HFCLK_LATENCY=1400 (default), CONFIG_BT=y, CONFIG_BT_PERIPHERAL=y
Tools: nrfjprog 10.24.2, J-Link V8.18

Symptom

The 32 MHz crystal oscillator never starts on this board.

Register-level test (BLE disabled, direct register access from main()): clear EVENTS_HFCLKSTARTED, trigger TASKS_HFCLKSTART, poll — EVENTS_HFCLKSTARTED never fires (we wait 500 ms; normal startup on the QFAA board is well under 1 ms). HFCLKSTAT keeps reporting SRC=RC. The CPU runs fine on HFINT the whole time; everything else on the chip works (GPIO, SAADC, TWIM, SWD/RTT).
Consequently, with CONFIG_BT=y the boot crashes ~190 ms in, during MPSL init:

<err> mpsl_init: MPSL ASSERT: 5, 1013
[00:00:00.192,169] <err> os: ***** HARD FAULT *****
[00:00:00.192,199] <err> os: ARCH_EXCEPT with reason 3
[00:00:00.192,413] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:00.192,443] <err> os: Fault during interrupt handling
[00:00:00.192,474] <err> os: Current thread: 0x20007f18 (idle)

The LFXO (32.768 kHz, X1) is working fine.

Attachments

HFXO manufacturer part no: X201632MKB4SI

Datasheet: https://www.lcsc.com/datasheet/C718072.pdf?spm=wm.sxq.inf.ggs&lcsc_vid=TwcIAgUAFFkIUVEFR1gKUAEFR1NXUgYDFVJXV1FUFFQxVlNeQ1FcX11RR1RXUTsOAxUeFF5JWBYZEEoBGA4JCwFIFA4DSA%3D%3D

Schematic

Nordic Q&A - Recent Threads

Unable to detect external device when programming custom PCB with nrf5340 via JTAG and nrf5340DK

SVCALL(SD_POWER_GPREGRET_SET, uint32_t, sd_power_gpregret_set(uint32_t gpregret_id, uint32_t gpregret_msk));

Channel Sounding: counter-intuitive repetition behavior + non-configurable event interval (nRF54L15)

Dual mode on nrf5340 - Receive Bluetooth classic/LE->12s, simultaneous with i2s->unicast to different device

nRF Cloud — account auth broken: REST API key (40100) AND device CoAP (-13)

COEX0 load capacitance and VDD decoupling differences

Unexplained current spikes during sleep

NCS subsys/esb: PTX never gets ACK from a receiver that ACKs LOGITacker's identical payload (DPL S1 bit)

nRF54L15 PWM precise frequency output for Active Stylus (470.970 kHz) – internal limitation analysis

NCS SDK v3.3.0 download is extremely slow and restarts before completion

nRF9151: GCI searches returning limited results

nRF9151 DK (LACA A1A) - UICC failure, card responds on I/O but modem reports NO ATR

nRF54L15 + NCS v3.4.0: MCUboot fails with "Firmware has been invalidated: 0xffff0000" when using NSIB + MCUboot + BLE FOTA

psa_aead_finish with CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y generates incorrect tag for AES-GCM

nPM1100 ship mode

CS procedures never start after CS security enable — channel_sounding_ras_reflector stuck on nRF54L15DK with Android 17 (Pixel 10) + nRF Toolbox v4.3.2

Peripheral Registers Not Visible in Keil Debug Session (NRF52840)

nRF54LM20A USB HID device

How to connect two Keyboards with the Desktop sample

DevAcademy : nRF Connect SDK Intermediate : Lesson 2 Exercise 4 : Need CONFIG_LOG=y

mcuboot does not boot images after migrating to DTS partitioning when CONFIG_MCUBOOT_VERIFY_IMG_ADDRESS=y

nRF54L15 DK + nRF7002 EB2 official Wi-Fi shell example problems

1. VCOM1 disabled?

2. Console on VCOM0 / UART30?

3. Pin assignments correct?

4. Firmware blobs installed?

5. Build command correct?

6. shell_SHIELD vs SHIELD?

7. SHEL:2372 applicable?

nRF9151 (Thingy:91 X): GNSS never acquires satellites after AT+CFUN=1

nRF Connect on iOS not receiving extended advertisements above ~120 bytes

HFXO (32 MHz crystal) never starts on nRF52840-CKAA (WLCSP), custom flex PCB — MPSL ASSERT: 5, 1013 while trying to initiate BLE (NCS v3.4.0)

6. `shell_SHIELD` vs `SHIELD`?

7. `SHEL:2372` applicable?