https://devzone.nordicsemi.com/f/nordic-q-a/128719/nrf54l10-with-watchdog/569236Mon, 20 Jul 2026 05:48:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:bbe32603-ac7c-41a4-9233-ec6d82dce1f4omtFair point on the domain isolation rationale — though it does make me wonder about consistency. By that same logic, you could technically report "System ON: 2 µA" as the headline and leave "but you need to power the domain feeding the CPU core too, +3 µA" as a footnote in chapter 18. WDT isn't an optional add-on like a second SPI channel — it's baseline for any production-grade application, so hiding its cost outside the main comparison numbers ends up following the same pattern. Anyway, thanks for the straight answer — genuinely appreciatedhttps://devzone.nordicsemi.com/f/nordic-q-a/127625/about-esb_ptx_ble-esb_prx_ble/569235Mon, 20 Jul 2026 04:19:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8fb6e7d7-0ade-45ab-aa87-562b705d3987Leo MoHello AHaug, Thanks! Another question is why sending 8 bytes, 16 bytes, and 32 bytes takes about the same amount of time? Is it time-consuming to prepare before sending? config ESB_MPSL_TIMESLOT bool "ESB on MPSL Timeslot [EXPERIMENTAL]" select EXPERIMENTAL depends on MPSL depends on ! ESB_NEVER_DISABLE_TX depends on ! SOC_SERIES_NRF53 help This option configures the ESB to use the MPSL Timeslot API as middleman in radio access. It allows multiple protocols to be used concurrently. Using the Timeslot API can increase number of retransmissions, reduce ESB packets delivery rate, and cause the delay of retransmissions to vary. config ESB_NEVER_DISABLE_TX select EXPERIMENTAL bool "Never disable radio transmission stage" help This option changes the radio behavior so that the transmitter remains IDLE between transmissions instead of being disabled. This is applicable only when the packet is not acknowledged. Otherwise, the radio emitter needs to be turned off to enable the radio receiver. This reduces delay between consecutive transmissions but consumes more energy. ESB_MPSL_TIMESLOT and ESB_NEVER_DISABLE_TX cannot be set to y at the same time. Is there any way to reduce the preparation time before launch. while (1) { err = esb_initialize(); if (err) { LOG_ERR("ESB initialization failed, err %d", err); return 0; } tx_payload.length = 32; for (int i = 0; i > 8) & 0x7F; tx_count = 0; k_sleep(K_MSEC(1000)); }https://devzone.nordicsemi.com/f/nordic-q-a/128743/dual-mode-on-nrf5340---receive-bluetooth-classic-le--12s-simultaneous-with-i2s--unicast-to-different-deviceMon, 20 Jul 2026 02:19:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:1d3b03af-8096-4894-b11a-a7124a7fcec0Joe0123Hi, 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. JoesoftwareEvaluationauto_softwareauto_le_audioauto_bluetoothbluetooth leauto_nrf5340nRF5340https://devzone.nordicsemi.com/f/nordic-q-a/128736/nrf9151-gci-searches-returning-limited-results/569234Mon, 20 Jul 2026 00:18:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b34fb47d-cae6-4fee-a605-0e31f0ad960dJordanYatesAttached is the modem trace file from boot across a few iterations of the cell searches. The global search found a second cell more often than last week, but was still measurably worse than the EXTENDED_LIGHT search for all runs. GCI_EXTENDED_LIGHT also never found any extra cells over GCI_DEFAULT, and returned fewer result on at least one run. [00:04:00.000,122] task_network_scan: Search Type: 2 GCI_Count: 0 [00:04:00.663,726] task_network_scan: Serving Cell Valid: Yes, Neighbour Cells: 4 [00:04:00.663,726] task_network_scan: ID: 147045644 RSRP: 108 dBm [00:04:00.663,757] task_network_scan: Neighbour ID: 372 RSRP: 108 dBm [00:04:00.663,757] task_network_scan: Neighbour ID: 70 RSRP: 118 dBm [00:04:00.663,787] task_network_scan: Neighbour ID: 302 RSRP: 116 dBm [00:04:00.663,787] task_network_scan: Neighbour ID: 238 RSRP: 121 dBm [00:04:00.663,940] task_network_scan: Search Type: 4 GCI_Count: 11 [00:04:00.967,102] task_network_scan: Global Cells: 2 [00:04:00.967,102] task_network_scan: Global ID: 147249163 RSRP: 108 dBm [00:04:00.967,132] task_network_scan: Global ID: 147045644 RSRP: 109 dBm [00:04:00.967,285] task_network_scan: Search Type: 5 GCI_Count: 11 [00:04:07.806,121] task_network_scan: Global Cells: 1 [00:04:07.806,152] task_network_scan: Global ID: 147045644 RSRP: 105 dBm I updated the modem firmware from 2.0.3 to 2.0.4 before capturing the trace. devzone.nordicsemi.com/.../1784505677_5F00_nrf_5F00_modem_5F00_trace.ziphttps://devzone.nordicsemi.com/f/nordic-q-a/128742/nrf-cloud-account-auth-broken-rest-api-key-40100-and-device-coap--13Sun, 19 Jul 2026 00:58:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:5c7b8e65-b713-479b-8395-b858bd91f6d4drrh12On 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 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 "). - 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.developmentsoftwareauto_nrf9151nRF Cloudauto_softwareauto_nrf_connect_sdkauto_configurationauto_nrf_cloudauto_cellular_iothttps://devzone.nordicsemi.com/f/nordic-q-a/128676/creating-multiple-bigs-with-one-gateway-nrf5340-audio-dk/569233Sat, 18 Jul 2026 20:59:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:72a598f5-e00d-4173-9543-3a55cd6e0cf1dark73I would like to correct my previous statement. and SUB0 and SUB1 are displayed on the phone. behavior to be: SUB0 → KOR audio SUB1 → ENG audio However, the actual behavior is: SUB0 → KOR audio SUB1 → KOR audiohttps://devzone.nordicsemi.com/f/nordic-q-a/128676/creating-multiple-bigs-with-one-gateway-nrf5340-audio-dk/569232Sat, 18 Jul 2026 20:57:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:3ff053b9-c376-4f8c-a443-220c0bee23fcdark73Thank you very much for your continuous support and for taking the time to answer my questions. All previous issues have been resolved. I separated the broadcast into two subgroups and implemented the code so that each encoded audio stream (KOR and ENG) can be transmitted through different subgroups. The KOR audio is assigned to SUB0, and the ENG audio is assigned to SUB1. However, only the KOR audio is being broadcast. The audio from SUB0 also affects SUB1, so the KOR audio can be heard from SUB1 as well. I verified that KOR and ENG are different audio streams by broadcasting them separately through only SUB0. My question is: I called subgroup_send() with different audio frames according to each subgroup, but why is the audio assigned to SUB0 also being transmitted through SUB1? I modified subgroup_send() so that it receives the encoded audio frame as an argument and sends it using broadcast_source_send(audio_frame, stream_idx.lvl1, stream_idx.lvl2) . I expected the behavior to be: SUB0 → KOR audio → BIG0 SUB1 → ENG audio → BIG1 However, the actual behavior is: SUB0 → KOR audio → BIG0 SUB1 → KOR audio → BIG1 It seems that the frame buffer or stream mapping is still shared between the subgroups. I would like to know if there is any additional configuration or buffer separation required when using multiple subgroups. Also, does broadcast_source_send() use the subgroup index ( lvl1 , lvl2 ) only for routing, or is there another internal mechanism that determines which LC3 frame is transmitted for each subgroup? Below is my modified subgroup_send() code. ** The stream_frame_send () function is called from encoder_thread() ** void stream_frame_send ( struct net_buf * audio_kor , struct net_buf * audio_eng ) { struct stream_index kor_idx = { .lvl1 = 0 , .lvl2 = 0 , .lvl3 = 0 }; subgroup_send (kor_idx, audio_kor); struct stream_index eng_idx = { .lvl1 = 0 , .lvl2 = 1 , .lvl3 = 0 }; subgroup_send (eng_idx, audio_eng); } static void subgroup_send ( struct stream_index stream_idx , struct net_buf * audio_frame_out ) { int ret ; static int prev_ret ; uint8_t num_bis = subgroups [ stream_idx . lvl1 ][ stream_idx . lvl2 ]. num_bises ; size_t frame_size = lc3_stream_infos [ stream_idx . lvl1 ][ stream_idx . lvl2 ]. frame_size ; struct net_buf * audio_frame = net_buf_alloc ( & ble_tx_pool , K_NO_WAIT ); struct audio_metadata * meta = net_buf_user_data ( audio_frame ); memset ( meta , 0 , sizeof ( * meta )); if ( audio_frame == NULL ) { LOG_ERR ( "Out of RX buffers" ); return ; } for ( int i = 0 ; i locations |= ( uint32_t ) subgroups [ stream_idx . lvl1 ][ stream_idx . lvl2 ]. location [ i ]; } // Modified code net_buf_add_mem ( audio_frame , audio_frame_out -> data , audio_frame_out -> len ); meta -> data_coding = LC3 ; struct bt_audio_codec_cfg * codec_cfg = & subgroups [ stream_idx . lvl1 ][ stream_idx . lvl2 ]. group_lc3_preset . codec_cfg ; ret = le_audio_freq_hz_get ( codec_cfg , & meta -> sample_rate_hz ); if ( ret ) { LOG_ERR ( "Failed to get frequency: %d" , ret ); } ret = le_audio_duration_us_get ( codec_cfg , & meta -> data_len_us ); if ( ret ) { LOG_ERR ( "Failed to get frame duration: %d" , ret ); } ret = broadcast_source_send ( audio_frame , stream_idx . lvl1 , stream_idx . lvl2 ); if ( ret != 0 && ret != prev_ret ) { if ( ret == - ECANCELED ) { LOG_WRN ( "Sending cancelled" ); } else { LOG_WRN ( "broadcast_source_send returned: %d" , ret ); } } net_buf_unref ( audio_frame ); prev_ret = ret ; }https://devzone.nordicsemi.com/f/nordic-q-a/128731/npm1100-ship-mode/569231Sat, 18 Jul 2026 15:09:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2f3a923b-fad2-42a2-bb4f-9bf0ff0f80a5Kazi Afroza SultanaHello, 1. '' If I don't need the switch on SHPHLD, do I just connect SHPHLD directly to VBAT?'' Yes you can just connect SHPHLD directly to VBAT. According to datasheet, ''there are two ways to exit Ship mode. Either connect the USB ( VBUS ) or set SHPHLD low for a minimum period of t shipToActive . The battery supply ( VBAT ) is used to hold SHPHLD high through a weak pull-up resistor when Ship mode is enabled. A circuit to pull down SHPHLD is optional (see the Button switch shown in the following figure). If no pull-down circuit is present, Ship mode is exited when VBUS is connected. Product overview • nPM1100 Product Specification • Technical Documentation SO, if you don't need to switch. you can just connect this pin to VBAT to keep it high. 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. 100kohm is current limiting pull up resistor. If you don't need the wake up button you can omit this part. The 100k mentioned is the datasheet is chosen for minimizing current in a battery product. the EK hardware design focuses on having less noise over uA level current. 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? I don't think so as BUTTON is open and in such condition SHPHLD is a high impedance input. 4. Since the number 3 answer is no. You have very straight forward approach to enter ship according to datasheet, ( Product overview • nPM1100 Product Specification • Technical Documentation ) "To enter Ship mode, SHPACT must be set high for a minimum period of tactiveToShip = 200 ms when VBUS is disconnected and SHPHLD held high.'' So, to enter Ship mode, you have to follow the following steps: 1. Connect a button between SHPACT and VBAT. 2. Button should be pressed at least for 200ms. 3. When button is not pressed, internal pull down (500kohm) holds SHPACT low. Thanks. BR Kazihttps://devzone.nordicsemi.com/f/nordic-q-a/128665/application-fails-to-boot-with-mcuboot-image-in-external-flash-and-tf-m/569230Sat, 18 Jul 2026 14:13:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a83caab3-5928-49db-85f6-b0496d17150dandvibYou were spot on - now it works! I misunderstood how app, tfm_nonsecure and mcuboot_primary ties together, so cleaning them up fixed it. Thanks a lot!https://devzone.nordicsemi.com/f/nordic-q-a/123763/please-cancel-this-ticket/569229Sat, 18 Jul 2026 06:51:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:97189569-983e-40f7-9b4f-685eb341f778fgfgergMovieBox APK is a free streaming app which has made it possible for users to watch out for the latest in movies, TV shows and web series right from their Android devices. https://movieboxapkdownload.net/https://devzone.nordicsemi.com/f/nordic-q-a/123763/please-cancel-this-ticket/569228Sat, 18 Jul 2026 05:57:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:f4acf442-a77a-49e1-a7f1-6c1a0161e5b9fgfgergMovieBox Apk is an amazing entertainment app. It provides you with free interesting movies, comedy movies, entertainment movies and serious movies. It also provides you with TV shows, sports stories and live music shows, world news and many more things. https://movie-box.co.za/https://devzone.nordicsemi.com/f/nordic-q-a/123613/i2s-master-frequency-stuck-at-10-khz/569225Sat, 18 Jul 2026 03:58:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:555693a7-9e91-4f50-8167-beca24b03f3flilyhunder98It's always the logic analyzer, isn't it? I've pulled my hair out over similar issues, thinking it was some deep-seated bug in my code, only to find my tools were misleading me. Glad you figured it out! It's tricky enough getting I2S working without false positives. Reminds me of debugging some weird hitboxes in Pokerogue .https://devzone.nordicsemi.com/f/nordic-q-a/128538/nrf54lm20a_dk-vscode-cannot-be-programmed/569224Sat, 18 Jul 2026 02:12:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c49c8599-a163-4eb8-9db3-73e24d641429john.liuHi SwRa: Thank you for your help! "nRF Connect for Desktop" can be programmed, but "VScode" cannot. After using " nrfutil device recover --serial-number 1051847907 ", it is also cannot.https://devzone.nordicsemi.com/f/nordic-q-a/122056/how-to-use-the-health-model-of-bluetooth-mesh/569223Sat, 18 Jul 2026 02:07:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:eab2ed80-f7c2-4c50-a186-0ec8e948c7aeChristina67I’ve been working with the Bluetooth Mesh Health model too, and I ran into similar confusion. For the periodic fault upload: check that you’ve set fault_period in the Health SRV configuration and that you’re calling bt_mesh_health_srv_fault_update() appropriately – the stack won’t upload automatically unless you trigger it after changes. Regarding fault_get_cur : in many Zephyr implementations, this callback is indeed redundant or not fully used – fault_get_reg is the one that actually returns the current registered faults. The “cur” variant often maps to the same register unless you override it with custom logic. I’d suggest focusing on fault_get_reg and fault_clear for practical use. For detailed examples, the Zephyr sample samples/bluetooth/mesh has a health server demo, but it’s not exhaustive. I found better step‑by‑step breakdowns on community blogs. On a side note, if you’re ever looking for clear, practical guides on other topics – like menu breakdowns – I’d recommend checking out the dutch bros frost menu page; it’s surprisingly well laid out and impressed me with how simply it explains everything, similar to what I wish the Health Model docs did. Hope that helps – let me know if you want me to share my actual callback setup code.https://devzone.nordicsemi.com/f/nordic-q-a/80629/decouple-mcuboot-public-key-storage-and-image-signing-nrf9160-mcuboot/569222Fri, 17 Jul 2026 23:45:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:af5a4b2b-fcf5-4613-8d73-755f509c0ce6J.P. HutchinsWe have added support for multiple keys here: https://github.com/zephyrproject-rtos/zephyr/commit/e8c5edf40532720ef219dcdeebc3cf5978e6e390 You are correct that MCUboot never needs access to the private key and it is verified in unit tests: https://github.com/mcu-tools/mcuboot/pull/2702 . In order to produce a signed application image you do need to have access to some private key that corresponds to one of the public keys that MCUboot will embed in the image for verification.https://devzone.nordicsemi.com/f/nordic-q-a/115651/signing-file-with-a-relative-key-path/569221Fri, 17 Jul 2026 23:41:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a664a87e-3b96-4a14-97fc-220870c065c1J.P. HutchinsNewer versions of sysbuild will expand cmake variables in kconfig fragments, so you can use ${APP_DIR}, and we're updating the documentation here: github.com/.../111814https://devzone.nordicsemi.com/f/nordic-q-a/113899/adding-a-custom-signature-key-file-with-application_config_dir-does-not-work/569220Fri, 17 Jul 2026 23:39:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a39e2d61-680e-46c9-aefb-591b6dc38516J.P. HutchinsThis will work with newer versions of sysbuild and we're updating the documentation: github.com/.../111814https://devzone.nordicsemi.com/f/nordic-q-a/128579/at-cfun-20-lte_lc_func_mode_set-deactivate_lte-blocks-indefinitely-under-registration-churn-software-deadlock-ruled-out-nrf9151-mfw-2-0-4-ncs-3-3-0/569219Fri, 17 Jul 2026 22:35:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:7da091b5-3b62-43e6-aa4b-82c5d89c389cEdemusmaxHopefully, any of this may be helpful. This was from an offline discussion with an engineer. "Closing the loop on our report of lte_lc_offline() / AT+CFUN=20 never returning on the nRF9151 (Thingy:91X, modem FW mfw_nrf91x1_2.0.2, NCS v3.3.0). I've completed my investigation and field validation, and no further support is needed — but I wanted to leave you a summary in case the pattern is useful to your modem team. What I found. The hang is strongly environment-dependent. At my original test site — dense coverage with roughly three overlapping cells of the same carrier — issuing CFUN=20 from RRC idle wedged reliably: +CEREG: 0 would arrive, but the command response never did, whether issued through lte_lc_offline() or directly via nrf_modem_at_cmd() . The calling thread blocks indefinitely inside the modem library; no error, no timeout. At a second site served by a single cell, the identical firmware performed the same transition cleanly three out of three times, with the OK response arriving in roughly 0.6–2 seconds. My working theory is a race in detach handling when the modem has multiple candidate cells at the moment of deactivation, but I did not root-cause beyond that boundary — it's inside the modem/library and beyond my visibility. How I resolved it. Since the wedge is unpreventable from application code, I made it survivable: a hardware watchdog supervised from my main loop catches the wedged state, a noinit RAM record carries intent across the reset, and firmware resumes the interrupted operation on reboot. With that architecture the transition now succeeds either immediately (clean environments) or after one watchdog cycle (overlap environments), and the feature built on it has passed multi-cycle field testing. If your modem team ever wants a repro: the signature is CFUN=1→20 from RRC idle in a multi-cell overlap zone; single-cell sites won't show it. Happy to share AT traces from both environments if useful, but please consider the ticket closed from my end."https://devzone.nordicsemi.com/f/nordic-q-a/128538/nrf54lm20a_dk-vscode-cannot-be-programmed/569218Fri, 17 Jul 2026 20:23:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:0e264825-aaef-420d-ae0b-d2ebaa04f515psychogenicThis was super annoying, same for me with two LM20B boards. Did a bunch of things, had all the latest version of SDK, nrfutil, etc then even downgraded JLink to version 9.24a, no go. But solution: upgrading nrfutil devices. Running an `nrfutil upgrade` did this: nrfutil-completion is already the newest version (1.5.0) Downloading nrfutil-device-x86_64-unknown-linux-gnu-2.19.4 Verifying nrfutil-device-x86_64-unknown-linux-gnu-2.19.4 Updating nrfutil-device to 2.19.4 [00:00:05] ###### 100% [Upgrade packages] Upgrade packages And things started working, even if I'd done the same only 2 days prior..? In any case, re-updated JLink to v9.6.0 and it still works.