Unable to communicate with I2C fuel gauge - Page 1
Forum section: electronics / projects

author: davegravy
author_rank: Regular Contributor
timestamp: May 04, 2024, 07:38:25 pm
content: I'm trying to communicate with an LTC2959 (datasheet) battery fuel gauge via I2C from my linux-based SBC. I'm not succeeding and I suspect a hardware or device-tree issue.The IC address is 0xC6 which is outside of the standard 0x03 to 0x77 address range but I understand I should be able to bit shift it to 0x63 and access via linux.My SBC has two onboard I2C devices, and EEPROM (datasheet) and PMIC, which I can communicate with so I'm confident the bus and the OS's interface to it is healthy. The IC datasheet saysQuoteIt's not clear to me that this is compatible with how the interface is configured in linux.The device tree source configures the SCL line as "open drain", but not the SDA line and in the pinctrl definition there is `bias-disable` not `bias-pullup`, like there is for other GPIO.Excerpt from the devicetree source (.dts) that the SBC manufacturer provides:Code:/ {//snipahb {apb {flx4: flexcom@fc018000 {atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;status = "okay";i2c@600 {dmas = <0>, <0>;pinctrl-names = "default";pinctrl-0 = <&pinctrl_flx4_i2c>;sda-gpios = <&pioA PIN_PC28 GPIO_ACTIVE_HIGH>;scl-gpios = <&pioA PIN_PC29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;i2c-analog-filter;i2c-digital-filter;i2c-digital-filter-width-ns = <35>;status = "okay";eeprom: eeprom@50 {compatible = "microchip,24c32", "atmel,24c32";reg = <0x50>;read-only;pagesize = <32>;status = "okay";};pmic: pmic@5b {compatible = "active-semi,act8945a";reg = <0x5b>;status = "okay";regulators {//snip};};};};//snippioA: pinctrl@fc038000 {//snippinctrl_flx4_i2c: flx4_i2c {pinmux = <PIN_PC28__FLEXCOM4_IO0>, //SDA<PIN_PC29__FLEXCOM4_IO1>; //SCLbias-disable;};};};};};That said, the EEPROM chip seems to have the same requirement for external pullup on SDA, and is operating fine.What am I missing?

author: moffy
author_rank: Super Contributor
timestamp: May 04, 2024, 11:49:50 pm
content: It is easy enough to modify the pin definition of the SDA pin to give that a try but if the bus is already working with two other devices it is unlikely that is a problem. Yes the I2C bus needs normally resistor pullups on both the SDA and SCL lines and is driven by open collector devices. If you don't have a serial logic analyser it can get a little difficult, is there any way to check that your address shifting is working?

author: selcuk
author_rank: Frequent Contributor
timestamp: May 05, 2024, 10:50:41 am
content: I haven't used that IC before but it will be helpful if you share the DTS file you use for defining the LTC2959. Someone experienced can see if there is a wrong parameter.

author: davegravy
author_rank: Regular Contributor
timestamp: May 05, 2024, 01:10:07 pm
content: Quote from: moffy on May 04, 2024, 11:49:50 pmI don't have a LA but I decided I'm going to buy one. Will post once I have results.Quote from: selcuk on May 05, 2024, 10:50:41 amI'm confused. I see that the eeprom and pmic have definitions in the DTS but isn't that because they have a Linux device driver associated with them?To be clear, in my case, I plan to communicate directly to the fuel gauge via python using the python-smbus or mpio packages, accessing whatever specific register addresses I need. I thought the existing DTS is sufficient for this since the high level interface is defined (i2c@600). Is this wrong?

author: Perkele
author_rank: Regular Contributor
timestamp: May 05, 2024, 01:42:03 pm
content: Check if you have i2c-tools installed on that box, and try to read any register that you know it will return an expected value at that moment.That tool saved my day many times.

