Issues with I2C/GPIO 2 and 3

February 14, 2024, 08:40

sibert_20079

I'm having issues with I2C-1 on a Pi 4 model B. The pins stay high, no matter what I do (verified using a logic analyser). I know about the pull-ups, so it makes sense that they are high on boot. I've tried following: - Switched to a different PI (same model) - Tried a different PSU - Disconnected everything from the GPIO header - Used pinctrl to set GPIO2 and GPIO3 manually. They stay high - Other GPIO's do work as expected - Reflashed SD card with clean raspbian Anyone any idea what to try next? I'm out of ideas

sibert_20079

I2C-1 is enabled

oops.se

As with raspi-config?

sibert_20079

Yes

sibert_20079

Verified in /boot/config.txt and using lsmod

oops.se

When you state something, please add the "command" or the output.

oops.se

sibert_20079

pi@pucktestbench:~ $ lsmod | grep i2c i2c_dev 20480 0 i2c_brcmstb 16384 0 i2c_bcm2835 20480 0

sibert_20079

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Additional overlays and parameters are documented
# /boot/firmware/overlays/README

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]

sibert_20079

contents of config.txt

sibert_20079

This one I do not understand:

pi@pucktestbench:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77

On the other PI the result is -- for each address (both nothing connected)

sibert_20079

Attempts to manually drive GPIO 2 low:

pi@pucktestbench:~ $ pinctrl set 2 op
pi@pucktestbench:~ $ pinctrl set 2 dl

sibert_20079

What strikes me as odd as well:

pi@pucktestbench:~ $ pinctrl set 2 dh
pi@pucktestbench:~ $ pinctrl get 2
 2: op -- pu | lo // SDA1/GPIO2 = output

When driving high, pinctrl reports the pin as low but my logic analyser measures high on that pin

sibert_20079

Ah fuck me a third pi does work. What are the chances of two hardware failures -_-

oops.se

If you have a i2c device connected it will show up

oops.se

Looking at https://www.nxp.com/docs/en/user-guide/UM10204.pdf you see that it should be high until pulled down. So I wonder why do you think it shouldn't?

oops.se

And I uses the gpio family of commands (gpiodetect gpiofind gpioget gpioinfo gpiomon gpioset) and mine i2c is also high.

oops.se

Output from gpioinfo

gpiochip0 - 58 lines:
        line   0:     "ID_SDA"       unused   input  active-high
        line   1:     "ID_SCL"       unused   input  active-high
        line   2:       "SDA1"       unused   input  active-high
        line   3:       "SCL1"       unused   input  active-high

sibert_20079

Nothing was connected, so nothing can show up

sibert_20079

Not sure what you mean here. My issue was that it didn't go to ground even when driving the pin low

oops.se

And you had a i2c device connected when analyzing?

sibert_20079

I tried both