i2cdetecy -y 1 Shows All Possible Addresses When Using QWIIC

Hello! I’m using a Sparkfun QWIIC [HAT, [relay and [temperature sensor on my Raspberry Pi 4.

When first connected, ```
i2cdetect -y 1


![02.PNG|683x279](upload://5GGFmGeCj6K5lu7AtRrZzTly60r.png)

However, at random intervals, the I2C devices stop working, and ```
i2cdetect -y 1
``` shows all addresses as follows:

![01.PNG|671x282](upload://v7qkZCkNCVXqPMIrBLjzQg7AJqq.png)

We use the [[CircuitPython STTS22H](https://circuitpython-stts22h.readthedocs.io/en/latest/) library and [[QWIIC relay library](https://github.com/sparkfun/Qwiic_Relay_Py) to access the sensor and relay.

What I've tried:
<LIST>
<LI>- Replaced the HAT, relay, temp sensor and the Pi 4 with a new device.</LI>
<LI>- Ensured that the HAT is oriented correctly on the Pi.</LI>
<LI>- Made sure nothing is trying to accidentally write to the I2C pins.</LI>
<LI>- Made a new SD card with only the latest Raspbian and nothing else installed</LI>
<LI>- Deactivated and reactivated I2C on the Pi via sudo raspi-config</LI>
<LI>- I've read the existing threads [[here](https://forums.raspberrypi.com/viewtopic.php?t=93222), [[here](https://raspberrypi.stackexchange.com/questions/32719/i2cdetect-shows-every-possible-address), and [[here](https://raspberrypi.stackexchange.com/questions/43224/i2cdetect-shows-all-possible-adresses), but those didn't help me with the issue</LI>
<LI>- Unplugging and replugging one of the I2C devices resolves the problem, but only for a short while. The problem reappears after a few hours.</LI>
<LI>- I asked ChatGPT but it only gave vague answers.</LI>
</LIST>

Having only the temperature sensor connected directly to the I2C pins on the GPIO seems to work fine. So there's either an issue with the QWIIC HAT or the QWIIC relay.

I'm really at a loss here. Any suggestions/ideas what might cause this behavior?

Best,

West](https://raspberrypi.stackexchange.com/questions/43224/i2cdetect-shows-all-possible-adresses)](https://raspberrypi.stackexchange.com/questions/32719/i2cdetect-shows-every-possible-address)](https://forums.raspberrypi.com/viewtopic.php?t=93222)](https://github.com/sparkfun/Qwiic_Relay_Py)](https://circuitpython-stts22h.readthedocs.io/en/latest/)](https://www.sparkfun.com/products/21262)](https://www.sparkfun.com/products/15093)](https://www.sparkfun.com/products/14459)

It sounds like a problem with the pull-up resistance; disable the pull-ups resistors on one of the boards (backside of sensor, or front side of relay) - you just cut the traces between the jumper pads on the PCB

Leave one set of pull-ups active and re-try, any luck?

Thanks TS-Russell. I’ve been able to use the temp sensor and relay directly connected to the Pi using a QWIIC to female pin cable without issues. Then I reconnected the HAT and so far it’s been working for 2 days without issues. If the problem comes back, I’ll try removing one of the pullups, thanks for the suggestion!

Best

West

We’ve further narrowed down the issue to the Qwiic relay. With the relay connected to the Pi, i2cdetect -y 1 will show all addresses when SDA is pulled to GND, like TS-Russell described. Once the GND connection is removed, however, the I2C bus becomes sluggish, and i2cdetect shows each address one by one, with about a 1 second break in between.

This seems like abnormal behavior. When I do the same with a QWIIC temp sensor, for example, the bus returns to its normal state after once SDA is no longer connected to GND.

I know that the relay uses its own [firmware. Is it possible that there’s a firmware issue that causes this kind of behavior?

We’d really like to use this relay, but if it freezes up the I2C bus then it’s really not usable.

PS: Removing the pull-up on one of the I2C devices did not resolve this issue.](https://cdn.sparkfun.com/assets/1/2/d/4/b/Qwiic_Relay_Firmware.zip?_gl=1*fvwv74*_ga*OTc2ODUzNDQuMTY5MDc0MTEzMQ_ga_T369JS7J9NMTcwOTA2NzM1Ni40Mi4xLjE3MDkwNzA2NTEuNTIuMC4w)

I’m seeing similar behavior. With only a COM-15093 connected to a Pi 4 I2C bus, an address scan reports all addresses from either 0 to 127 or 24 to 127 (apparently depending on some internal state of the 15093). I’ve tried disconnecting I2C pullups on the 15093 and slowing I2C clock to 10KHz. Two separate 15093’s show the same behavior. Other I2C devices work correctly.