author: selcuk
author_rank: Frequent Contributor
timestamp: May 05, 2024, 02:58:20 pm
content: Quote from: davegravy on May 05, 2024, 01:10:07 pmYes, they have device drivers and kernel is using them. I believe you are going to use user space I2C driver then. You may use the suggested i2ctools package. User space access details are here:https://www.kernel.org/doc/html/latest/i2c/dev-interface.htmlNormally you see that eeprom in the sys file system like this (I copied from one of the hardware I use, address is 50):/sys/bus/i2c/devices/0-0050/eepromBut you may not find LTC2959 there without a DTS definition. So look under this directory for i2c bus list:/sys/class/i2c-dev/

author: davegravy
author_rank: Regular Contributor
timestamp: May 05, 2024, 05:10:52 pm
content: Quotei2cdetect reports nothing other than 50 and 5b (the eeprom and pmic)QuoteNothing from the bit-shifted 0xC6 address.I guess I need to inspect the SCL and SDA lines to get more info. Connections are via short dupont cable but I've used these before without issue for I2C.

author: davegravy
author_rank: Regular Contributor
timestamp: May 05, 2024, 05:43:42 pm
content: In case there's some silly design mistake, this is my prototype/eval board for the ltc2959.SCL, SDA, go direct to the SBC.J1_pin3 (GND) goes to the SBC GND and -ive on bench supplyJ1_pin2 goes to my bench supply +5VJ1_pin1 goes to SBC 5V supply input.Vreg measures 2.2V relative to GND.R1 is 10mohm, current through R1 is ~100mA.Confirmed D1 through D3 are soldered in correct orientation.

author: Perkele
author_rank: Regular Contributor
timestamp: May 05, 2024, 08:29:13 pm
content: OK, to rule out other issues, is the device on the same bus as those two devices that you're seeing on the scan?

author: selcuk
author_rank: Frequent Contributor
timestamp: May 05, 2024, 08:40:41 pm
content: J1 pin order is wrong on your post, isn't it? Can you try after removing D1 and D2?

author: davegravy
author_rank: Regular Contributor
timestamp: May 05, 2024, 09:29:15 pm
content: Quote from: selcuk on May 05, 2024, 08:40:41 pmThanks, edited/fixed my previous post.I'll try without the diodes.

author: davegravy
author_rank: Regular Contributor
timestamp: May 05, 2024, 09:30:58 pm
content: Quote from: Perkele on May 05, 2024, 08:29:13 pmThere's only one I2C bus shown in linux and mentioned in the SBC datasheet (link), the same one the physical pins map to, but it'll be interesting once I get my LA if I can see the eeprom and pmic traffic on those pins.

author: moffy
author_rank: Super Contributor
timestamp: May 05, 2024, 11:34:49 pm
content: Quote from: davegravy on May 05, 2024, 05:10:52 pmCould you try your bit shifting technique on a device that you know is there e.g. the EEPROM to see if that works?P.S. Are you able to set the signaling rate to 100kHz or lower, sometimes a lower clock will fix some devices.

author: moffy
author_rank: Super Contributor
timestamp: May 06, 2024, 12:00:00 am
content: This might be of interest:https://www.i2c-bus.org/addressing/10-bit-addressing/It looks like the addressing is a little more complicated.The above link probably doesn't apply but this should:https://forums.raspberrypi.com/viewtopic.php?t=86683

author: davegravy
author_rank: Regular Contributor
timestamp: May 06, 2024, 02:07:29 am
content: I picked up a LA this afternoon and here is the result from i2cdumpThat appears to be the correct address pattern (1100011) from the datasheet, but no ACK received. SCL frequency is 100kHz.Is this a problem of logic level? The SBC is outputting 1.8V logic, the datasheet shows Logic Input Threshold (V_ITH) as between 0.5 and 1.4V.I'm a bit stumped.

author: moffy
author_rank: Super Contributor
timestamp: May 06, 2024, 03:06:46 am
content: The data looks correct except there is no ACK from the chip. Just one weird thing, you measure Vreg as 2.2V but with a 1.8V minimum VDD one would expect it to be lower, unless it is doing some internal charge pumping, which is possible, unfortunately I cannot see that the datasheet mentions the voltage anywhere. If you can raise the I2C pullup voltage to above 1.8V safely, say 2.5V without damaging anything you could try, but maybe like that previous link, a grounding issue? You kinda need a scope now to check the actual waveforms.