https://devzone.nordicsemi.com/f/nordic-q-a/128775/nrf52832-ncs-2-5-1-hfxo-stuck-on-100-of-time-with-no-zephyr-bt-hfclk-requester---mpsl-bug/572812Mon, 02 Nov 2026 22:48:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2effa4ae-a313-4f86-b096-49beeeecae57Geoff HunterHi Simonr , Thanks for that. I realise the SoftDevice is proprietary, but can you answer this one specific question? If the SDC starts an on-demand calibration (for whatever reason, e.g. Bluetooth activity), and mpsl_calibration_timer_handle() then fires while that calibration is still running, does the timer path start a second calibration without checking whether one is already in progress? And would that leave an extra HFXO reference held, so HFXO stays on until reset? If so, is a guard on the timer path something the MPSL team would fix? Our DK repro (MPSL only, no Bluetooth) shows that two overlapping starts leave HFXO on regardless of the accuracy setting. So unless the SDC never requests a calibration at 500 ppm, it looks like 500 ppm would make it rarer rather than impossible. Regards, Geoffhttps://devzone.nordicsemi.com/f/nordic-q-a/129538/nrf93m1-dk-evaluation-in-usa/572811Mon, 02 Nov 2026 19:50:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:9b2bb259-04fd-4895-b5fb-f4c2e8e2d5b7robbsabolovicHi Ethan, I am the district sales manager for New England. I will reach out to you directly. Best regards, Robbhttps://devzone.nordicsemi.com/f/nordic-q-a/129538/nrf93m1-dk-evaluation-in-usa/572810Mon, 02 Nov 2026 19:28:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:6d252c10-67a6-41ea-b958-284e1830aa37Amanda HsiehHi Ethan, That's correct. Please request an early LACA-based DK via the contact form or your regional sales manager. Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/129529/nrf9151-band-71-support/572809Mon, 02 Nov 2026 18:39:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d66c44a2-6f76-4f45-abcc-628dcb096547JonsiannHi Syed - Band 71 matters for healthcare IoT because reliable indoor coverage matters far more than data rate. T-Mobile’s 600 MHz spectrum improves building penetration and extends rural coverage, both relevant to hospitals and clinics. Devices often sit deep inside buildings, in pharmacies, storage rooms and equipment areas. Omitting B71 removes a useful coverage option.https://devzone.nordicsemi.com/f/nordic-q-a/128938/sysbuild-with-encryption-fails-as-soon-as-sb_config_boot_encryption_alg_aes_256-y-is-set/572808Mon, 02 Nov 2026 18:29:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:6698d088-2280-42f5-a76c-04a95c614165Vidar BergUpdate: a PR which should address this issue was submitted today here: https://github.com/nrfconnect/sdk-nrf/pull/32396https://devzone.nordicsemi.com/f/nordic-q-a/129538/nrf93m1-dk-evaluation-in-usaMon, 02 Nov 2026 17:45:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:89297173-a82a-4cf6-95b2-6e3c8ca4cb99piethanHello, I recently bought the nRF93M1-DK from Mouser for evaluation in the USA. I was trying to get either the included SIM or a separate known good IOT SIM I already have to work, and had trouble getting a cellular link. It turns out I have a LABA variant and I think I need the LACA version for the bands here in New Hampshire, USA. Is this true and where can I get my hands on a DK with this LACA variant? Thanks, EthannRF93M1lte-mnb-iotEvaluationhardwarehttps://devzone.nordicsemi.com/f/nordic-q-a/129535/npm1300-resets-with-vsyslow-when-enabling-external-boost-converters-at-vbat-3-1-3-2-v/572807Mon, 02 Nov 2026 17:13:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e88d8c8f-5ed9-42d0-bb43-582bffce268eAmanda HsiehHi, No. In the nPM1300, the VSYS comparator (VSYSPOF) is an always-active hardware protection feature. It cannot be disabled nor controlled to a lower value than its lowest 2.6V value because of the PMIC architecture. Just thinking about your application loads and LiPo battery limits, for a standard LiPo cell an unloaded/lightly-loaded voltage of 3.1–3.2 V is already past the discharge knee and corresponds to roughly 0 to 1% remaining State of Charge (SOC). At this stage, there is almost no usable energy left, and the cell’s internal impedance increases sharply, meaning any high-current surge from enabling boost converters will anyway naturally cause a steep voltage collapse. Even if you manage to extract the last bit of juice, it puts a lot more stress on the battery (aging) when you try to operate around that region with those high currents. Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/129531/nrf54lm20a-ncs-v3-4-0-esb-only-in-the-rest-of-each-20-ms-period-esb_init-esb_disable-or-timeslot/572806Mon, 02 Nov 2026 16:00:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:1e8b61ba-a333-4398-87e2-3ff89ca3071cProject NICThank you, Kenneth. That is clear, and option 1 is what we have written now. One thing we hit when building it. With your Kconfig on the Belka (CONFIG_MPSL_FEM_ONLY=y, ESB with dynamic interrupts) and MCUmgr's OS group enabled (CONFIG_MCUMGR_GRP_OS=y), NCS v3.4.0 does not link for nrf54lm20dk/nrf54lm20a/cpuapp: undefined reference to `mpsl_low_latency_acquire_callback' undefined reference to `mpsl_low_latency_release_callback' The map shows libmpsl.a pulled in by nrf/subsys/mgmt/mcumgr/grp/os_mgmt/src/os_mgmt_reboot_bt.c (mpsl_uninit). MCUMGR_GRP_OS_REBOOT_BT has no prompt and is on by default with depends on (BT || MPSL), and ESB selects MPSL even with MPSL_FEM_ONLY, while the two callbacks are defined in subsys/mpsl/init/mpsl_init.c, which FEM-only leaves out. The same condition is in v3.4.1 and v3.5.0-preview4. We patched the Kconfig locally to depends on (BT || (MPSL && !MPSL_FEM_ONLY)) and both images build. Is that the right fix, or is there a supported way to use MCUmgr's OS group with MPSL_FEM_ONLY? With FEM-only, MPSL is never initialised, so we assume nothing needs mpsl_uninit() before a reset. Thank you, Pavelhttps://devzone.nordicsemi.com/f/nordic-q-a/129509/nsib-upgradable-mcuboot-how-can-an-smp-client-read-the-running-mcuboot-version/572805Mon, 02 Nov 2026 15:35:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:0d771e5d-7f2e-4ec2-a099-f51cc56d4f44ddiasswordThanks Simon, that makes sense. We understand the signed_by_b0_* files are enough to boot, because only the NSIB signature is checked once a copy is in place. We'd still like to program signed_by_mcuboot_and_b0_mcuboot.hex and signed_by_mcuboot_and_b0_mcuboot_s1_variant.hex directly, with both west flash and our production programmer. That way, both copies have the MCUboot header and TLVs from the first boot, so our app can report the header version, image hash and signing key hash of each copy over SMP. Otherwise, that information is only available for a copy once it has been installed by an update, so a device that never gets an MCUboot update couldn't report it for the copy it's running. Is it OK to flash these files this way, including in production? Apart from the extra bytes, is there any downside or risk we should know about?https://devzone.nordicsemi.com/f/nordic-q-a/129494/repurposing-i2c-pins-without-device-pm/572804Mon, 02 Nov 2026 15:32:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:73e7904f-0045-4e61-8768-17f224cc3cd0Simon D-MHi, Sorry for the delay. One of my colleagues suggested a solution that would most likely work fine. It is not going to make your LP5814 driver a generic zephyr driver but at least it would be somewhat clean. His solution is to use the new exclusive access API you mentioned in your initial message ( link ) and using the nrfx_twim API directly, following a similar approach to the one used by i2c_nrfx_twim_recover_bus() . It would look something like this: static int lp5814_wakeup(void) { .... ret = i2c_nrfx_twim_exclusive_access_acquire(dev, K_SECONDS(1)); /* wait for exclusive access or time out */ if (ret) { return err }; nrfx_twim_disable(cfg->twim); /* releases the pins to GPIO */ // TODO: bit bang wake up sequence. Do not use any i2c APIs here pinctrl_apply_state(cfg->pcfg, PINCTRL_STATE_DEFAULT); /* restore pin configuration */ nrfx_twim_enable(cfg->twim); i2c_nrfx_twim_exclusive_access_release(dev); .... } I hope this helps a bit. If you have any question on this solution, feel free to ask. Best regards, Simonhttps://devzone.nordicsemi.com/f/nordic-q-a/129526/nrf52840-twis-hangs-after-write_req-with-config_uart_async_api-enabled-constlat-prevents-failure/572803Mon, 02 Nov 2026 15:20:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:9e57960e-9456-4645-b561-e2ea9a0d0fd9Pallavi PatilHi, I will look into this and have a detailed answer by tomorrow. thanks for your patience. Regards Pallavihttps://devzone.nordicsemi.com/f/nordic-q-a/129409/vid-pid-for-a-commercial-nrf52840-usb-cdc-acm-product---can-we-use-0x1915-and-what-about-the-open-bootloader-s-0x521f/572802Mon, 02 Nov 2026 15:15:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2bac268c-986f-448e-aec0-8b355b87785bAmanda HsiehSee my colleague's explanation in this post . If you go to production, I suggest obtaining your own Vendor ID (see this post ).https://devzone.nordicsemi.com/f/nordic-q-a/129509/nsib-upgradable-mcuboot-how-can-an-smp-client-read-the-running-mcuboot-version/572801Mon, 02 Nov 2026 14:40:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e02b0c2c-dcde-4b81-af76-c9a70f60fc3fSimon D-MHi, Sorry for the delay, I asked internally and I now a clearer idea of why this happens. So this is actually a cleaner way of doing it. The thing is that the MCUBoot signature is only used when MCUBoot is transferring the new MCUBoot image from slot1 to s1 or s0. Once the bootloader firmware is in the right place, MCUBoot signature is not checked anymore, only the NSIB one is checked. This means that it is actually a bit cleaner to do it like this as no unused bytes are transferred when writing the program for the first time as this is written directly to s0 and s1. So this is not a bug and is normal. If you flash directly to the device, then using signed_by_b0_mcuboot(_s1_variant).bin is cleaner but if you perform an update then the signed_by_mcuboot_and_b0_mcuboot(_s1_variant).bin has to be used. If you need more precision feel free to ask. Best regards, Simonhttps://devzone.nordicsemi.com/f/nordic-q-a/129504/54l15-mesh-packet-loss/572800Mon, 02 Nov 2026 14:35:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:aa7ecdc9-4ecd-4383-bfab-49eec0be14b5EdvinWhat kind of HW are you testing this on? Are you using DKs, or custom PCBs? If it is a custom PCB, did you submit your design for a review? Best regards, Edvinhttps://devzone.nordicsemi.com/f/nordic-q-a/129307/nrf-academy-intermediate-course---lesson-1-exercise-1-issue-with-debugging/572799Mon, 02 Nov 2026 14:34:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:0fa73e97-daa4-4f2d-be50-82b31be3ff97EdvinHello, This is to be expected. If the debugger is to know the state of anything, it needs to halt the application, which is why you see it when you stop the application. Best regards, Edvinhttps://devzone.nordicsemi.com/f/nordic-q-a/129456/nrf-7002-current-draw/572798Mon, 02 Nov 2026 14:27:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d2ffdbfe-7cd4-4b99-aeed-69f3d308a712KennethHi Samuel, A few thoughts. A 10- 15% spread across units under same conditions is typical for process variations and RF power amplifiers. If you factor in temperature range and supply voltage variations, I expect the spread can even be higher. Other reasons why your measurements might be 12-13% higher than the Online Power Profiler: "Peak" vs. average TX burst: The datasheet and profiler numbers represent the average current across the active TX sequence, not the instantaneous peak. If your measurement tool is logging the absolute "max" spike, it's likely catching DC-DC switching ripple or brief ramp-up transients rather than the actual TX level. Voltage drop (IR drop) at the chip: At 100+ mA, test wires and contacts can cause voltage drop. Because the nRF7002 uses internal DC-DC converters, if the voltage sags at the chip input, it has to draw more current. It's worth scoping the supply rail directly at the nRF7002 VDD/VBAT pin during transmission to check if the voltage is dipping. Test lead inductance: Fast current steps through longer jumper leads introduce inductive overshoot, which measurement tools can misinterpret as higher peak current. The devicetree property wifi-max-tx-pwr-2g-mcs0 = ; only sets the software ceiling limit. The Wi-Fi firmware and internal factory calibration will clamp the actual output power to the hardware limit (15 dBm typical for QFN MCS0). Best regards, Kennethhttps://devzone.nordicsemi.com/f/nordic-q-a/129532/feasibility-study-of-google-find-hub-support-on-the-nrf5340-for-bluetooth-device-tracking/572797Mon, 02 Nov 2026 14:03:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a60bf92d-e941-428e-ab73-f60d2cc8c518Pallavi PatilHi Asha, The nRF5340 is not supported for the Google Find Hub / Fast Pair Locator Tag use case in the current nRF Connect SDK. There is currently no SDK sample or supported software stack for the Locator Tag use case onnRF534. The only supported Soc is nRF54L and you can find the sample here . Regards Pallavihttps://devzone.nordicsemi.com/f/nordic-q-a/129531/nrf54lm20a-ncs-v3-4-0-esb-only-in-the-rest-of-each-20-ms-period-esb_init-esb_disable-or-timeslot/572796Mon, 02 Nov 2026 14:02:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:43b06ae1-0b5c-4611-84e4-fd0f19585259KennethHi, I'd recommend option 1: call esb_init() / esb_disable() every period. You keep full control of the timing and don't depend on an experimental feature. Kconfig: CONFIG_ESB=y CONFIG_ESB_DYNAMIC_INTERRUPTS=y CONFIG_DYNAMIC_INTERRUPTS=y CONFIG_DYNAMIC_DIRECT_INTERRUPTS=y CONFIG_MPSL_FEM_ONLY=y # CONFIG_ESB_CLOCK_INIT is not set Dynamic interrupts let you swap in your own RADIO ISR between esb_disable() and esb_init(). With MPSL_FEM_ONLY set, MPSL is never initialized and doesn't reserve RADIO or TIMER10. Keep ESB_CLOCK_INIT off and hold HFXO on yourself for the whole period. Otherwise every esb_disable() stops HFXO and you pay the startup time again on the next init. What to take care of: Peripherals: TIMER10: ESB uses it and reprograms it for every transaction. Run your 20 ms period from GRTC or a TIMER2x (via PPIB) instead. You can use TIMER10 for your own frame after esb_disable(). DPPIC10 channels and EGU10 channels 6–8: ESB allocates its DPPI channels with nrfx_gppi in esb_init() and frees them in esb_disable(). Allocate yours through nrfx_gppi too so they don't collide. Hand-over: before esb_init(), leave RADIO clean: SHORTS, INTEN and your PUBLISH/SUBSCRIBE settings cleared. Re-init side effects: esb_init() resets several things every period: Addresses: reset to the ESB defaults. Call esb_set_base_address_0/1(), esb_set_prefixes(), esb_set_rf_channel() and esb_set_tx_power() again. FIFOs: flushed. Re-queue any pending TX and ACK payloads. Duplicate detection (PID): reset. Use a sequence number at the application level if duplicates matter. Stopping in time: ESB has no "stop at time T", and esb_disable() aborts a packet in flight. A 252-byte packet at 2 Mbit/s is about 1.05 ms on air, so plan on about 1.2 ms per TX+ACK attempt. Stop starting new TX about 1.3 ms before your cutoff. On the PRX, call esb_stop_rx() at the cutoff. That leaves room for about four attempts in your ~6 ms window. retransmit_delay must be longer than one TX+ACK. Timing: there are no published numbers for esb_init() / esb_disable(). Without ESB_CLOCK_INIT they only write registers and allocate resources. Please measure them with a GPIO toggle. Option 2 (CONFIG_ESB_MPSL_TIMESLOT) only makes sense if you also run a protocol that depends on MPSL, such as Bluetooth LE or 802.15.4. In that case, yes, your own frame would also have to run in an MPSL timeslot session, since MPSL then owns RADIO and TIMER10. Without such a protocol it only adds scheduling overhead and latency to ESB. Best regards, Kennethhttps://devzone.nordicsemi.com/f/nordic-q-a/129536/chan_map/572795Mon, 02 Nov 2026 13:52:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a522091a-a8ed-4acb-a13e-979f56b9c507SigurdDuplicate of beeehttps://devzone.nordicsemi.com/f/nordic-q-a/129537/beee/572794Mon, 02 Nov 2026 13:51:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a3d227bf-6f59-4e0e-86a6-aeca4c042debSigurdYes, it's available for the BLE central role.