I2C help needed.. ISL94203 returning different values for the same address

[samofab]

Hello,

I'm trying to communicate with ISL94203 battery monitoring device, but the response that I get is gibberish.
The IC acts like an EEPROM, you basicly dummy write the memory address that you're after and then you access it in read mode to get it. If you acknowledge the read, device will continue to send out data (from the next memory address).

The problem is that the replies look random - I tried many different RAM memory address that should contain a very stable data.

I'm currently using STM32, but the result is the same if I use Buspirate.

Here's the device datasheet: http://www.intersil.com/content/dam/Intersil/documents/isl9/isl94203.pdf

I'm attaching the oscilloscope screenshot...

[pa3bca]

You are writing to I2C address 50 (I assume that is the I2C address of the ISL94203), and then reading from address 51?? Why, what's on 51?

[samofab]

Last bit on I2C is R/W bit (at least for 7bit addressing). I first write to 0x50 with memory address, then issue read command with 0x51. In both cases the device returns ACK (otherwise the uC wouldn't move on).

[pa3bca]

Oh.. That is unexpected, I would expect the Rigol to display the real address and indicate the R/W bit with... R and W as displayed. And not make the r/w bit part of the address.

[samofab]

Oh.. That is unexpected, I would expect the Rigol to display the real address and indicate the R/W bit with... R and W as displayed. And not make the r/w bit part of the address.

As a matter of fact, Rigol does that by default.. I set it up so that it displays the raw address.

[electrodacus]

Hello,

I'm trying to communicate with ISL94203 battery monitoring device, but the response that I get is gibberish.
The IC acts like an EEPROM, you basicly dummy write the memory address that you're after and then you access it in read mode to get it. If you acknowledge the read, device will continue to send out data (from the next memory address).

The problem is that the replies look random - I tried many different RAM memory address that should contain a very stable data.

I seen your private message so I came here.
It seems like you try to read the battery voltage (total pack voltage) that is the voltage at pin 48 VBATT pin.
That is a 12bit number with A6 representing the least significant 8bit and A7 most significant 4
Not sure about your hardware so not sure what you will expect at VBATT pin but here is an example from my own SBMS right now.
I see at A6  191 and at A7 7
So 7 x 256 + 191 = 1983 and using the formula in the datasheet  (1983 * 1.8 * 32) / 4095 = 27.89V exactly what I have since I use a 8s LiFePO4 that is currently charging from a solar PV array.
I do not think is anything wrong with your communication and hope this helped.

[samofab]

I found an exact description my problem on Intersil website which let me to correct solution:
https://kb.teamsupport.com/knowledgebase.aspx?organizationid=784358&ArticleID=10357593&TicketType=Ticket
(as a side note, the Intersil website is awful - only working)

When I reduced the length of the wires and powered the uC from RGO voltage, everything started working. Then I started wondering why the Vbatt volatage as calcuated from datasheet formula didn't make any sense.. and electrodacus answered my question before I even asked it: the most siginificant register is the second one, not the first one as I assumed.

ISL94203 now works as expected and it seems happy (no reported errors)

(Now I'm battling MSP430 eUSCI I2C... it seems that absolutely all of the examples on the internet are for USCI which is just slightly different.)

Thanks to everybody, again...