Search Result

I’m facing a UICC failure issue on multiple nRF9151 DKs. Symptoms: AT+CPIN? returns ERROR %XSIM: 0,9 SIM VCC is not present (no 1.8 V observed) Nordic stock examples that previously worked now also fail Same physical SIM works correctly on a custom nRF9151 board that has never used SoftSIM Commands/results: AT%XVBAT %XVBAT: 5035 OK AT+CPIN? ERROR AT%XSIM? %XSIM: 0,9 OK AT+CFUN? +CFUN: 1 OK What I already tried: Full chip erase/recover Reflashed modem firmware Tested with Nordic sample applications Power cycle/reset Different SIM cards Verified SIM works on another board Important detail: All affected DKs had previously been used for SoftSIM/eSIM experiments. At this point I’m trying to determine: Whether %XSIM: 0,9 specifically indicates a hardware-level UICC failure Whether the modem suppresses SIM VCC if it detects an electrical fault on SIMIO/CLK/RST Whether anyone has seen permanent UICC damage after SoftSIM experiments or SIM line contention Whether there are additional

Hello Nordic Team, I am currently working with the nPM1300 EK together with the nRF54L15 platform and a custom 40 mAh Li-Po battery. I am facing an issue while configuring battery charging and discharging parameters in nPM PowerUP v2.2.4. The tool currently provides a minimum battery capacity option of 400 mAh, and I am unable to configure or generate settings for a 40 mAh battery. I would appreciate your guidance on the following points: How to create a valid battery profile .inc file for a 40 mAh Li-Po battery. Recommended charger configuration values for: Charge current Termination current Cutoff voltage Whether it is possible to use the fuel gauge functionality without the dedicated nPM Fuel Gauge Board. Recommended approach for performing charge/discharge testing and SOC estimation using only: nPM1300 EK nRF54L15 40 mAh battery Any available examples or documentation for low-capacity batteries (<100 mAh) with nPM1300. Current setup: nPM1300 EK

