https://devzone.nordicsemi.com/f/nordic-q-a/128571/nrf54l15-spi-slave-not-work-as-expected/568579Tue, 30 Jun 2026 02:16:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:889483f6-22e7-407e-a880-8da5a17ff0fderihsuHi, Simon I have remaped pin in board files and swap MISO/MOSI wiring. But still got spi_transceive hangs. I also posted the prj.conf, which may help this. CONFIG_SPI=y CONFIG_SPI_SLAVE=y CONFIG_SPI_ASYNC=y CONFIG_USE_SEGGER_RTT=y CONFIG_RTT_CONSOLE=y CONFIG_UART_CONSOLE=n CONFIG_LOG=y nrf52833 just runs a spim example running 8M spi sck and I verify it by logic analyzer. I can also post my nrf52833 SPIM project if it can help. By the way, don't worry about it. We are also considering another solution if nrf54L15 SPIS cannot be fit in.https://devzone.nordicsemi.com/f/nordic-q-a/128586/ncs-v3-3-0-inquire-about-the-possibility-of-bypassing-kmu-key-verification-for-single-slot-operationTue, 30 Jun 2026 02:11:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:578a1171-43b2-436a-bd2c-f322519b7178YI YANRONGHi Nordic Support Team, We are currently evaluating the nRF54L05 DFU single-slot sample in NCS v3.3.0. Our question is: Is it technically possible to configure the single-slot DFU or MCUboot to operate without the KMU key verification process? We would like to understand if there is any Kconfig option or build flag that allows bypassing the KMU for development or specific use cases. Any clarification on this would be greatly appreciated. Best regards, RyansoftwarenRF Connect SDKnRF54L05zephyrproductionhttps://devzone.nordicsemi.com/f/nordic-q-a/128533/ble-ota-by-ble-connection-not-by-dtm-mode/568578Tue, 30 Jun 2026 00:22:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b96cf17f-85e2-4586-9cef-d16af5a7fa27JohnnywenHi Kenneth, OK, looking forward to your comment, Thanks. Wen Junhttps://devzone.nordicsemi.com/f/nordic-q-a/128575/channel-sounding-ranging-algorithm/568577Mon, 29 Jun 2026 22:13:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:eb45d72f-81d0-4f8c-b64f-05502d8440a5loquatOK.Thanks.https://devzone.nordicsemi.com/f/nordic-q-a/128560/synchronization-over-lte-nb-iot---sntp-time-accuracy/568576Mon, 29 Jun 2026 20:36:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:3cf3950f-e0dd-4352-be8b-8028e60acff2tescHi, [quote user=""]What is the expected accuracy of SNTP time synchronization over LTE on the nRF9160?[/quote] While NTP can achieve sub-ms resolution on cabled networks, I would not expect too much from SNTP over an LTE network. Maybe around 100 ms could be achievable, but highly dependent on the network operator. [quote user=""] What is the expected accuracy of LTE network time received via NITZ or SIB16 (configurable via AT%XNETTIME )? Are either of these solutions capable of meeting our < 1 ms accuracy requirement? Are there any other Nordic-supported time synchronization solutions that could meet our accuracy requirement given our constraints? [/quote] I will need to look further into this, and expect to have more answers within a couple of days. In the meantime, I highly encourage the community here on DevZone to weigh in. Regards, Terjehttps://devzone.nordicsemi.com/f/nordic-q-a/128559/aliro-expose-session-error-code-to-the-application/568575Mon, 29 Jun 2026 20:25:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b3ed9bbb-6bd4-40bd-89c9-10e14ed24ba2tescHi, Thank you for the request. I have shared it with the team, and hopefully this is either something we can add, or there is some other workaround for getting the same. Regards, Terjehttps://devzone.nordicsemi.com/f/nordic-q-a/128562/nrf54l15-dk-zephyr-posix-udp-socket-over-openthread-nat64-sends-coap-successfully-but-poll-recv-does-not-receive-returned-packet/568574Mon, 29 Jun 2026 20:13:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e56fa8c7-c1b1-4e18-9205-1d976619c5f3MarkusKThanks a lot, that helps. The RFC8422 point makes sense and matches my OpenSSL tests. It explains why the client needs to advertise both curves: one for the ECDSA certificate/key and one for the ephemeral ECDHE key exchange. In my Zephyr secure socket test the ClientHello now contains both secp256r1 and secp384r1, and the ThingsBoard server accepts it and sends the full server flight. So the supported_groups issue seems solved for that path. The remaining problem is probably later, while processing the server flight. Your note about the certificate chain is interesting: 3 certificates, about 3196 bytes, wildcard CN, and the server also sends CertificateRequest. Even with peer verification disabled, this is a rather complex DTLS server flight for an embedded client. So I think I will stop debugging directly against ThingsBoard for the moment and set up a controlled local CoAPS test server first, with a short self-signed EC certificate, no wildcard, no client certificate request, and the same AES128-CCM8 cipher suite. If that works, then the remaining issue is likely specific to the ThingsBoard certificate flight / DTLS profile rather than the basic Zephyr/OpenThread DTLS transport.https://devzone.nordicsemi.com/f/nordic-q-a/128582/vs-code-keeps-selecting-wrong-build-configuration/568571Mon, 29 Jun 2026 19:25:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:f893e757-5a49-4960-928a-0d0fa1215ecaAmanda HsiehHi Will, Try selecting the app entry under the build configuration entry as the following figure: Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/128583/nrf54l105-flpr-support/568570Mon, 29 Jun 2026 19:07:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:4cdcece4-2df8-4a42-bfb4-d65fb45d6b9fAmanda HsiehHI, Unfortunately, the current NCS doesn't support FLPR on nRF54L05. See https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/device_guides/nrf54l/vpr_flpr.html Please contact your regional sales manager or use the form of Sales related questions for the plan or feature request. Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/128566/nrf5340-audio-unicast-server-unicast-client-configuration/568569Mon, 29 Jun 2026 18:50:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2599e86b-6aa4-45a2-859e-f25c19d0ce0aAmanda HsiehHi Pier, Did you configure the headset location ? Also, see the Programming CIS transport mode with two headsets or stereo . Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/128562/nrf54l15-dk-zephyr-posix-udp-socket-over-openthread-nat64-sends-coap-successfully-but-poll-recv-does-not-receive-returned-packet/568568Mon, 29 Jun 2026 18:14:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c373d069-a781-40d8-a0ed-51278ffa9a7dAchim Kraus> Interestingly, the actual ECDHE key exchange later used prime256v1 . The server certificates uses SHA256withECDSA, SHA384withECDSA and SHA384withRSA. If I remember it well, SHA384withECDSA uses then the secp384r1 . And RFC8422 then defines: NOTE: A server participating in an ECDHE_ECDSA key exchange may use different curves for the ECDSA or EdDSA key in its certificate and for the ephemeral ECDH key in the ServerKeyExchange message. The server MUST consider the extensions in both cases. So the curves must match both, ECDSA and ECDHE. > The remaining problem then seems to be on the embedded client side: it does not continue after ServerHelloDone . The server's certificate chain uses 3 certificates and has a size of 3196 bytes. It uses a wildcard in the CN, "*. eu.thingsboard.cloud ". Therefore not sure, what makes the client reject the certificate. Maybe the overall size, maybe the wildcard, if the client complies with RFC7252 about the used x509 certificates, ...If there is no SubjectAltName in the certificate, then the authority of the request URI MUST match the Common Name (CN) found in the certificate using the matching rules defined in [ RFC3280 ] with the exception that certificates with wildcards are not allowed.https://devzone.nordicsemi.com/f/nordic-q-a/128585/question-about-the-nrf54l15-dk-npm1300-power-connectionsMon, 29 Jun 2026 17:59:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:3e3eb657-d7cc-4194-b58c-04ffd8b3c294Tim012Hi, I'm using the published nRF54L15 DK hardware files and noticed something that I don't understand. On the nPM1300 section of the schematic and PCB: Pin 20 ( VSYS ) is connected to the P5V0 rail. Pin 30 ( LSIN2/VINLDO2 ) is also connected to P5V0 , which makes sense as the load switch input. However, Pin 32 ( VOUT2 , BUCK2 output) also appears to be connected to the same P5V0 rail. Looking at the PCB layout, it appears that pins 20 , 30 , and 32 are all on the same copper connection. In the nPM1300 Product Specification: VOUT2 is described as the output of BUCK2. BUCK2 is an independent regulator. The reference configurations either use BUCK2 as a separate regulator or leave it unused. I couldn't find any documentation explaining why VOUT2 is connected to VSYS on the DK. Is BUCK2 intentionally disabled and VOUT2 repurposed in this design, or is there another reason for tying VOUT2 to the VSYS/P5V0 rail? I know VSET 2 is grounded and cannot switch the regulator on I'm designing custom hardware based on the nPM1300 and would like to understand whether this is a recommended design practice or is this something specific to the DK implementation.developmentpcbhardwarenPM1300https://devzone.nordicsemi.com/f/nordic-q-a/122856/test/568567Mon, 29 Jun 2026 17:50:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:4878cb86-db56-4b95-9435-f5a732a0b3b0Tim012.https://devzone.nordicsemi.com/f/nordic-q-a/128578/i2c-clock-stretching-nrf54l-zephyr/568566Mon, 29 Jun 2026 16:54:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:3ffa9b9d-9b4a-4af6-a98e-196854a94056Kazi Afroza Sultana''Run at 100 kbps minimum with the TWIM peripheral'' The supported bit rate of TWIM is 100kbos, 400kbps, 100 kbps, which I mentioned in my previous reply with the source link. This frequency is enforced at the Zephyr driver level. You will configure this in the device tree file(overlay file). For example: &i2c20 { status = "okay"; pinctrl-0 = ; pinctrl-1 = ; pinctrl-names = "default", "sleep"; clock-frequency = ; /* 100 kbps */ /* Example sensor device */ my_sensor: sensor@48 { compatible = "vendor,sensor"; reg = ; status = "okay"; }; }; When we set ''I2C_BITRATE_STANDARD'' as clock frequency, we set it as 100kbps. '' Do you mean enabled as in kconfig/devicetree, or enabled by running i2c_configure()? Also, I'd rather not be talking directly to registers if possible while using Zephyr.'' No, these PSEL.SCL and PSEL.SDA registers are not configured in the kconfig or not by running i2c_configure(). This is set in the pincntrl file of board file. for example: &pinctrl { /omit-if-no-ref/ i2c21_default: i2c21_default { group1 { psels = , ; bias-pull-up; }; }; /omit-if-no-ref/ i2c21_sleep: i2c21_sleep { group1 { psels = , ; low-power-enable; }; }; }; Now getting back to the clock stretching of TWIM again, since it is supported in TWIM, it may possible to set the bit rate below 100kbps according to this old case (+) I2C frequencies below 100kbps - Nordic Q&A - Nordic DevZone - Nordic DevZone . I will talk to team to be sure. '' The MAX41462 has a 4 byte FIFO buffer and implements flow control by I2C clock stretching which seems to be causing the crash - using a logic analyser I can see the clock signal being held low after 8 bits of data transfer. '' Could you please share the error log and the output from logic analyser? Thanks. BR Kazihttps://devzone.nordicsemi.com/f/nordic-q-a/128550/subject-mpsl-assert-69-108-and-hardfault-when-using-esb-config_esb_mpsl_timeslot-with-ble-dual-connection-and-zms-on-ncs-v3-3-0-nrf54l10/568565Mon, 29 Jun 2026 15:47:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d9951c79-bb78-4cb8-87c3-33a2c14f2d3dKazi Afroza SultanaHello, Can you try to set CONFIG_MPSL_HFCLK_LATENCY=1650 in the prj.conf file and try again to run the sample? Thanks. BR Kazihttps://devzone.nordicsemi.com/f/nordic-q-a/128571/nrf54l15-spi-slave-not-work-as-expected/568564Mon, 29 Jun 2026 15:29:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:07c48885-7de5-406a-af53-6dbae15e9a15Simon D-MHi, I'm sorry, but I believe that your issue here is indeed because of your pin mapping... If we follow closely the documentation ( link ), I think that you mixed up the MISO and MOSI pins. P2.01 SPIS SCK OK P2.02 SPIS SDO NOT OK (MOSI = slave SDI) P2.04 SPIS SDI NOT OK (MISO = slave SDO) P2.05 SPIS CSN OK Do you have any way of trying to cross these traces/wires on your board? Best regards, Simonhttps://devzone.nordicsemi.com/f/nordic-q-a/128544/azure-iot-hub-demo-on-nrf54h20dk-nrf7002ek-problems/568563Mon, 29 Jun 2026 15:14:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c71c566c-fd03-46e9-b9b9-92719f198d81Amanda HsiehI am checking with the team and will update once I have enough information. Please give us more time to investigate the issue. Thanks for your patience.https://devzone.nordicsemi.com/f/nordic-q-a/128578/i2c-clock-stretching-nrf54l-zephyr/568562Mon, 29 Jun 2026 15:03:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:ba6a9f26-8f73-4a1a-9c67-158eba6e1ed0Nick_RA[quote userid="108933" url="~/f/nordic-q-a/128578/i2c-clock-stretching-nrf54l-zephyr/568543"]You can try at least 100kbps as a first try to see if that helps.[/quote] OK, but I don't want to blindly try things, I want to understand what's what. Is I2C clock stretching supported? Can I configure a timeout by code, kconfig etc? [quote userid="108933" url="~/f/nordic-q-a/128578/i2c-clock-stretching-nrf54l-zephyr/568543"]These registers and their configurations are only used when TWIM is enabled[/quote] Do you mean enabled as in kconfig/devicetree, or enabled by running i2c_configure()? Also, I'd rather not be talking directly to registers if possible while using Zephyr.https://devzone.nordicsemi.com/f/nordic-q-a/128581/nrf5340-the-zephyer-os-priority-issue-the-ble-thread-and-the-other-thread-priority-can-be-changed/568561Mon, 29 Jun 2026 15:01:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:5fe94d6a-51cf-4895-8f80-c0ad1782f2ffAmanda HsiehHi, [quote user=""] the BLE thread and the other thread priority can be changed?[/quote] Yes, a thread's priority in Zephyr RTOS can be altered up or down after the thread has been started, m eaning a preemptible thread can become a cooperative thread and vice versa. See Thread Priorities . [quote user=""]Does the BLE thread be the 1st priority than other thread all the time?[/quote] The BLE stack uses the System w ork queue (priority -1) as a cooperative thread, which gives it a high priority, but it is not unconditional ly the highest priority. Any thread with a priority lower than -1 (e.g., -2, -3, etc.) would have higher priority. See the DevAcademy course: Scheduler In-Depth [quote user=""]can the BLE thread change to lower priority? how to change it in the zephyer OS.[/quote] What is your NCS version? Are you using standard HCI IPC ( SB_CONFIG_NETCORE_IPC_RADIO_BT_HCI_IPC ) or RPC on the NetCore? Regards, Amanda H.https://devzone.nordicsemi.com/f/nordic-q-a/127797/using-nfc-on-nrf5340-to-do-type-4-card-emulation-how-can-i-set-the-ats-bytes-for-the-rats-request-from-a-reader/568560Mon, 29 Jun 2026 14:36:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:82643c45-4349-40fd-98bf-808f5fc996a3BrianWthanks for that. Given: [quote userid="145945" url="~/f/nordic-q-a/127797/using-nfc-on-nrf5340-to-do-type-4-card-emulation-how-can-i-set-the-ats-bytes-for-the-rats-request-from-a-reader/568532"]Why do PC/SC applications care? Contactless cards do not present a classic contact-style ATR. PC/SC readers synthesize a virtual ATR for ISO14443-4 Type A cards, and the ATS bytes become the ATR historical bytes ( PC/SC interface for smart cards ). If an application expects a specific card profile, it may reject the reader connection based on that ATR - even when raw APDU exchange works on other interfaces. That aligns with what you see.[/quote] this confirms that it is critical that the library ATS reponse can be set by the application to allow correct operation! [quote userid="145945" url="~/f/nordic-q-a/127797/using-nfc-on-nrf5340-to-do-type-4-card-emulation-how-can-i-set-the-ats-bytes-for-the-rats-request-from-a-reader/568532"]The ATS response is generated inside the library stack and is not configurable through the public API.[/quote] When is it planned to change this? Also: [quote userid="145945" url="~/f/nordic-q-a/127797/using-nfc-on-nrf5340-to-do-type-4-card-emulation-how-can-i-set-the-ats-bytes-for-the-rats-request-from-a-reader/568532"]The SELRES should be set after setup nfc_t4t_setup() but before emulation start nfc_t4t_emulation_start() .[/quote] Nice to know, however my experience is that if this is done between set and start, then I get an error of -22 (invalid param). does this mean that the library validates the SELRES value set matches the setup method called? This is a problem when I am trying to emulate a card which is not a standard type4 (eg a mifare classic - this is why I am handling the APDU commands myself), as the reader will often use the SAK to determine historical card types (there is a flowchart from NXP in AN10833 about how to do this...) Is there a way round this check? thanks