I2C on i2c2 (the Arduino header, arduino_i2c, P0.30 SDA / P0.31 SCL) is completely non-functional on two separate, brand-new nRF9151 DK (PCA10171) units. A raw bus scan finds zero devices at any address, regardless of what is connected, including nothing at all.
We have isolated this to SCL sitting at a hard 0 V at the header even with the SoC's internal pull-up enabled, while SDA in the same pinctrl group correctly reads 3.3 V.
Looking for a sanity check before concluding this is a hardware problem with the Arduino header on this batch or revision.
Environment
- DK: nRF9151 DK, PCA10171. Two separate units, both fresh out of the box.
- SDK: nRF Connect SDK v3.3.0, Zephyr ncs-v3.3.0 (v4.3.99-fd9204a02d52)
- Board target:
nrf9151dk/nrf9151/ns - Toolchain: nRF Util sdk-manager, NCS v3.3.0 toolchain
Hardware setup
i2c2 is aliased to arduino_i2c in the stock board devicetree. Pin mapping confirmed from nrf9151dk_nrf9151_common-pinctrl.dtsi: TWIM_SDA to P0.30, TWIM_SCL to P0.31. This SDK version's board.yml has no revision variants, so this is the only mapping in the tree.
Sensors are on breakout boards connected over Qwiic-style cabling into the Arduino header:
| Device | Compatible | Address | Kconfig |
|---|---|---|---|
| LPS28DFW barometer | st,lps28dfw |
0x5C | CONFIG_LPS2XDF |
| LSM6DSOX IMU | st,lsm6dso |
0x6A | CONFIG_LSM6DSO |
| MAX30101 PPG | maxim,max30101 |
0x57 | CONFIG_MAX30101 |
All are in-tree Zephyr drivers, all status = "okay" under &arduino_i2c in a board overlay. A known-good SSD1306-class OLED module (0x3C/0x3D) was also tried on the same chain.
For context: these same breakouts and Qwiic cables previously worked on a different Nordic DK model. That has not been re-verified against this exact firmware build.
What we tried, in order
1. Baseline boot. All three sensor drivers fail to initialize:
<err> LPS2XDF: lps28dfw@5c: Not able to read dev id
<inf> LSM6DSO: Initialize device lsm6dsox@6a
<err> LSM6DSO: Failed to set user bank
<err> LSM6DSO: failed to initialize chip
<err> MAX30101: Could not get Part ID2. Controller check. device list over the shell confirms the i2c@a000 (i2c2) controller itself is active, but all three sensor devices show (DISABLED).
3. Single-sensor isolation. Removed everything except the barometer. Identical Not able to read dev id error.
4. Swapped SDA/SCL at the sensor end. No change, identical error.
5. Raw bus scan. Enabled CONFIG_I2C_SHELL to scan independently of any driver init sequence. i2c scan i2c2 across the full range (0x00 to 0x77) reports 0 devices found: with the barometer alone, with the OLED connected, and with nothing connected at all. Same result every time. The scans also take far longer than expected, with each address appearing to time out rather than returning a fast NACK, which seems like a symptom in itself.
6. Enabled internal pull-ups. Added bias-pull-up; to the i2c2_default / i2c2_sleep pinctrl groups in a board overlay, following the pattern used in nrf/samples/shields/npm2100_ek and npm13xx_ek for other boards. The stock i2c2_default pinctrl sets no bias-pull-up, and we found no evidence of pull-up resistors on the bare Arduino header. Rebuilt and reflashed. Still 0 devices found.
7. Multimeter at the header. DK powered, nothing connected, bias-pull-up build flashed:
- SDA (P0.30): 3.3 V, correctly pulled high
- SCL (P0.31): 0 V, flat, despite identical pull-up configuration on both pins in the same pinctrl group
8. Resistance check, SCL (P0.31) to GND, DK powered off. Started around 37 MΩ and drifted slowly down toward 10 MΩ, still decreasing when we stopped watching. That reads as capacitive settling rather than a hard short, which would normally drop to a low value within seconds.
9. Repeated on a second, brand-new PCA10171 unit. Same firmware build, same Qwiic-connected sensors. Identical result: 0 devices found on a full bus scan. We have not yet re-run the SDA/SCL voltage measurement on this second unit.
Where we're stuck
Two independent, freshly unboxed DK units producing an identical failure argues against a one-off defective unit. But we also cannot find anything wrong in the devicetree, pinctrl, or Kconfig: the pin mapping matches the shipped board files, the sensors and wiring have worked with the same parts on a different Nordic DK, and enabling internal pull-ups made no measurable difference.
Questions
- Is it expected that the nRF9151 DK's Arduino/Qwiic header (i2c2, P0.30/P0.31) has no pull-up resistors and no
bias-pull-upin the default pinctrl? Put differently, is external pull-up hardware required for any I2C use of this header, unlike some other Nordic DK models? - Is there a known issue, solder bridge, or jumper setting on PCA10171 relevant to powering or enabling the Arduino header's I2C lines that the default board configuration does not handle?
- Does a 0 V SCL with
bias-pull-upenabled, while SDA in the same pinctrl group reads 3.3 V, point to anything specific such as a known erratum, a VDD_GPIO sequencing issue, or something else worth ruling out before we assume both DK units have a hardware fault?
Happy to attach full boot logs, devicetree_generated.h or pinctrl dumps, or run any other test that would help.