I have a Raspberry Pi qwiic pHat (DEV-15945) that I just purchased. I also have a couple of the Qwiic buttons. I’m getting unreliable results when communicating to the buttons. I have a simple set up, single button wired to the pHat. If I do a simple i2cget -y 1 0x6F 0x00 I expect 0x5D, but sometimes I get 0x2E (about 2 out of 10 reads).
I have a scope hooked up to SDA and SDC, plus a logic analyzer (Salea). The scope trace looks ok, it over and undershoots quite a bit, but other than that pretty sharp edges based on my limited knowledge. The logic analyzer has i2c decoder and it also reports invalid returns on the registry read. I have tried another hat (direct SDA/SDC connections) and two different buttons, same issue. Short wire (4") from pHat to button. Any suggestions? Most of the commands make it over fine, ie I can control the LED on the button, etc. But it’s not reliable (gets invalid data on read).
About 8 out of 10 I get 0x5D as expected. And I get the same result with the Twist module, every so often I get erroneous data (bits set/not set for button being pressed, when I don’t even touch it).
Photos attached.
I read in a loop with a 500ms sleep after each read (so reading 2 times per second).
I finally figured it out! The CPU of the Raspberry Pi doesn’t support I2C clock stretching properly (bug in the processor hardware apparently)! Especially when the clock stretch is small and happens at arbitrary points. And that’s exactly what seems to happen with the Qwiic modules from SparkFun (tested both the button and the twist). Fortunately there is a workaround, you have to enable a bit-banging i2c driver in the RPi boot files and then it’s rock solid!
Fix
Add this to the boot config (/boot/firmware/usercfg.txt in Ubuntu):
dtoverlay=i2c-gpio,i2c_gpio_sda=2,i2c_gpio_scl=3
Just note that it will then change the default i2c bus from id 1 to id 7 (I assume it gets re-assigned due to a conflict with the i2c hardware driver).
I’ll have to give this a shot… I actually have been having very little trouble with all but one of my QWIIC devices… I do get the occasional “IO Error”, but I took care of that just by catching the event and re-sending… so far, so good… The only exception is the QWIIC RFID board. I can’t get that thing to work AT ALL on a RPI or on an Arduino. I went so far as to order a second one, and had the same problem, and then actually reflashed it, and started from scratch with a “blink” type program and worked my way back up, and the processor seem to be working, but wont do I2C. I THINK I just figured out why though, but I dont know enough about i2c to know. The default i2C address is set to 0x7D, but from what I’m reading, i2c addresses are supposed to be no larger than 0x77? I see some references to larger bit length addresses, but I’m not knowledgeable enough about i2c to know how they work in conjunction with the 7 bit addresses, and in any case it doesn’t show up on the i2cdetect. If I change the firmware to an arbitrary smaller number, and re-flash, it does show up on the i2cdetect. I will try your soft-bit banging idea, and I Really appreciate that guidance… I’m curious if you know anything about the validity of an address of 7D? Thanks!! Steve
I2C addresses from 0x78 to 0x7F are reserved as are addresses from 0x00 to 0x07 as well. Addresses 0x78 to 0x7B are used for 10-bit I2C addressing. I believe 0x7C-0x7F are unused. So 7D isn’t bad, but ic2detect may not be scanning up to that address. That said, I haven’t tried the Qwiic RFID with Raspi yet, so I don’t know if address 0x7D causes any problems or not, but I have been using it with my Arduino just fine.
THANK YOU! This post solved the issue I was having over at viewtopic.php?f=105&t=54688. One slight improvement is that you can specify the bus number so you don’t have to change it elsewehere. In my /boot/config.txt I have:
# What I had before to force 10 kHz for stability
# dtparam=i2c_arm=on,i2c_arm_baudrate=10000
# Switch to software i2c, works much better! This uses the same bus=1
dtoverlay=i2c-gpio,bus=1,i2c_gpio_sda=2,i2c_gpio_scl=3
