https://devzone.nordicsemi.com/f/nordic-q-a/128226/options-for-flashing-nrf9151-with-production-firmware-without-j-link/566821Mon, 25 May 2026 12:10:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:4d3cb9bc-df7f-4b43-82ee-edfdd962fcf3Achim KrausThere are some boards using a onboard-RP2040 probe and https://probe.rs/ with github.com/.../modem_updater , e.g. nrf9151-feather . For the feather it works well, I don't know, if it works for a RP2040 stand alone probe.https://devzone.nordicsemi.com/f/nordic-q-a/127831/power-consumption---dwm3001c/566820Mon, 25 May 2026 11:20:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8057643d-4b79-4e67-8a1d-dd325284aabcBraxatorisHello, sorry for my late reply. Version of SDK is 2.7.0 and there is nothing which could consume power except LIS2DH12. Sensor is in ODR10 LOW POWER MODE which should average on 3uA if we believe datasheet. So measurement should be skewed by it but not that much. Can you tell me how to make sure there arent any leaking GPIO ?https://devzone.nordicsemi.com/f/nordic-q-a/128231/ncs-2-9-0-wi-fi-softap-ble-coexistence-2x-nrf5340-nrf7002-complete-wi-fi-starvation-upon-ble-adv-start-leading-to-rpu-crashMon, 25 May 2026 10:37:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b6698ff5-7cb3-40b5-9b60-c96073609535wbezsHello Nordic Support, We are developing a project using two setsof nRF5340 DK with the nRF7002 EK attached. We are trying to achieve coexistence between Wi-Fi in SoftAP mode and BLE in Peripheral mode (Advertising) using NCS 2.9.0. The application builds successfully, the system boots without IPC deadlocks, the Wi-Fi AP initializes, and a station can connect perfectly. However, the exact moment we initialize the BLE stack and start advertising (`bt_le_adv_start()`), the Wi-Fi interface is completely starved on the TX side. Furthermore, after exactly 5 minutes of this starvation, the nRF7002 RPU crashes with an invalid memory address error via SPI (`0xAAAAAAAA`). Symptoms: 1. SoftAP starts, Station connects, UDP handshake is ready. 2. We wait for the Station to be fully connected before calling `bt_le_adv_start()`. 3. Once BLE Advertising starts, the Wi-Fi radio stops sending all packets (including Beacons). 4. The connected Station (Node B) inevitably drops the connection within a 20-second timeframe due to missing Beacons. 5. Crucial Observation: If we use a "mock" BLE implementation (software bypass without activating the actual MPSL radio), the Wi-Fi SoftAP maintains the connection perfectly indefinitely (Current testing range was aprox. 2h) 6. If left running with BLE active, the Wi-Fi driver throws a fatal SPI/RPU memory error after 5 minutes (likely during WPA key rotation or timeout cleanup when the chip is unresponsive). Boot Log: [00:00:00.345,520] wifi_nrf_bus: SPIM spi@a000: freq = 8 MHz [00:00:00.345,550] wifi_nrf_bus: SPIM spi@a000: latency = 0 [00:00:00.494,689] wifi_nrf: Management buffer offload enabled *** Booting nRF Connect SDK v2.9.0-7787b2649840 *** *** Using Zephyr OS v3.7.99-1f8f3dc29142 *** [00:00:00.518,981] app_main: Starting... [00:00:00.519,012] objscn: initialized. [00:00:00.519,104] app_main: Requesting SoftAP enable... [00:00:00.519,134] app_main: Wi-Fi MAC not ready, retrying in 500ms... (10 left) [00:00:00.520,843] wifi_supplicant: wpa_supplicant initialized [00:00:10.109,558] app_main: [EVENT] SoftAP MAC layer is fully active. [00:00:10.109,558] app_main: Wifi hardware MAC: F4:CE:36:00:17:9E [00:00:10.110,687] app_main: SoftAP is active. Firmware loaded safely without SPI collision. [00:00:10.110,778] app_main: Waiting for Node B to connect... [00:00:13.710,601] app_main: [EVENT] Node B (Sonda) physically joined the AP! [00:00:13.711,730] app_main: Node B connected! Starting BLE system & advertising. [00:00:13.711,730] app_main: Initializing BLE System IPC (MPSL)... [00:00:13.742,767] bt_hci_core: HW Platform: Nordic Semiconductor (0x0002) [00:00:13.742,797] bt_hci_core: HW Variant: nRF53x (0x0003) [00:00:13.742,828] bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 45.41337 Build 3074452168 [00:00:13.745,147] bt_hci_core: Identity: EC:B7:63:ED:2F:47 (random) [00:00:13.745,147] bt_hci_core: HCI: version 6.0 (0x0e) revision 0x206b, manufacturer 0x0059 [00:00:13.745,178] bt_hci_core: LMP: version 6.0 (0x0e) subver 0x206b [00:00:13.745,208] blescn: BLE System IPC initialized [00:00:14.247,650] blescn: BLE Advertising successfully started (Name:master) [00:00:14.247,680] app_main: UDP Server listening on port 4242 // 5 minutes of Wi-Fi silence later... [00:05:13.635,925] wifi_nrf: hal_rpu_mem_write: Invalid memory address 0xAAAAAAAA [00:05:13.636,016] wifi_nrf: hal_rpu_msg_write: Copying information to RPU failed [00:05:13.636,077] wifi_nrf: hal_rpu_cmd_process_queue: Writing command to RPU failed [00:05:13.636,108] wifi_nrf: nrf_wifi_wpa_supp_sta_get_inact_sec: nrf_wifi_fmac_get_station failed objscn:~$ Meanwhile node B: [00:00:11.619,689] app_station: [EVENT] Wi-Fi Handshake Complete! Connected. [00:00:31.571,319] app_station: Connection lost! Self-healing active... Hardware & Build Setup: Board:`nrf5340dk/nrf5340/cpuapp/ns` Shields applied via Sysbuild: `--shield "nrf7002ek nrf7002ek_coex"` (also passed to the net core via `-Dipc_radio_SHIELD="nrf7002ek_coex"`). Relevant Application `prj.conf`: CONFIG_WIFI=y CONFIG_WIFI_NRF70=y CONFIG_NRF70_AP_MODE=y CONFIG_WIFI_NM_WPA_SUPPLICANT_AP=y CONFIG_BT=y CONFIG_BT_PERIPHERAL=y CONFIG_BT_MAX_CONN=2 # Coex Configuration CONFIG_NRF70_SR_COEX=y CONFIG_NRF70_SR_COEX_RF_SWITCH=y CONFIG_MPSL_CX=y CONFIG_MPSL_CX_NRF700X=y # RPC disabled as per the official ble_coex sample to avoid IPC endpoint bond timeouts CONFIG_NRF_RPC=n Relevant Net Core (`sysbuild/ipc_radio/prj.conf`): CONFIG_MBOX=y CONFIG_IPC_SERVICE=y CONFIG_BT=y CONFIG_BT_HCI_RAW=y CONFIG_BT_MAX_CONN=2 CONFIG_IPC_RADIO_BT=y CONFIG_IPC_RADIO_BT_HCI_IPC=y # Coex enabled on net core CONFIG_MPSL=y CONFIG_MPSL_CX=y CONFIG_MPSL_CX_NRF700X=y What we have already verified: 1. `CONFIG_MPSL_CX_NRF700X=y` is correctly set on both `cpuapp` and `cpunet` (ipc_radio). 2. We removed any huge Event Length Kconfigs (like `CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT`) that might monopolize the PTA. 3. We aligned HCI buffers to avoid `opcode 0x0c33` HCI errors. 4. Baseline Testing: We ran the unmodified samples/wifi/ble_coex from NCS 2.9.0. It initializes properly and successfully connects to a Wi-Fi network. However, we noticed the standard sample runs the Wi-Fi in STATION mode. Our requirement is strictly SoftAP mode. It appears the hardware PTA arbiter gives 100% priority to the BLE stack once initialized, completely ignoring the SoftAP's strict requirement to send periodic Beacons and data. Questions: 1. We observed that the official ble_coex sample works flawlessly because the Wi-Fi operates in STATION mode (utilizing Power Save to yield the antenna to BLE). However, SoftAP cannot sleep and must respect strict TBTT (Target Beacon Transmission Time). Does the current MPSL Coex framework in NCS 2.9.0 natively support dynamic time-slicing for SoftAP mode, or is the PTA arbiter designed to give exclusive priority to BLE Advertising, inherently starving the AP? 2. If SoftAP coexistence is supported, is there a specific Kconfig, low-level API call, or Zephyr Wi-Fi management command required to enforce Beacon priority so the nRF7002 is not muted by the BLE controller? 3. Given the board definition updates in NCS 2.9.x, does appending --shield "nrf7002ek_coex" via Sysbuild create a pin allocation conflict or override the default Devicetree routing in a way that breaks the GRANT signal from the net core? Should this specific shield overlay be omitted when building for nrf5340dk/nrf5340/cpuapp/ns ? Thank you in advance for your guidance.beaconsEvaluationconfigurationzephyrhardwarenRF5340https://devzone.nordicsemi.com/f/nordic-q-a/128227/nb-iot-sim-options-for-nrf9160-in-india/566819Mon, 25 May 2026 10:18:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:adaf1ee4-ca35-446d-b682-c02c9d5976d0Paper IO GameFrom what I've seen recently, Jio is currently the most reliable NB-IoT network for nRF9160 in India, but most deployments still use private enterprise onboarding and non-IP data paths, so for small-scale R&D many developers end up testing with LTE-M fallback where available or using international IoT SIM providers until they can secure proper Jio enterprise provisioning. paper iohttps://devzone.nordicsemi.com/f/nordic-q-a/128230/no-device-npm1300_ek-one-button-sample-with-nrf52-dk-on-i2c-busMon, 25 May 2026 09:59:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b019458e-b928-41a7-a3e6-a073eb5b1f2enRF52_DK_usrI try to get the one button sample to work. There were several details missing to be able to compile and run this sample, which was very frustrating. After editing/updating the prj.conf: CONFIG_I2C=y CMakeLists.txt: set(SHIELD npm1300_ek) nrf52dk_nrf52832.overlay: #include &i2c1 { status = "okay"; pinctrl-0 = ; pinctrl-1 = ; pinctrl-names = "default", "sleep"; clock-frequency = ; //clock-frequency = ; }; &i2c1_default { group1 { psels = , ; bias-pull-up; }; }; &i2c1_sleep { group1 { psels = , ; low-power-enable; }; }; My zephyr.dts i2c1 snippet: /* node '/soc/i2c@40004000' defined in zephyr/dts/arm/nordic/nrf52832.dtsi:172 */ i2c1: i2c@40004000 { #address-cells = ; /* in zephyr/dts/arm/nordic/nrf52832.dtsi:181 */ #size-cells = ; /* in zephyr/dts/arm/nordic/nrf52832.dtsi:182 */ reg = ; /* in zephyr/dts/arm/nordic/nrf52832.dtsi:183 */ interrupts = ; /* in zephyr/dts/arm/nordic/nrf52832.dtsi:184 */ easydma-maxcnt-bits = ; /* in zephyr/dts/arm/nordic/nrf52832.dtsi:185 */ zephyr,pm-device-runtime-auto; /* in zephyr/dts/arm/nordic/nrf52832.dtsi:187 */ compatible = "nordic,nrf-twi"; /* in zephyr/boards/nordic/nrf52dk/nrf52dk_nrf52832.dts:188 */ status = "okay"; /* in ../../../../mnt/df01dc22-f3bf-40d5-9858-752a58c9832d/devprojects/nordicsemi/npm13xx_one_button/build/npm13xx_one_button/zephyr/boards/nrf52dk_nrf52832.overlay:9 */ pinctrl-0 = ; /* in ../../../../mnt/df01dc22-f3bf-40d5-9858-752a58c9832d/devprojects/nordicsemi/npm13xx_one_button/build/npm13xx_one_button/zephyr/boards/nrf52dk_nrf52832.overlay:10 */ pinctrl-1 = ; /* in ../../../../mnt/df01dc22-f3bf-40d5-9858-752a58c9832d/devprojects/nordicsemi/npm13xx_one_button/build/npm13xx_one_button/zephyr/boards/nrf52dk_nrf52832.overlay:11 */ pinctrl-names = "default", "sleep"; /* in ../../../../mnt/df01dc22-f3bf-40d5-9858-752a58c9832d/devprojects/nordicsemi/npm13xx_one_button/build/npm13xx_one_button/zephyr/boards/nrf52dk_nrf52832.overlay:12 */ clock-frequency = ; /* in ../../../../mnt/df01dc22-f3bf-40d5-9858-752a58c9832d/devprojects/nordicsemi/npm13xx_one_button/build/npm13xx_one_button/zephyr/boards/nrf52dk_nrf52832.overlay:13 */ }; with claudes assistance/support i got it to compile and run. But an i2c scan i2c0 shows no device at all. What minimal required steps/configuration have to setup to get I2C enabled and detect devices on the bus should be? Trying with the nrf-connect (Ubuntu) Linux-Desktop app (2x USB -C, 1x LiPo Battery) i get NPM detected, the LiPo Battery to and can change parameters for ex. the LED's live, so the BOARD is working. Any support/hint/help is appreciated.developmenthardwarenPM1300https://devzone.nordicsemi.com/f/nordic-q-a/127854/sdc-assertion-13-451/566818Mon, 25 May 2026 09:18:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:5e60194e-8553-441a-aa65-8e13a9b3e1eeHayden BallTo follow up: we haven't seen any failures since updating to the patch linked above. The deadlock we were seeing was an issue we had introduced, which we've now resolved.https://devzone.nordicsemi.com/f/nordic-q-a/128229/nrf54-nrf52-max-rangeMon, 25 May 2026 08:45:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d5aa733c-c4a4-4ecc-bd6f-7223d5937bd0koegWhat kind of range would be possible with the nrf54/52 with any kind of protocol?EvaluationnRF54L15hardwarehttps://devzone.nordicsemi.com/f/nordic-q-a/128228/nrf54l15-ble-advertising-not-seen-in-mobile-apps/566817Mon, 25 May 2026 08:09:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e8d3275b-8921-471c-baf9-12066bfcb5a2jLYV3rHi Nishant, thanks for your quick response. I was able to sort it out - it wasn't a problem with the scan response. I built the Zephyr Beacon sample for the BL54L15u DVK, and see there, it popped up immediately. So I was sure that it had to be something within the default DTS/Kconfigs, comparing the DTS I saw that the BL54L15u DVK has explicitly set; &lfxo { load-capacitors = "internal"; load-capacitance-femtofarad = ; }; &hfxo { load-capacitors = "internal"; load-capacitance-femtofarad = ; }; I did not have these explicit values set; after applying this in my case, the ADV was immediately picked up by the nRF Connect app on Android, so I guess this solves my problem - still have to do some research on why that is ;) My guess is that this messes up some timings, which results in Android/iOS dropping the packets, but it still is weird, as I was able to connect and communicate between nRFs perfectly fine...https://devzone.nordicsemi.com/f/nordic-q-a/128200/nrf52805-dfu-not-working/566816Mon, 25 May 2026 07:56:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:f7088f79-21a6-491b-b703-cd23c2821a89shionThank you for the fast response. Yes, as you pointed out, I am using FDS. As you suggested, reducing the firmware size resolved the error, and the DFU process now works correctly.I was not aware that the FDS usage is included in NRF_DFU_APP_DATA_AREA_SIZE, so I had assumed that the application firmware size itself was within acceptable limits. It also appears that this is not reflected in the "app_size : xxxxx" output from the "nrfutil pkg display APP-FWxxx.zip" command. In any case, I sincerely appreciate your accurate and helpful advice.https://devzone.nordicsemi.com/f/nordic-q-a/128117/54l15-ncs3-2-4-nlc-mesh--pst-certification/566815Mon, 25 May 2026 07:00:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b4623345-822a-484a-b363-b603e52573d0liujyHi Amanda： Thank you very much for your reply. The default value of CONFIG_BT_MESH_MSG_CACHE_SIZE in the sample is 64. I ran the test again,BV-03-I still failed. Could you please take a look at the log？ devzone.nordicsemi.com/.../Report_5F00_MESH_5F00_2026_5F00_05_5F00_23_5F00_17_5F00_27_5F00_26.ziphttps://devzone.nordicsemi.com/f/nordic-q-a/128227/nb-iot-sim-options-for-nrf9160-in-india/566814Mon, 25 May 2026 05:52:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d6d28d55-604a-4844-a595-35b9b2679f62Nishant GauravHi, I’ve been using Jio NB-IoT with the nRF9151 since last year and my experience has been quite stable overall. I’ve tested it across 7–8 states in India, including Bangalore and Chennai, and the device was able to attach and exchange data reliably in most locations. From my setup, Jio is working in standard APN/IP mode — I’m not using NIDD. My configuration uses an APN-based connection (in my case jionpiot ). You should confirm the exact APN and provisioning details with your local Jio distributor/M2M contact because they sometimes provision different profiles depending on the SIM type and region. A few things that helped in my case: Band lock made a noticeable difference in some areas. Keeping the modem restricted to NB-IoT only improved attach stability. Verifying that the SIM is actually provisioned for NB-IoT data (not just LTE-M/general M2M) is important. For small quantities, I was able to get development quantities through a distributor rather than going through the full enterprise onboarding path directly. Overall, compared to Airtel, Jio has been much more reliable for NB-IoT in my testing so far. thanks and regards Nishanthttps://devzone.nordicsemi.com/f/nordic-q-a/128228/nrf54l15-ble-advertising-not-seen-in-mobile-apps/566813Mon, 25 May 2026 05:44:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:32619fdc-5b8e-4816-89c8-cfea039f219dNishant GauravHi, jLYV3r Try temporarily removing the scan response (sd) entirely and see if the device appears in mobile apps with just the advertising packet. To remove the scan response, simply pass NULL and 0 for the scan response parameters in bt_le_adv_start(). err = bt_le_adv_start(&param, ad, ARRAY_SIZE(ad), NULL, 0); if (err) { LOG_ERR("Advertising failed to start (err %d)", err); return; } By passing NULL instead of sd and 0 instead of ARRAY_SIZE(sd), no scan response packet will be sent. This was confirmed to produce a valid ADV_NONCONN_IND (or connectable, depending on your params) advertising packet visible in Wireshark. [Non-connectable advertising] Since your param uses BT_LE_ADV_OPT_CONN, the device will still advertise as connectable — just without the scan response. If mobile apps can now see the device, it confirms the issue is in your sd array (likely the sizeof(CONFIG_BT_DEVICE_NAME) length problem discussed earlier). thanks & regards Nishanthttps://devzone.nordicsemi.com/f/nordic-q-a/128090/websocket-tls-connection-stuck-issue/566812Mon, 25 May 2026 05:03:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:850d00ab-5ba8-40cd-8a6a-588047d074b7DipeshParikh_Hi, Here I'm Providing you to zephyr.elf & zephyr.map files. devzone.nordicsemi.com/.../7282.zephyr.zip [quote userid="106736" url="~/f/nordic-q-a/128090/websocket-tls-connection-stuck-issue/566790"] Can you log the reason why the Wi-Fi lost the stop server? [/quote] We are getting the reset reason unspecified. providing you the logs for reference. [14:00:24.910,003] NK_Timer: HubStatus cycle start 00> [14:00:24.910,003] NK_Timer: Stopping WebSocket 00> [14:00:24.923,400] nk_ws: WS stopped 00> [14:00:24.923,431] NK_Timer: WS RX Timer periodic timer stopped 00> [14:00:24.923,431] NK_Timer: WS Ping periodic timer stopped 00> [14:00:24.923,461] NK_Timer: HubStatus: resolve server 00> [14:00:24.923,461] nk_net_conn: ========== DNS RESOLVE START ========== 00> [14:00:24.923,492] nk_net_conn: Host : api.nexkey.com 00> [14:00:24.923,522] nk_net_conn: Port : 443 00> [14:00:29.929,046] wifi_nrf: nrf_wifi_wpa_supp_signal_poll: Failed to get station info, ret = -11[0m 00> [14:00:29.930,908] wifi_mgr: ========== WIFI DISCONNECTED ========== 00> [14:00:29.930,908] wifi_mgr: Disconnect Count : 1 00> [14:00:29.930,908] wifi_mgr: Disconnect status : 0 00> [14:00:29.931,182] nk_net_conn: RSSI : -9999 00> [14:00:29.931,213] nk_net_conn: System Uptime : 50429 sec 00> [14:00:29.931,243] nk_net_conn: Thread : �b 00> [14:00:29.931,243] nk_net_conn: ======================================= 00> [14:00:29.931,243] nk_net_conn: [DNS] Attempt=1 00> [14:00:29.959,533] wifi_mgr: RSSI Before Drop : -46 00> [14:00:29.959,564] wifi_mgr: IP Before Drop : 192.168.201.11 00> [14:00:29.959,594] wifi_mgr: SSID : Nextkey 00> [14:00:29.959,625] wifi_mgr: System Uptime : 50429959 00> [14:00:29.959,625] wifi_mgr: ====================================== 00> [14:00:29.959,625] wifi_mgr: Disconnect Reason : UNSPECIFIED 00> [14:00:29.959,686] wifi_mgr: Iface State : 4 00> [14:00:29.959,686] wifi_mgr: Iface RSSI : 0 00> [14:00:29.959,686] wifi_mgr: Iface Channel : 0 00> [14:00:29.959,686] nk_net_mgr: NET Manager stop 00> [14:00:29.959,716] nk_net_conn: Server disconnected 00> [14:00:29.959,716] nk_ws: WS stopped 00> [14:00:29.959,716] NK_Timer: WS RX Timer periodic timer stopped 00> [14:00:29.959,747] NK_Timer: WS Ping periodic timer stopped 00> [14:00:29.959,747] wifi_mgr: WiFi Disconnected 00> [14:00:29.959,747] NK_Timer: HubStatus periodic timer stopped 00> [14:00:30.053,833] NK_Timer: WiFi monitor timer stopped 00> [14:00:30.058,410] wifi_mgr: ========== WIFI CONNECTED ========== 00> [14:00:30.058,410] wifi_mgr: Connect Count : 2 00> [14:00:30.058,410] wifi_mgr: Status : 0 00> [14:00:30.058,441] wifi_mgr: SSID : Nextkey 00> [14:00:30.058,441] wifi_mgr: RSSI : -46 00> [14:00:30.058,471] wifi_mgr: MAC : 00:18:07:01:59:4C 00> [14:00:30.058,502] wifi_mgr: ==================================== 00> [14:00:32.033,813] nk_net_conn: [DNS] Duration=2102 ms 00> [14:00:32.033,813] nk_net_conn: [DNS] FAILED 00> [14:00:32.033,843] nk_net_conn: [DNS] getaddrinfo err=-3 00> [14:00:32.033,874] nk_net_conn: [DNS] errno=0 (Success) 00> [14:00:32.037,872] nk_net_conn: [DNS] RSSI=-47 00> [14:00:32.037,872] nk_net_conn: [DNS] WiFi Connected=1 00> [14:00:32.037,872] nk_net_conn: [DNS] Retry remaining=2 00> [14:00:34.037,963] nk_net_conn: [DNS] Attempt=2 00> [14:00:34.038,269] nk_net_conn: [DNS] Duration=1 ms 00> [14:00:34.038,299] nk_net_conn: [DNS] FAILED 00> [14:00:34.038,299] nk_net_conn: [DNS] getaddrinfo err=-11 00> [14:00:34.038,330] nk_net_conn: [DNS] errno=2 (No such file or directory) 00> [14:00:34.042,327] nk_net_conn: [DNS] RSSI=-51 00> [14:00:34.042,327] nk_net_conn: [DNS] WiFi Connected=1 00> [14:00:34.042,358] nk_net_conn: [DNS] Retry remaining=1 00> [14:00:36.042,419] nk_net_conn: [DNS] Attempt=3 00> [14:00:36.042,724] nk_net_conn: [DNS] Duration=0 ms 00> [14:00:36.042,755] nk_net_conn: [DNS] FAILED 00> [14:00:36.042,755] nk_net_conn: [DNS] getaddrinfo err=-11 00> [14:00:36.042,785] nk_net_conn: [DNS] errno=2 (No such file or directory) 00> [14:00:36.046,813] nk_net_conn: [DNS] RSSI=-50 00> [14:00:36.046,813] nk_net_conn: [DNS] WiFi Connected=1 00> [14:00:36.046,813] nk_net_conn: [DNS] Retry remaining=0 00> [14:00:38.046,905] nk_net_conn: ========== DNS RESOLVE FAILED ========== 00> [14:00:38.046,905] nk_net_conn: All retries exhausted 00> [14:00:38.046,936] nk_net_mgr: NET Manager start 00> [14:00:38.046,936] nk_ws: WS stopped 00> [14:00:38.046,936] NK_Timer: WS RX Timer periodic timer stopped 00> [14:00:38.046,936] NK_Timer: WS Ping periodic timer stopped 00> [14:00:38.046,966] NK_Timer: HubStatus failed → DNS resolve 00> [14:00:38.047,088] NK_Timer: Watchdog not Feed 00> [14:00:38.049,346] nk_net_mgr: STATE: RESOLVE 00> [14:00:38.049,346] nk_net_conn: ========== DNS RESOLVE START ========== 00> [14:00:38.049,377] nk_net_conn: Host : api.nexkey.com 00> [14:00:38.049,407] nk_net_conn: Port : 443 00> [14:00:38.054,168] nk_net_conn: RSSI : -47 00> [14:00:38.054,168] nk_net_conn: System Uptime : 50438 sec 00> [14:00:38.054,199] nk_net_conn: Thread : �b 00> [14:00:38.054,229] nk_net_conn: ======================================= 00> [14:00:38.054,229] nk_net_conn: [DNS] Attempt=1 00> [14:00:38.054,534] nk_net_conn: [DNS] Duration=0 ms 00> [14:00:38.054,565] nk_net_conn: [DNS] FAILED 00> [14:00:38.054,565] nk_net_conn: [DNS] getaddrinfo err=-11 00> [14:00:38.054,595] nk_net_conn: [DNS] errno=2 (No such file or directory) 00> [14:00:38.062,591] nk_net_conn: [DNS] RSSI=-47 00> [14:00:38.062,591] nk_net_conn: [DNS] WiFi Connected=1 00> [14:00:38.062,591] nk_net_conn: [DNS] Retry remaining=2 00> [14:00:38.065,765] wifi_mgr: DHCP IP: 192.168.201.11 00> [14:00:38.065,765] wifi_mgr: WiFi ready start server connect 00> [14:00:38.065,765] NK_Timer: WiFi monitor timer stopped 00> [14:00:38.065,795] nk_net_mgr: NET Manager start 00> [14:00:38.065,795] nk_ws: WS stopped 00> [14:00:38.065,795] NK_Timer: WS RX Timer periodic timer stopped 00> [14:00:38.065,795] NK_Timer: WS Ping periodic timer stopped 00> [14:00:40.062,652] nk_net_conn: [DNS] Attempt=2 00> [14:00:40.145,324] nk_net_conn: [DNS] Duration=83 ms 00> [14:00:40.145,355] nk_net_conn: [DNS] SUCCESS 00> [14:00:40.145,385] nk_net_conn: [DNS] Server IP=34.193.34.228 00> [14:00:40.150,115] nk_net_conn: [DNS] RSSI=-50 00> [14:00:40.150,146] nk_net_conn: ========== DNS RESOLVE SUCCESS ========== 00> [14:00:40.150,268] nk_net_mgr: STATE: TLS 00> [14:00:40.150,299] NK_Timer: Watchdog not Feed 00> [14:00:40.150,329] nk_net_mgr: STATE: CONNECT 00> [14:00:41.586,456] nk_net_conn: Server connected (TLS) 00> [14:00:41.586,853] nk_net_mgr: SERVER CONNECTED 00> [14:00:41.586,883] nk_net_conn: CLOUD BOOTSTRAP START 00> [14:00:42.319,732] NK_CLOUD_LOGIN: Login success token stored 00> [14:00:42.823,028] rtc_pcf85263: RTC time set successfully 00> [14:00:42.823,028] NK_CLOUD_OBJECTTIME: RTC synced from cloud 00> [14:00:42.823,211] NK_CLOUD_HUBSTATUS: ====== Calling HUBSTATUS API ====== 00> [14:00:42.823,242] NK_CLOUD_HUBSTATUS: build_hub_status_json START 00> [14:00:42.824,157] rtc_pcf85263: RTC time read successfully 00> [14:00:42.824,279] NK_CLOUD_HUBSTATUS: sensorTime=2026-05-23T02:15:18.000Z 00> [14:00:42.834,411] NK_CLOUD_HUBSTATUS: build_hub_status_json END 00> [14:00:42.834,564] NK_CLOUD_HUBSTATUS: hub_status_payload : {"APINumber":2,"hubObjectId":"zstoCY93XJ","statusData":{"hub":{"hubObjectId":"zstoCY93XJ","hubId":"55003","description":""},"software":{"app":{"versionName":"0RNT99-EB_3630_PROD-1.0.0.8-beta"}},"hardware":{"device":"Controller B (WT02C40C)","uuid":"0641304100000000460039001851343438333231","rtc":1779502518},"network":{"type":"WIFI","details":{"ip":"192.168.201.11","public_ip":"34.193.34.228","ssid":"Nextkey","mac":"00:18:07:01:59:4C","rssi":-51}},"keypad":{"voltage_mV":0,"battery_percent":0,"temperature_C":0},"locks":[{"bleAddress":"FA:B2:AA:24:23:9B","firmwareVersion":"EB.05.10","lockId":"55003","state":1,"sensorTime":"2026-05-23T02:15:18.000Z","sensor":1}]}} 00> [14:00:42.834,655] NK_CLOUD_HUBSTATUS: HubStatus request sent 00> [14:00:43.364,471] NK_CLOUD_HUBSTATUS: HubStatus API response received 00> [14:00:43.364,746] NK_CLOUD_HUBSTATUS: HubStatus API response received 00> [14:00:43.364,837] nk_net_conn: CLOUD BOOTSTRAP DONE 00> [14:00:43.364,837] nk_net_mgr: NET Manager stop 00> [14:00:43.370,056] nk_net_conn: Server disconnected 00> [14:00:43.370,056] nk_ws: WS start 00> [14:00:43.402,648] nk_ws: WS DNS OK (attempt 1) 00> [14:00:43.403,137] nk_ws: WS TCP connect: spawning thread (attempt 1/3) 00> [14:00:43.403,961] nk_ws: [WS-TC Thread] connect() started — TLS handshake will happen here 00> [14:00:44.862,335] nk_ws: [WS-TC Thread] connect() SUCCESS — TCP + TLS done 00> [14:00:44.862,365] nk_ws: WS TCP connected (attempt 1) — TCP + TLS complete! 00> [14:00:44.862,365] nk_ws: WS handshake attempt 1 00> [14:00:45.073,364] nk_ws: WS connected 00> [14:00:45.074,768] nk_ws: WS ping 00> [14:00:45.074,768] NK_Timer: WS Ping periodic timer started 00> [14:00:45.075,500] NK_Timer: WS Rx periodic timer started 00> [14:00:45.075,531] NK_Timer: HubStatus periodic timer started 00> [14:00:45.075,988] NK_Timer: Watchdog not Feed 00> [14:00:45.228,363] NK_Timer: Watchdog not Feed 00> [14:00:45.676,330] nk_ws: WS RX: {"op":"connected","clientId":"1a8a3c3a-557c-4a5a-9cf9-35fd63b0e807"} 00> [14:00:45.676,391] nk_ws: Subscribing Hub: zstoCY93XJ 00> [14:00:46.190,032] nk_ws: WS RX: {"op":"subscribed","clientId":"1a8a3c3a-557c-4a5a-9cf9-35fd63b0e807","requestId":3} 00> [14:00:46.190,063] nk_ws: WS subscribed OK 00> [14:00:46.326,080] NK_Timer: Watchdog not Feed I kept the device powered on since last Friday for long-term testing. During this period, the device disconnected from Wi-Fi 7 times, but the good thing is that it reconnected instantly each time. I have increased the stack size–related macros in the project configuration file. After this change, the TLS and WebSocket connect API stuck issue has not been observed so far during the weekend long-term testing. Updated project config file for your reference. ############################################ # Logging ############################################ CONFIG_LOG=y CONFIG_LOG_BACKEND_RTT=y CONFIG_USE_SEGGER_RTT=y CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=2048 CONFIG_LOG_MODE_DEFERRED=y CONFIG_LOG_MODE_IMMEDIATE=n CONFIG_CBPRINTF_FP_SUPPORT=n ############################################ # DK (LED / Button) ############################################ # CONFIG_DK_LIBRARY=y ############################################ # Hardware Drivers ############################################ CONFIG_I2C=y CONFIG_ADC=y CONFIG_FLASH=y CONFIG_FLASH_PAGE_LAYOUT=y CONFIG_NVS=y CONFIG_NVS_LOG_LEVEL_DBG=y CONFIG_NVS_LOG_LEVEL_INF=y ############################################ # Watchdog ############################################ CONFIG_WATCHDOG=y CONFIG_WDT_LOG_LEVEL_DBG=y CONFIG_WDT_DISABLE_AT_BOOT=n ############################################ # Bootloader / OTA (MCUBoot) ############################################ CONFIG_BOOTLOADER_MCUBOOT=y CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y # MCUBoot image manager API CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y CONFIG_IMG_ERASE_PROGRESSIVELY=y CONFIG_PM_SINGLE_IMAGE=n ############################################ # Wi-Fi ############################################ CONFIG_WIFI=y CONFIG_WIFI_NRF700X=y CONFIG_WPA_SUPP=y CONFIG_WIFI_CREDENTIALS=y CONFIG_WIFI_CREDENTIALS_STATIC=n CONFIG_WIFI_CREDENTIALS_BACKEND_SETTINGS=y CONFIG_WIFI_MGMT_EXT=y CONFIG_NET_CONNECTION_MANAGER=y CONFIG_L2_WIFI_CONNECTIVITY=y CONFIG_NRF700X_MAX_TX_AGGREGATION=4 ############################################ # Networking Stack ############################################ CONFIG_NETWORKING=y CONFIG_NET_NATIVE=y CONFIG_NET_SOCKETS=y CONFIG_NET_SOCKETS_POSIX_NAMES=y CONFIG_POSIX_MAX_FDS=16 CONFIG_NET_SOCKETS_POLL_MAX=6 CONFIG_NET_L2_ETHERNET=y CONFIG_NET_IPV4=y CONFIG_NET_IPV6=y CONFIG_NET_TCP=y CONFIG_NET_DHCPV4=y CONFIG_DNS_RESOLVER=y CONFIG_NET_CONFIG_NEED_IPV4=y ############################################ # TLS / Security ############################################ CONFIG_NET_SOCKETS_SOCKOPT_TLS=y CONFIG_TLS_CREDENTIALS=y CONFIG_NRF_SECURITY=y CONFIG_MBEDTLS=y CONFIG_MBEDTLS_TLS_LIBRARY=y CONFIG_MBEDTLS_ENABLE_HEAP=y CONFIG_MBEDTLS_HEAP_SIZE=81920 CONFIG_MBEDTLS_RSA_C=y CONFIG_MBEDTLS_DHM_C=y CONFIG_MBEDTLS_SSL_SERVER_NAME_INDICATION=y CONFIG_PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY=y CONFIG_PSA_WANT_RSA_KEY_SIZE_2048=y CONFIG_NET_SOCKETS_ENABLE_DTLS=n CONFIG_NET_SOCKETS_TLS_MAX_CONTEXTS=2 ############################################ # HTTP / WebSocket ############################################ CONFIG_HTTP_CLIENT=y CONFIG_WEBSOCKET_CLIENT=y ############################################ # JSON ############################################ CONFIG_CJSON_LIB=y ############################################ # C Library ############################################ CONFIG_NEWLIB_LIBC=y CONFIG_NEWLIB_LIBC_NANO=y CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y ############################################ # Memory / Stacks ############################################ CONFIG_MAIN_STACK_SIZE=8192 CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192 CONFIG_HEAP_MEM_POOL_SIZE=153600 CONFIG_NET_TCP_WORKQ_STACK_SIZE=2048 CONFIG_NET_TX_STACK_SIZE=4096 CONFIG_NET_RX_STACK_SIZE=4096 CONFIG_NET_BUF_RX_COUNT=36 CONFIG_NET_BUF_TX_COUNT=36 CONFIG_NET_BUF_DATA_SIZE=512 CONFIG_NET_TC_TX_COUNT=0 CONFIG_WIFI_INIT_PRIORITY=50 ############################################ # Flash / Settings ############################################ CONFIG_FLASH_MAP=y CONFIG_SETTINGS=y CONFIG_SETTINGS_NVS=y CONFIG_SETTINGS_NVS_SECTOR_COUNT=2 CONFIG_PM_PARTITION_SIZE_NVS_STORAGE=0x2000 CONFIG_MPU_ALLOW_FLASH_WRITE=y ############################################ # Bluetooth ############################################ CONFIG_BT=y CONFIG_BT_PERIPHERAL=y CONFIG_BT_GATT_CLIENT=y CONFIG_BT_SMP=n CONFIG_BT_DEVICE_NAME="NKEY eLatch" CONFIG_BT_USER_PHY_UPDATE=y CONFIG_BT_USER_DATA_LEN_UPDATE=y CONFIG_BT_PERIPHERAL_PREF_MIN_INT=15 CONFIG_BT_PERIPHERAL_PREF_MAX_INT=30 CONFIG_BT_PERIPHERAL_PREF_LATENCY=0 CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=3200 CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y # MTU / Data length CONFIG_BT_CTLR_DATA_LENGTH_MAX=251 CONFIG_BT_BUF_ACL_RX_SIZE=251 CONFIG_BT_BUF_ACL_TX_SIZE=251 CONFIG_BT_L2CAP_TX_MTU=251 # Device Information Service CONFIG_BT_DIS=y CONFIG_BT_DIS_PNP=n CONFIG_BT_DIS_MANUF="Nexkey" CONFIG_BT_DIS_FW_REV=y CONFIG_BT_DIS_FW_REV_STR="EB.05.10" My concern is whether this fix will resolve the issue completely ? Regards, Dipeshhttps://devzone.nordicsemi.com/f/nordic-q-a/128122/i-cannot-use-npm-2100-ek-with-cr2023/566811Mon, 25 May 2026 03:10:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:0bcd1777-38bc-4471-b2cd-42470c73dd57Luiz MirandaHi Szabolcs: Thank you very much for your honest and highly valuable technical feedback. Your calculations regarding the 13 mA current draw on the coin cell were spot on, and it made us completely rethink our power architecture to protect the project from voltage sag and brownout issues. Based on your recommendations, we have a plan to upgrade our power management strategy for the FRA Project: 1 We are migrating from the nPM2100 to the nPM1300 family to take advantage of its integrated Lithium battery charger, power path management, and advanced fuel gauge. 2 We are switching to a rechargeable Lithium chemistry (3.7V) to ensure a much lower ESR, allowing the passive piezo to trigger continuously without affecting the nRF54L15 rails. Since our mechanical enclosure constraint is tight (4.5 cm x 3.0 cm), we are currently evaluating two battery form factors and would highly appreciate your professional insight on them regarding their performance with the nPM1300: Please note that while our current baseline is 4.5 cm x 3.0 cm, we have some flexibility to slightly increase the PCB dimensions if required to optimize the antenna ground plane or to better accommodate the power management section." Option A: LIR2450 (Coin Cell): Compact circular footprint (24mm diameter), but requires a rigid PCB holder and offers around 120 mAh. Option B: Small Pouch Li-Po (e.g., 502030): Rectangular footprint (20mm x 30mm x 5mm), which aligns nicely with our PCB edges, allows a "sandwich" mounting on the back of the board, and doubles the capacity to around 250 mAh. Given that our target is to maintain a constant BLE connection to a Mobile APP with a target standby autonomy of 15 to 30 days, we have two quick questions: 1 BLE Parameters: To achieve our 15-30 days battery target while maintaining a continuous connection, what baseline values would you recommend for the Connection Interval and Peripheral Latency within the Zephyr RTOS? (A slight delay in mobile app command responsiveness is perfectly acceptable for this product). 2 Discrete H-Bridge: We plan to drive the passive piezo at 4.5 kHz using the nRF54L15 PWM. To achieve the 80 dB target at a regulated 3.3V, we are planning a discrete, low-cost H-Bridge circuit using two 2N7000 (N-Channel) and two BS250 (P-Channel) MOSFETs. Does this discrete topology look safe and appropriate to be driven directly by the nRF54 GPIOs? Best regards, Luiz Mirandahttps://devzone.nordicsemi.com/f/nordic-q-a/128131/npm1300-query-on-rshphld/566810Mon, 25 May 2026 02:24:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:52476554-d29b-490a-8bc8-6d717f0328b5Nic-SGHi Mathias, Have not received any further query from cusotmer. So will close this case for the time being. Thanks so much and wishing you a great week ahead! Best Regards, Nichttps://devzone.nordicsemi.com/f/nordic-q-a/128216/zephyr-driver-regarding-the-execution-speed-of-flash-read-api-at-nrf54l15/566809Sun, 24 May 2026 23:37:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:845206b1-b975-4388-8316-21209acdaf69H-ogawaHi,Vidar Thank you for your response. Since it has been resolved, I will close this issue. Best regards, Hirokihttps://devzone.nordicsemi.com/f/nordic-q-a/128228/nrf54l15-ble-advertising-not-seen-in-mobile-appsSun, 24 May 2026 21:39:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:75e81594-2460-4c82-95c0-909e7346ab22jLYV3rHey there! I am facing a very frustrating issue, where my nRF54L15 (custom board) BLE peripheral just won't appear in mobile apps. For example, right now I am trying to set up the MCUmgr via BLE and I have everything configured but neither iOS nor Android will show the device, be it with the nRF Connect or the Device Manager apps. Also other thirdparty BLE dev apps don't work. When scanning with the nRF BLE Sniffer on a Mac, the peripheral instantly shows up perfectly fine. The package seems to be structured right and at this point I don't know what else to do... I know that it can't be the hardware itself because (1) Sniffing shows valid packets going through the air, and (2) in an earlier stage, I was able to see ADVs perfectly fine with the exact same hardware, sadly I can't restore that exact code. Below is the advertising packet in code and after that the raw bytes captured by Wireshark using the BLE sniffer. struct bt_le_adv_param param = BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_CONN, BT_GAP_ADV_FAST_INT_MIN_2, BT_GAP_ADV_FAST_INT_MAX_2, NULL); static const struct bt_data ad[] = { BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)), BT_DATA_BYTES(BT_DATA_UUID128_ALL, SMP_BT_SVC_UUID_VAL), }; static const struct bt_data sd[] = { BT_DATA(BT_DATA_NAME_COMPLETE, CONFIG_BT_DEVICE_NAME, sizeof(CONFIG_BT_DEVICE_NAME) - 1), }; The LE link layer bytes. 0000 d6 be 89 8e 40 1b 2c a4 7c 6c 79 e1 02 01 06 11 ....@.,.|ly..... 0010 07 84 aa 60 74 52 8a 8b 86 d3 4c b7 1d 1d dc 53 ...`tR....L....S 0020 8d 11 d2 67 ...g Is anyone facing a similar experience?developmentFailure AnalysisdebuggingnRF54L15bluetooth leDisappointmenthttps://devzone.nordicsemi.com/f/nordic-q-a/103007/unknown-device/566808Sun, 24 May 2026 14:51:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e6ca7490-94d6-4a9b-abfc-eff4fdab134fzidongchnVery informative article! I've been facing similar issues with my custom board and this helped me understand the problem better. For more detailed insights, check out scritchy scratchy .https://devzone.nordicsemi.com/f/nordic-q-a/128227/nb-iot-sim-options-for-nrf9160-in-indiaSun, 24 May 2026 12:55:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8a03bca3-32e2-4e3d-8f62-b97b7fa4a581purush123Hi all, I'm deploying an nRF9160-based device in India and hitting the familiar "which SIM actually works here" wall. Looking for current (2026) experiences, since older threads are out of date and the operator landscape keeps shifting. What I've tried: - Airtel M2M NB-IoT SIM — provisioned fine, but NB-IoT coverage at my location( Bangalore ) was poor and unreliable. Device couldn't get a stable attach. Where I'm stuck — questions: 1. For anyone running nRF9160 in India in 2025–2026: which operator's NB-IoT are you actually getting a reliable attach and data on? Jio keeps coming up as the main NB-IoT operator — can anyone confirm current nRF9160 experience? 2. Jio NB-IoT is reportedly Non-IP (data tunneled via their server rather than standard IP sockets). For those using it — how are you handling this on the nRF9160 side? NIDD, or is there an IP APN available now? 3. Has anyone sourced a small-quantity NB-IoT SIM (R&D, under 10 SIMs) without the 100-SIM enterprise minimum? Any band-lock (%XBANDLOCK) or APN config that made the difference would be a huge help. Thanks!nRF9160auto_nrf9160configurationauto_configurationproductionauto_cellular_iothttps://devzone.nordicsemi.com/f/nordic-q-a/128226/options-for-flashing-nrf9151-with-production-firmware-without-j-linkSun, 24 May 2026 11:27:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:ca3f2c90-d759-47ee-bd14-1dfcbe23bf25Joe01Hi all, I've built a custom nRF9151 board, which is successfully responding to the basic factory AT commands. It won't accept a CFUN=1 command though, presumably because it's still loaded with the factory firmware. I've only got access to a PicoProbe at the moment, which has worked great for flashing application programs over SWD, but I'm now trying to change the modem firmware to the production version and I can't find any way to do this without MCUBoot or a J-Link adapter. Do I have any options other than buying a J-Link Edu Mini? Thanks!developmentsoftwareauto_mcubootauto_nrf9151nRF9151auto_softwareauto_configurationauto_cellular_iot