&pinctrl { spi21_imu_default: spi21_imu_default { group1 { psels = , , ; // nordic,drive-mode = ; }; }; spi21_imu_sleep: spi21_imu_sleep { group1 { psels = , , ; // nordic,drive-mode = ; low-power-enable; }; }; }; &spi21 { status = "okay"; pinctrl-0 = ; pinctrl-1 = ; pinctrl-names = "default", "sleep"; cs-gpios = ; overrun-character = ; bmi323: bmi323@0 { status = "okay"; compatible = "bosch,bmi323"; reg = ; spi-max-frequency = ; }; }; int spi_transceive(const struct spi_dt_spec *spi_dev, const uint8_t *tx_data, size_t tx_len, uint8_t *rx_data, size_t rx_len) { if (!artoo_spi_is_ready(spi_dev)) { return -ENODEV; } const struct spi_buf tx_buf = { .buf = (void *)tx_data, .len = tx_len, }; const struct spi_buf rx_buf = { .buf = rx_data, .len = rx_len, }; const struct spi_buf_set tx_set = { .buffers = &tx_buf, .count = 1, }; const struct spi_buf_set rx_set = { .buffers = &rx_buf, .count = 1, }; return spi_transceive_dt(spi_dev,

devzone.nordicsemi.com/.../DS_5F00_Abracon_5F00_ABM12W_2D00_40.0000MHZ_2D00_6_2D00_B1U_2D00_T3.pdf Any issues with this crystal and nRF7002?

Hi, while developing a custom driver for the nRF54L15, using the PWM I have found a potential bug. I have removed the custom driver and just enabled PWM shell and I can reproduce the bug typing this commands: Here the debug watch data of the pwm_nrfx_0_data structure during the test. Boot: After: pwm nsec pwmd2000 0 50000 0: (I would aspect the pwriod_cycles t be equal to 800). After: pwm nsec pwmd2000 1 50000 0: After: pwm nsec pwmd2000 1 50000 50000: After pwm nsec pwmd2000 1 50000 100: I hade basically this sequence of commands in my custom driver that is why I have found this issue. I believe the period_cycles of the driver instance is not properly set when pwm is configured with 100% pulse... We are on ncs 3.2.4 Thanks, andrea

Hi, I'm running into what looks like a software link-layer issue on the nRF54L15-DK that I'd like a second pair of eyes on. The same firmware works end-to-end with iOS / Android centrals but consistently fails post-MTU with Windows 10/11 centrals. ### Hardware / SW * **Board:** nRF54L15-DK (PCA10156), Engineering A * **SoC HCI report:** HW Variant `nRF54Lx (0x0005)` , Firmware `Standard Bluetooth controller (0x00) v4.2 Build 1` , HCI `5.4 (0x0d)` , manufacturer `0x05f1` * **Zephyr:** v4.2.1 (PlatformIO `[email protected]` ) * **Controller:** `CONFIG_BT_LL_SW_SPLIT=y` (default for nRF54L) * **Host configuration (relevant subset):** * `BT_PERIPHERAL=y` , `BT_MAX_CONN=1` , `BT_MAX_PAIRED=4` * `BT_SMP=y` , `BT_SMP_ENFORCE_MITM=y` , `BT_FIXED_PASSKEY=y` , `BT_SMP_SC_PAIR_ONLY=n` * GATT characteristics use `BT_GATT_PERM_*_AUTHEN` * `BT_GATT_SERVICE_CHANGED=n` , `BT_GATT_CACHING=n` (turning these on breaks iOS interop) * `BT_L2CAP_TX_MTU=247` , `BT_BUF_ACL_RX_SIZE=251` * `BT_PHY_UPDATE=n` , `BT_AUTO_PHY_UPDATE=n` , `BT_DATA_LEN_UPDATE=n` , `BT_CTLR_PHY_2M=n` * `BT_GAP_AUTO_UPDATE_CONN_PARAMS=n` , `BT_CTLR_CONN_PARAM_REQ=y` * `BT_LONG_WQ_PRIO=0` , `_STACK_SIZE=4096` (so SC P256 keygen completes) * `BT_CONN_TX_NOTIFY_WQ=y` , `_STACK_SIZE=2048`

i2c_write_read() returns -5 (EIO) immediately when writing register 0x01 to the sensor. Logic analyzer confirms the sensor clock-stretches SCL for ~14µs+ after receiving the byte while switching internal modes. Controller -NORA -B206 (nrf54l15) What works: Pure reads, writing 0x00 to same sensor, all other I2C devices on bus — no issues. Already tried: CONFIG_I2C_NRFX_TRANSFER_TIMEOUT=5000 — no change. Error fires instantly (hardware event, not software timeout). Questions: Does nRF54L15 TWIM have a configurable clock-stretch tolerance register? Any known errata for TWIM + clock-stretching slaves? Is CONFIG_I2C_GPIO (bitbang) the only workaround?

Hello Nordic Support, I am currently re-qualifying our Bluetooth product in Bluetooth SIG Launch Studio because we had to migrate from NCS SDK 2.1.4 to 2.9.2 due to a security vulnerability. We are trying to include to Bluetooth SIG qualification: Q322804 Q331781 However, Bluetooth SIG shows the following message when adding Q322804: "Design 322804 is going through correction and is temporarily unavailable. Please contact Nordic Semiconductor ASA for details or try again in a few days." Could you please let us know: when Q322804 is expected to become available again This issue is currently blocking our qualification submission and release process. Our production, development, and test teams are waiting for this qualification decision before we can proceed with releasing the product to the market. We would highly appreciate it if this could be treated with high priority. Thank you very much for your support. Best regards, Hamid

I recently completed a field-upgrade path from an nRF5 SDK 17.1 application (with the legacy Secure DFU bootloader) to a fresh NCS-based firmware stack, while preserving user data stored in FDS. It was easier than expected, so sharing the approach here in case it helps anyone in the same boat, and I'd appreciate any feedback. Goal Move from nRF5 SDK 17.1 + Secure DFU bootloader → NCS with MCUboot + firmware_loader + application. Preserve the legacy FDS records over-the-air, so end users don't lose state after the upgrade. Survive the transition with the smallest possible window where a power loss could brick the device. NCS-side preparation Build the NCS firmware for the target SoC (nRF52832 / nRF52833) and confirm it fits flash and RAM. Use an MCUboot + firmware_loader + application layout (MCUboot in firmware-updater mode). Place the legacy FDS region at exactly its original absolute address in the static

Hi I'm working on a new project using the nRF9151 SMA DK and I have some questions that I haven't been able to answer by searching this forum or reading through the documentation. 1. The hardware guide says the board should be powered from either USB or the VIN pin (pin 9 on P20). However it would be advantageous for my project if I could instead create a shield during prototyping that supplies 5v via pin 5 of P1. SB35 (closed by default) connects the P1/P3/P7 5V pins to VDD_5V, so electrically they appear to be the same net as VIN_5V on P20. Is this a supported way to power the DK, or are there caveats I should be aware of (e.g. the power switch SW6, power-input selection FETs, etc.)? 2. The guide says only one source should be applied at a time but doesn't say why. My assumption is