https://devzone.nordicsemi.com/f/nordic-q-a/129258/problems-using-modem_cellular-driver-with-the-modem_backend_uart_isr-option-in-ncs-3-4-0/571509Wed, 23 Sep 2026 23:00:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c750b2f1-95d2-4f89-b5b0-c1a05e2903a6Nathan BoydHi Vidar, We aren't currently using CONFIG_UART_NRFX_UARTE_HFXO_ON_ACTIVE, but we have previously confirmed that we always have the HFXO running when we need this UART. We have tested with the separate TIMER/COUNTER specified to handle the RX timeout, and this works in terms of not ending up with the RX disabled randomly, but the CPU load seems so high when running at 921600bps that the CMUX driver is dropping bytes. I am not sure if this is dropping at the modem backend level, or at the CMUX driver (on ncs-3.3.0 with earlier modem code we had a lot of trouble tuning all the buffer sizes through the modem and network stack to make sure that we were not dropping data there. Our application is rather simple from a power management point of view, as we spend most of our time idle, but using PM_DEVICE_RUNTIME simplifies a few of our use cases, so we do rely on the UART being suspended when not in use. We will try the CONFIG_UART_NRFX_UARTE_HFXO_ON_ACTIVE to see if there is a chance it is related to clock precision, as I did suspect in an earlier ticket (case ID 344534) relating to async UART problems that frame errors were detected, leading to the RX being aborted. Regards, Nathan.https://devzone.nordicsemi.com/f/nordic-q-a/129262/vscode-extension---slow-to-trigger-buildWed, 23 Sep 2026 22:48:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:162b6bb8-cb14-465f-98a4-07db2b782ddfcrzyrndmRecently the VSCode extension has seemed to become extremely slow / unresponsive when triggering a build Judging by the vscode popup on every build telling me there's an SDK update it's clearly triggering a lot more than just west build Whatever these checks are (there's clearly more than just the SDK version), can this please be changed to be something periodic (daily / weekly). A 5-10s lag on every build is crippling PS On the topic of VSCode extension issues - when a build is started (and after the ^^ delay) it blanks the source tree and actions windows. I understand the actions (would be better if they were just disabled but...) but the source browser is still very useful while a build is ongoing, especially if there was only source level changesdevelopmentsoftwarenRF Connect SDKhttps://devzone.nordicsemi.com/f/nordic-q-a/129222/thingy-91-x-pca20065---nrf5340-1-8-v-por-margin-and-npm1300-c00-errata/571508Wed, 23 Sep 2026 20:48:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:fb2d1c82-9ac8-40ba-9f71-0fbdc55676b6Jeff3813Hi Ketil, Thanks again for your reply. Before changing the power architecture, I’d like to clarify three points for our PCA20065-based redesign. We need to move from nRF5340 CMAA to QKAA for sourcing reasons, while retaining the existing functionality. 1. Original 1.8 V supply BUCK1's published ±5% tolerance allows 1.710 V before FB3, SW1 and U3, while the nRF5340 requires 1.75 V at power-on. Is the successful Thingy:91 X experience supported by startup/low-load characterization, or by a tighter guaranteed limit we could use for a new design? Would that also apply to QKAA with its reference decoupling, and only during startup or also during normal operation? 2. QKAA high-voltage mode Could powering VDDH from an existing higher rail and using VREGH at 1.8 V be a supported minimal change, keeping the other devices on the existing ~1.8 V domain? Which GPIO/debug limits and sequencing restrictions would apply when these two domains power up or down independently? If the original path cannot be justified for a new design, would Nordic recommend this arrangement, another existing-rail solution, or a separate MCU supply? 3. nPM1300 revision and procurement From PCN213, I understand that Revision 2 is D00, marked QEAAD0 on the device, while the order codes remain nPM1300-QEAA-R and -R7. Is there an official way to specify and verify D00 through an authorized distributor, particularly for cut tape? PCN246 also announces E10 alongside D00. Which Product Specification, errata and reference-design documentation apply to E10? Does it retain the PCN213 functional changes, and do the remaining D00 errata still apply? Best regards, Geoffreyhttps://devzone.nordicsemi.com/f/nordic-q-a/129249/mcuboot-serial-recovery-application-boot-request-is-never-cleared-so-the-device-re-enters-recovery-after-every-reset-ncs-v3-4-1/571507Wed, 23 Sep 2026 19:37:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:38a69c23-8ca0-4263-b7d6-ff151eef1fcdAmanda HsiehHi, I am checking with the team and will update you once I have gathered enough information. Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/129253/ble-receiver-shutting-down-periodically/571506Wed, 23 Sep 2026 18:29:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e546bedb-377e-44c0-b24e-feb9d9f0cebflgsealWe figured it out. Samsung phones (mine at least) use an egregiously long delay between the chunks of extended advertisements. The NCS softdevice can only "follow" 1 at a time.https://devzone.nordicsemi.com/f/nordic-q-a/129245/nrf-mesh-app-can-send-generic-onpowerup-set-message/571505Wed, 23 Sep 2026 17:36:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:25c1a904-4d30-4a6e-800a-dc8e6200486fAmanda Hsieh[quote user="James168"]Can I use nRF Mesh APP to change this value?[/quote] You can set "Restore" to the last known Light level in the Control under the Generic Power OnOff Setup Server on Element1 via the nRF Mesh APP on iOS after binding the application key.https://devzone.nordicsemi.com/f/nordic-q-a/129237/is-there-an-example-for-using-the-cortex-m33-mpu-with-nrf-connect-sdk-bare-metal/571504Wed, 23 Sep 2026 17:12:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:50c482a9-ed69-49b4-b136-651cd7db32c2Julio CabreraThank you for the clarification. I checked the linked S145 documentation and the referenced SoftDevice Controller and MPSL integration notes. For the nRF54L Series, I can see several reserved peripherals and channels, but I cannot find the Cortex-M33 MPU in those lists. We are developing software for a Class C medical device and need segregation between software components. In particular, we must treat the S145 SoftDevice as Software of Unknown Provenance (SOUP), so we are evaluating whether the MPU can isolate safety-related code and data and prevent unintended memory access by the SoftDevice. Could you please point me to the specific documentation stating that S145 reserves access to the MPU, or clarify whether you meant another peripheral? Thank you. 2.16.1.2https://devzone.nordicsemi.com/f/nordic-q-a/128304/ant-scan-can-t-found-any-device/571503Wed, 23 Sep 2026 15:47:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a3a3aeb7-eee3-4731-b799-a390ca8c2af0sr-ant-wirelessnanty Hello, were you able to move to this release and resolve your issues?https://devzone.nordicsemi.com/f/nordic-q-a/129222/thingy-91-x-pca20065---nrf5340-1-8-v-por-margin-and-npm1300-c00-errata/571502Wed, 23 Sep 2026 15:34:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a5116000-98c2-411a-ace5-46f3b1d4b4daketiljoHi Geoffrey [quote user=""]I understand that simply combining static worst-case limits does not necessarily describe the voltage actually seen during startup: the load, sequencing and PMIC operating mode matter. I am not assuming that PCA20065 has a startup problem; I would just like to understand the intended margin before reusing this power path.[/quote] This is a tricky one. You have to balance the regulator accuracy with the min and max voltages for all devices on the same net. We haven't seen any issued in the Thingy 91x regarding this, but that doesn't mean that it's always good. The Vdd,min = 1.75 V applies at power on. Current draw is low so there are little voltage drop over the switch. When the device is out of POR, the brown out limit takes over and resets the device if VDD is below this, configurable. https://docs.nordicsemi.com/r/bundle/ps_nrf5340/page/regulators.html If you set the buck output voltage 1.9 V, you're at the BMM250 max limit by a hair, 1.9 v +5% = 1.95 V. So keep it at 1.8 V [quote user=""] b) Is there a specific startup sequence, load-switch state or BUCK mode in PCA20065 that should be preserved when reusing this path?[/quote] The nRF5340 won't be able to control any regulator or switch before it's out of POR, so you get some sequencing there. The VSET pins on the nPM1300 are used to set the initial startup voltage. Else, the rest should be ok. [quote user=""] 2. nPM1300 revision / errata The PCA20065 BOM identifies U11 as nPM1300-QEAAC0. I noticed that nPM1300 Revision 1 errata items 30 and 34 concern BUCK output-voltage behavior on C00 builds under specific conditions, while those anomalies are not listed for the later D00 revision. Are errata 30/34 relevant to BUCK1 in the PCA20065 implementation? For a new design based on it, should a D00 nPM1300 build be preferred, or is there a particular configuration/workaround from the original design that should be kept? [/quote] Both these are relevant so make sure you use the latest revision. [quote user=""] 3. BUCK1 output capacitor C52 The original BOM identifies C52 as JMK105CBJ106MV-F (10 µF / 6.3 V / X5R / 0402), while the BOM description also contains an inconsistent 4.7 µF / X6S text. C94 is not populated. The nPM1300 BUCK documentation requires the output capacitor to meet the effective-capacitance and ESR limits after the relevant tolerance, temperature and DC-bias effects.[/quote] C52 = 10 µF but the description say 402 6.3VDC 4.7uF 20% X6S so this is clearly incorrect. In any case, it's well above the minimum requirement of 4 µF: The part number of the cap isn't important. The ferrite beads are important to filter noise that may affect the LTE low bands. Best regards, Ketil Aas-Johansenhttps://devzone.nordicsemi.com/f/nordic-q-a/129248/nrf93m1-dk-connecting-uart-directly-to-extrnal-mcu/571501Wed, 23 Sep 2026 15:27:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2fa2dcaa-81b9-4852-a96e-be51c16d67d8Stefano0Thanks, I am trying with some troubles. Ill continue this thread with a private ticket.https://devzone.nordicsemi.com/f/nordic-q-a/129194/nrf93m1-and-nrf-connect-sdk/571500Wed, 23 Sep 2026 15:26:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d9ccde7b-e3c6-421b-8ecb-646ddc2ad5bbStefano0I'm sorry, I cannot find the way to use it / configure VS code to use it. The documentation was not helpful.https://devzone.nordicsemi.com/f/nordic-q-a/129099/an-aborted-channel-sounding-procedure-leaves-1-ma-residual-current-until-reset-sdc-200-12506/571499Wed, 23 Sep 2026 15:01:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2743cd3d-812d-4eeb-8995-b5f4787e17edNicholas RobinsonThank you for your reply and sorry for the delayed response. I have taken over this issue now from our end. I don't have anything substantive to contribute yet, though. We are only seeing the problem intermittently, although all four beacons that I took near one of the reflectors immediately after inserting new batteries, walked away (ensuring I triggered the accelerometers) and then left for a week (isolated from any reflector) have now drained their batteries - almost exactly the 7.3 days predicted using the PPK2. I am working on a version of our initiator firmware that allows us to inject the accelerometer triggers using the dev kit buttons instead of the Holyiot beacon. I hope this will enable me to give you more specific/reproducible information.https://devzone.nordicsemi.com/f/nordic-q-a/129234/rohs-reach-and-doc/571498Wed, 23 Sep 2026 14:55:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:61542c5d-737a-4d09-bb66-8ee673b942a3Konstantin KoshmakThank you for clarifying it and sharing REACH and RoHs with it. This simplifies the document collection. Have a good day, Konstantinhttps://devzone.nordicsemi.com/f/nordic-q-a/129252/tf-m-build-tooling-fails-on-non-utf-8-host-locales-windows-zh-cn-gbk-unicodedecodeerror-in-tools-tfm_parse_manifest_list-py/571497Wed, 23 Sep 2026 14:43:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:6a5a752e-a999-477e-80ac-104cef6d6f66ElfvingHi, I'm looking into it, and will get back to you once I know more.https://devzone.nordicsemi.com/f/nordic-q-a/129234/rohs-reach-and-doc/571496Wed, 23 Sep 2026 14:38:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8c1375fc-d48b-4b69-ba54-94f431fdab17ketiljoThese are ICs (components) and can't have a DoC by themselves as you said. Only a product can have that, ie. the nPM1300- EK REACH/RoHs: https://docs.nordicsemi.com/r/bundle/eqr_npm1300/page/rep/pmic/npm1300_env_reports.html https://docs.nordicsemi.com/r/bundle/eqr_npm1304/page/rep/pmic/npm1304_env_reports.html For more information on the environmental reports, contact environment@nordicsemi.nohttps://devzone.nordicsemi.com/f/nordic-q-a/129261/unable-to-do-fota-since-nrf-cloud-migrated-to-memfaultWed, 23 Sep 2026 14:18:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c7cbb1fa-63c0-457b-9f76-3393ac2af08fRossJI am unable to perform a fota on an nrf9160 based device in the field since my nrfcloud account was updated to require the use of the new memfault based version. There was no issue with this on the old platform. Observing the log on the target device I see... [00:00:15.172,180] download_client: Setting up TLS credentials, tag 16842753 [00:00:15.172,302] download_client: Connecting to fw.nrfcloud.com [00:00:17.140,869] download_client: Downloading: firmwares/10624/ota-payloads/35689285308?expire=1790177456&token=OiiHgU5j7O4vTg [0] [00:00:17.140,899] nrf_cloud_fota: Downloading update [00:00:17.909,393] download_client: Error in recv(), errno 122 [00:00:17.909,393] fota_download: Download socket error. 2 retries left... [00:00:17.909,423] download_client: Reconnecting.. nRFcloud related config... # nRF Cloud CONFIG_NRF_CLOUD_MQTT=y CONFIG_NRF_CLOUD_FOTA=y CONFIG_NRF_CLOUD_AGPS=y CONFIG_NRF_CLOUD_ALERTS=y CONFIG_NRF_CLOUD_CLIENT_ID_SRC_IMEI=y CONFIG_NRF_CLOUD_CLIENT_ID_PREFIX="cxe-" CONFIG_NRF_CLOUD_LOG_LEVEL_INF=y # MQTT CONFIG_MQTT_KEEPALIVE=120 # Download Client CONFIG_DOWNLOAD_CLIENT=y CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_1024=y CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096 CONFIG_DOWNLOAD_CLIENT_BUF_SIZE=2300 CONFIG_DOWNLOAD_CLIENT_MAX_HOSTNAME_SIZE=128 This behavior is consistent. Error 122 (EMSGSIZE) appears to be related to insufficient buffer size. That's a problem for the hundreds of devices we have in the field if the FOTA can't be run without first changing the firmware! Our devices were built with SDK 2.3.0 (mfw 1.3.5). nRF cloud comm is via MQTT.softwarenRF9160productionhttps://devzone.nordicsemi.com/f/nordic-q-a/129250/tf-m-nrf9151-an-spu-event-latched-during-boot-is-escalated-to-a-silent-fatal-halt-when-the-spu-interrupt-is-enabled-in-nvic_interrupt_enable/571495Wed, 23 Sep 2026 14:15:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8d51a48c-d56e-46c8-b9de-0d02e022616dRogerLeeOne more reproduction from our side - this time a runtime variant of the same escalation, in case it helps the SDK team's analysis. Context: same board/firmware as the report (NCS 3.4.1, nrf9151dk/nrf9151/ns, TF-M with our local nvic_interrupt_enable() spu_clear_events() workaround applied). One unit ran normally for ~15 minutes, then went silent. From then on it stalled a few seconds into almost every boot (varying position: after the TF-M banner, or right after the shell prompt). Warm resets (pin/soft) did not help, and a full power cycle did not help either. An ERASEALL + full reflash restored normal operation immediately. Captured from the stalled state with a debugger: - the halt loop: PC in tfm_hal_system_halt (secure flash, 0x12692), reached from ns_fault_service_call_handler (nrf TF-M board common, ns_fault_service.c:147) - i.e. the system was halted through the NS fault service path; - a console dump of the triggering platform interrupt: Platform external interrupt (IRQn): 0x00000003 (SPU_IRQn) Exception came from non-secure FW in handler mode R0: 0x0005890c (= uart@a000 device object, __device_dts_ord_115) R3: 0x4000A000 (= UARTE2 peripheral base) LR: 0x0002ef37 (= _isr_wrapper, isr_wrapper.c:98) PC: 0x00050002 (= nrf_event_check, nrfx nrf_common.h:343) Platform Exception: SPU.PERIPHACCERR - a sampled stack frame: uarte_nrfx_isr_int (uart_nrfx_uarte.c:544) on uart@a000. So in our case the escalation also happens for events latched after the SPU interrupt is enabled (our local patch only discards events latched before nvic_interrupt_enable()), and this time the failing context is the NS-side UARTE2 ISR performing UARTE2 register access. Note that UARTE2 is our application's IPC UART, and it is also the UART used by MCUboot serial recovery in this build (chosen zephyr,uart-mcumgr). Two questions: 1. Should we treat the UARTE2 angle as a clue for the SDK team (e.g. any scenario where TF-M's peripheral attribution for UARTE2 changes after/during recovery use)? 2. Is there register state you would like us to capture on the next occurrence (e.g. SPU.PERIPHACCERR.ADDRESS or anything else)? We can also test a non-fatal variant of SPU_Handler (clear-and-continue) in our local build if that helps you evaluate the fix. The device has been running normally again since the ERASEALL + reflash, and we are monitoring for recurrence.https://devzone.nordicsemi.com/f/nordic-q-a/129251/nrf_modem_lib_shutdown-before-rebooting-into-mcuboot-serial-recovery-modem-reset-loop-event-and-securefault-inside-the-precompiled-modem-library-handle_modem_rpc_msg-on-the-next-application-boot/571494Wed, 23 Sep 2026 13:54:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:f1327ba3-0aa2-4825-9861-9c0c45f9f9e7RogerLeeHi Hakon, thanks for the follow-up - here are the results of the k_msleep(500) test, with modem trace capture attempted across the whole cycle. Setup used for every run below - nRF Connect SDK v3.4.1, modem firmware 2.0.4, nRF9151 DK (nrf9151dk/nrf9151/ns, sysbuild with MCUboot serial recovery). - Trace build: official nrf91-modem-trace-uart snippet applied to the application image only (-Dnrf9151_SNIPPET=...), trace level FULL (the Kconfig default). Trace captured over UART1 (second VCOM, 1 Mbaud) with a small local raw reader (pyserial) - the nrfutil trace on this machine could not finish its trace-database install. - Each run: enter recovery from the application (fmg dfu - see variants below) -> MCUboot serial recovery -> nrfutil mcu-manager serial image-upload -> serial reset -> next application boot. - The capture was started before the shutdown and left running past the next application boot, so each window covers a full cycle on the host side (see the caveat below about what the stream actually contains). Results - variant "shutdown + k_msleep(500)" (fmg dfu shutdown, 500 ms pause), **6 runs: 5 clean boots, 1 failed with the same fault** (details below). - variant "shutdown without pause" (fmg dfu shutdown 0, the original failing sequence), 3 valid runs: all boots clean. (One further run was aborted before the upload due to a host-tool timeout and is excluded.) - reference "modem left running" (default fmg dfu), 1 run: clean. Failure with the 500 ms pause in place (run "B6") - Same signature as our original report - non-secure SecureFault, handler mode, SFSR 0x48 (AUVIOL|SFARVALID), SFAR 0x0, R6 0: ``` *** Booting nRF Connect SDK v3.4.1-b20f8619ba9a *** Reset reason: software SecureFault Exception came from non-secure FW in handler mode. MSP_NS: 0x20033000 PSP_NS: 0x20033f88 R3: 0x00041f11 LR: 0x00041ef9 PC: 0x00041e94 R6: 0x00000000 SFSR: 0x00000048 SFAR: 0x00000000 ``` - PC/LR are 0x41e94/0x41ef9 in this build; in the build of the original report they were 0x41194/0x411f9 (+0x300 shift for the same code region in the precompiled modem library). The fault happens extremely early (right after the Zephyr banner, before any application log line), consistent with the earlier observation, and the device remains stopped afterwards. Traces - Files (raw modem trace streams over UART1, second VCOM, 1 Mbaud; open them in Cellular Monitor with modem trace database mfw_nrf91x1_2.0.4, or convert to PCAP in Wireshark): - `trace-B6-shutdown500.raw` (1.16 MB) - the failing run's window: **no trace bytes arrived from the shutdown sequence through the failing boot** ; after a manual reset the recovered device streamed 1.16 MB (boot + modem initialization + running application). The fault itself is evidenced by the console dump above. - Clean-cycle windows: `trace-C3retry-shutdown0.raw` (885 KB), `trace-C3-shutdown0.raw` (642 KB), `trace-B1-shutdown500.raw` (257 KB), `trace-B5-shutdown500.raw` (129 KB), `trace-smoke-test2.raw` (890 KB). - Caveat about our capture setup: the raw stream arrives in bursts - hundreds of KB around a boot / modem (re-)initialization, and quiet in between. In the failing run's window the stream produced no bytes at all until the next reset, and the failing boot itself (crash within the first few hundred ms) produced no trace output before it faulted. We are not sure yet whether the shutdown phase can be captured at all by tracing this way. - If you want a specific window captured with a specific tool (e.g. nRF Connect Cellular Monitor live capture, or nrfutil trace with its database installed) or with different trace settings, please say so - the failure is timing-dependent, so reproducing it again may take a number of attempts. - Since these traces contain device/network identifiers (IMEI, cell IDs, IP addresses, operator and server names), we would prefer to share them through a private channel rather than attaching them publicly. If a support case is the right place for them, we will attach them there - please advise what works best on your side. Observations - The 500 ms pause does not reliably prevent the failure - it occurred with the pause in place (1 of 6 runs). - Reproduced rate in this session: 1 failure in 10 full shutdown cycles (lower than the 2 of 3 we initially saw; the failure seems timing-dependent). - Separate observation (may or may not be related): calling the shutdown sequence very early after boot (about 10 s after a reset, while the modem is still searching) hung once in lte_lc_offline() without returning; steady-state calls (about one minute after boot) never hung. We can provide details if useful. - Happy to run more repetitions, longer pauses, or capture a specific window if that helps. Best regards, RogerLeehttps://devzone.nordicsemi.com/f/nordic-q-a/129203/nrf-stop-scanning-coded-phy-beacon/571493Wed, 23 Sep 2026 13:45:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:5f883cdf-12ac-4bb9-91e7-0579d1478205Einar ThorsrudHi, I came across another report of a similar issue, where the problem was too small buffer sizes on the network core . It could be worth increasing those on your end as well unless you have allready figured this out.https://devzone.nordicsemi.com/f/nordic-q-a/129260/bt_observer-scan-callbacks-stop-after-a-while-with-config_bt_ext_adv-y-on-ncs-v3-4-0-nrf5340/571492Wed, 23 Sep 2026 13:43:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:fc785e02-3c89-40f4-8837-11783d476803Einar ThorsrudHi, I was able to reproduce this on my end as well. The network core is crashing due to too small event buffers. These should be 255 byte to match the host configuration when both extended advertising and observer is enabled. The fix is to add this to your sysbuild/ipc_radio.conf: CONFIG_BT_BUF_EVT_RX_SIZE=255 CONFIG_BT_BUF_CMD_TX_SIZE=255