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 says
The LTC2959 uses an I2C/SMBus-compatible 2-wire interface supporting multiple devices on a single bus. Connected devices can only pull the bus lines low and must never drive the bus high. The bus wires are externally connected to a positive supply via current sources or pull-up resistors
It'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:
/ {
//snip
ahb {
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
};
};
};
};
//snip
pioA: pinctrl@fc038000 {
//snip
pinctrl_flx4_i2c: flx4_i2c {
pinmux = <PIN_PC28__FLEXCOM4_IO0>, //SDA
<PIN_PC29__FLEXCOM4_IO1>; //SCL
bias-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?
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?
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.
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?
I don't have a LA but I decided I'm going to buy one. Will post once I have results.
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.
I'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?
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.
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?
Yes, 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/eeprom
But you may not find LTC2959 there without a DTS definition. So look under this directory for i2c bus list:
/sys/class/i2c-dev/
root@kstr-sama5d27:/dev# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
i2cdetect reports nothing other than 50 and 5b (the eeprom and pmic)
root@kstr-sama5d27:/dev# i2cdump -y 0 0x63
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
Nothing 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.
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 supply
J1_pin2 goes to my bench supply +5V
J1_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.
OK, to rule out other issues, is the device on the same bus as those two devices that you're seeing on the scan?
J1 pin order is wrong on your post, isn't it? Can you try after removing D1 and D2?
J1 pin order is wrong on your post, isn't it? Can you try after removing D1 and D2?
Thanks, edited/fixed my previous post.
I'll try without the diodes.
OK, to rule out other issues, is the device on the same bus as those two devices that you're seeing on the scan?
There'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.
root@kstr-sama5d27:/dev# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
i2cdetect reports nothing other than 50 and 5b (the eeprom and pmic)
root@kstr-sama5d27:/dev# i2cdump -y 0 0x63
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
Nothing 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.
Could 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.
I picked up a LA this afternoon and here is the result from i2cdump
That 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.
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.