PCB Heaven

General Category => Digital discussion => Topic started by: cheerio on January 25, 2013, 16:26:34 PM

Title: TI bq34z100 i2c communication
Post by: cheerio on January 25, 2013, 16:26:34 PM
TI bq34z100: http://www.ti.com/lit/ds/symlink/bq34z100.pdf (http://www.ti.com/lit/ds/symlink/bq34z100.pdf)

Hi i try to communicate with the chip via i2c. But it just won't work. Maybe you can help me.
This is my setup:
-schematic for the chip connections is attached
-i use the bus-pirate v3.6 to communicate with the chip
-VCC = 4.2V
-100khz i2c clock

To check the communication i try to read out the chips name. This is register 0x63, 0x64, 0x65, 0x66, 0x67, 0x68 , 0x69, 0x6A [check page 38 (bottom)] and and should be bq34z100 [check page 40(mid)].

The communication sequence is shown on page 28.

I am pretty rusty on i2c so maybe i messed smth up but this is what i try to read the device name.

Start Bit, 0xAA, 0x63, Start Bit, 0xAB, read byte, ACK, read byte, ACK, read byte, ACK, read byte, ACK, read byte, ACK, read byte, ACK, read byte, ACK, read byte, NACK, Stop Bit

Is this alright? This is d) incremental read on page 28.

The Bus-Pirate Syntax is:
[ = Start bit
0x?? = send 0x??
r:8 = read 8 bytes, ACK the first 7 and NACK the last byte
] = Stop bit

Here is what happens when i do this (sometimes a) happens and sometimes b) happens):
a)
I2C>[ 0xaa 0x63 [ 0xab r:8 ]
I2C START BIT
WRITE: 0xAA NACK
WRITE: 0x63 NACK
I2C START BIT
WRITE: 0xAB NACK
READ: 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF
NACK
I2C STOP BIT

b)
I2C>[ 0xaa 0x63 [ 0xab r:8 ]
I2C START BIT
WRITE: 0xAA ACK
WRITE: 0x63 NACK
Warning: *Short or no pull-up
I2C START BIT
WRITE: 0xAB NACK
READ: 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF
NACK
I2C STOP BIT

The chip does not ACK when it should do so, this is giving me a hard time.
Can you point out any mistake i do?
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 25, 2013, 16:54:32 PM
This are the logic analyzer logs for a) and b)
Title: Re: TI bq34z100 i2c communication
Post by: kam on January 26, 2013, 10:05:26 AM
if i'm not mistaken, shouldn't the address be 0xab for read???
And what is this chip used for?
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 26, 2013, 13:49:47 PM
yes kam 0xAB is for read. But first i have to write the address i ant to read to the chip using 0xAA. read page 28 of the datasheet carefully.
The chip is used to determine the state of charge of a battery with pretty insane precision
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 26, 2013, 20:34:11 PM
i added a cap (330nF) between REG25 and GND.
Now i got the chip talking....

what i do to read the chipname is this:
[0xAA 0x63]
[0xAB r]
[0xAB r]
[0xAB r]
[0xAB r]
[0xAB r]
[0xAB r]
[0xAB r]
[0xAB r]


the incremental read like it was shown in the datasheet won't work yet. i think i experiment more into that. timing issues maybe
Title: Re: TI bq34z100 i2c communication
Post by: kam on January 26, 2013, 20:47:20 PM
The chip is used to determine the state of charge of a battery with pretty insane precision
Like, how much capacity is left? The remaining lifespan of the battery??? Something like this?
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 26, 2013, 21:20:44 PM
AFAIK the chip won't tell you that but it does use this data for it's prediction. The chip uses the open circuit and load voltage(impedance tracking), counts the current that has already been used, and it also compensates battery aging in it's calculations. It can predict the state of charge (remaining battery capacity) with a 1% precision.
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 27, 2013, 16:56:13 PM
it looks like i have misunderstood the incremental read. it works like this:
%:x = x ms delay
Increment read:
[0xAA REGADDR %:1600 [0xAB r [0xAB r ... [0xAB r]

you can also do it like that:
[0xAA REGADDR]
%:1600
[0xAB r]
...
[0xAB r]
 
for some reason i have to wait 1.6s after a write command. i really don't know whats going wrong here.

Title: Re: TI bq34z100 i2c communication
Post by: kam on January 27, 2013, 17:42:46 PM
AFAIK the chip won't tell you that but it does use this data for it's prediction. The chip uses the open circuit and load voltage(impedance tracking), counts the current that has already been used, and it also compensates battery aging in it's calculations. It can predict the state of charge (remaining battery capacity) with a 1% precision.

tomorrow i order some samples for myself.... Amazing chip
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 27, 2013, 18:53:47 PM
cool. maybe you can tell me how the flash write works when you got it. I really struggle with writing stuff to the chips data flash
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on March 12, 2013, 19:37:59 PM
did you have some time to investigate this chip? in about 1 month i want to continue with the project i need the chip for and help would be really appreciated.
Title: Re: TI bq34z100 i2c communication
Post by: kam on March 13, 2013, 00:01:02 AM
no not really. I'm starting a new business right now and i hardly have any time to spend for the site.
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on March 13, 2013, 01:24:51 AM
ok. i wish you good luck!
Title: Re: TI bq34z100 i2c communication
Post by: kam on March 14, 2013, 07:51:53 AM
Danke sehr! ;)
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on August 09, 2013, 01:12:26 AM
i put some time into this chip today and managed to get most of the communication working. to speed up the testing of the chip i attached it to an arduino. when i got alle the stuff working i post the arduino code so you can check out how the communication works exactly. but don't expect much of explanation in the code or a clean code ^^
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on August 10, 2013, 02:55:01 AM
here is a arduino project that let's you execute all the standard, control and extended commands. i commented out a few commands so you cannot mess with the chip by accident. just uncomment the commands in "void run(unsigned int i)" located in shell.ino.

if you run the project you get a shell where you can execute commands. you get the read values as feedback.
? - lists all commands
man command - gives you a short description of the command and tells you the page of the datasheet where you can get more information.

the code is not very clean. you need >22kb space. i ran it on an atmega328p


i did not implement the data flash read/write interface. i did not implement the write interface as well.
if you want it, you can code it.
Title: Re: TI bq34z100 i2c communication
Post by: kam on August 11, 2013, 00:53:14 AM
One day i have to dust off this arduino of mine....   ::) ::) ::)
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on August 11, 2013, 12:43:01 PM
For quick and dirty setups it is best. For final products it sucks.
I ordered the ti ev2400 so i can iterface the ti chips using their software. Maybe i can make a clone of it so you can benefit of it too.
Title: Re: TI bq34z100 i2c communication
Post by: momosh13 on November 24, 2013, 03:46:34 AM
Hello.
Thank you for this posting. I'm using your files in this post, and i'm receiving this respond form the bq34z100,

Shell start
-> VOLT
 > Voltage
328
-> TEMP
 > Temperature
3002
-> FW_VERSION
 > FW Version
0x6
-> CURRENT
 > Current
0
-> CURRENT
> Current
64116
->

So the voltage on my voltmeter is 7.8v,here i'm receing 328,
there is any way you can tell me, what I can do to receive the actual value (7.8v),
and the Temperature is 21C / 70F
i'm using bq34z100EVM module for my test,
Thank you.
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on November 24, 2013, 14:36:22 PM
it's been a while since i did this. i check it out soon
Title: Re: TI bq34z100 i2c communication
Post by: momosh13 on November 26, 2013, 05:24:05 AM
Thank you, for your help...
Title: Re: TI bq34z100 i2c communication
Post by: momosh13 on December 10, 2013, 20:22:03 PM
Hello.
Just want to let you know,what i receive from TI, about this problem

You should check your calibration. The voltage will read out in hex and will be in milli-volts after converting to decimal. Don't forget to swapped the bytes that are read out. e.g. If you read B61C for voltage, then you will convert 1CB6 to decimal. (7350mV) Temperature will read out in hex and will be in 0.1 degK after converting to decimal. The byte swap applies here as well.

Tom

Thanks again.
Title: Re: TI bq34z100 i2c communication
Post by: kam on December 10, 2013, 21:14:29 PM
and? you test it?
Title: Re: TI bq34z100 i2c communication
Post by: momosh13 on December 10, 2013, 22:08:50 PM
I'm going to test it today,and the results, i'll post it asap.
Thanks
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on December 12, 2013, 17:17:51 PM
ok. i can check it this weekend if i need to. had a lot to do the last weeks
Title: Re: TI bq34z100 i2c communication
Post by: klnz on January 19, 2015, 10:46:30 AM
Hi All,
Because the code posted by cheerio has been - by far - the most helpful tool to understand comms with the BQ34z110, I'd like to revive this thread.

I have very little reference data to figure out whether I'm going in the right direction. I'm using comparisons to default values for CHEM_ID (0x800), DEVICE_TYPE (0x110) gleaned from other's posts in TI's E2E forum, and Temperature() from the external NTC (actual temperature in my room) to figure out how to communicate and decode.
Also, I'm using a PIC18, BusPirate, and arduino for I2C comms (i.e. not TI's EVS boards), and a logic analyzer to observe byte and bit orders and decode bytes sent and received.

The fog is slowly lifting, but I'd be grateful if someone could confirm my conclusions (or suspicions?) thus far:
1) For Control commands, the order in cheerio's code seems to be AA+CNTL_LO_BYTE+CNTL_HI_BYTE, followed by AA+0x01+0x01, then AA+0x00 (set the pointer to the LO register?), then AB (read). The BQ responds with LO_BYTE then HI_BYTE. For CHEM_ID (0x0008), this means AA+00+08, AA+01+00, AA+00, AB, response 0x00 (LO) then 0x08 (HI). Left-shifting the HI byte (0x08) by 8 bits and adding the LO byte (0x00) gives a 16-bit word 0000100 00000000 with a value matching the default CHEM_ID of of 0x800.
While this matches the expected default value (and also works for CHEM_ID), we're sending sub-command first, then Control(). This is inverse to the order described in the datasheet (p9): "Issuing a Control() command requires a subsequent two-byte sub-command". The data sheet doesn't seem to erroneous (the order Control() then sub-command (0x00+0x01 then 0x00+0x08 also returns 0x800!).  Please note that I'm not complaining about the code (I love it!), I'm simply confused: why do both ways work? I'm also concerned that I may be badly mis-understanding things ...

2) cheerio's code to retrieve TEMP (a simple and ingenious
Code: [Select]
tx1(0x0d0c);) produces a word (0xD0C), but  only 0xAA+ACK, 0x0C+ACK, and 0xAB+ACK are sent over I2C. The HI byte of the word never appears on the pins. Surprisingly, the BQ responds with the expected temperature value! (LO byte first). Is this because the arduino's wire library (and the other 8-bit MCU's I"m using) can't cope with a 16-bit word and send only the LO byte? And how is this understood correctly by the BQ34z110?

3) Is the order of bytes returned consistently LO byte first, as for Temperature()?

4) Are the bytes coming from the BQ34 consistently MSBit first, as in the (testable) cases CHEM_ID, DEVICE_TYPE, and Temperature?

Sorry for these basic questions, it's hard to figure out reliably with limited reference data.

Many thanks in advance for all replies!
K
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 22, 2015, 20:00:26 PM
Quote
1) For Control commands, the order in cheerio's code seems to be AA+CNTL_LO_BYTE+CNTL_HI_BYTE, followed by AA+0x01+0x01, then AA+0x00 (set the pointer to the LO register?), then AB (read). The BQ responds with LO_BYTE then HI_BYTE. For CHEM_ID (0x0008), this means AA+00+08, AA+01+00, AA+00, AB, response 0x00 (LO) then 0x08 (HI). Left-shifting the HI byte (0x08) by 8 bits and adding the LO byte (0x00) gives a 16-bit word 0000100 00000000 with a value matching the default CHEM_ID of of 0x800.
While this matches the expected default value (and also works for CHEM_ID), we're sending sub-command first, then Control(). This is inverse to the order described in the datasheet (p9): "Issuing a Control() command requires a subsequent two-byte sub-command". The data sheet doesn't seem to erroneous (the order Control() then sub-command (0x00+0x01 then 0x00+0x08 also returns 0x800!).  Please note that I'm not complaining about the code (I love it!), I'm simply confused: why do both ways work? I'm also concerned that I may be badly mis-understanding things ...
I am not sure about this one. I add some snapshots of the communication where you can figure out how it should be done. Just stick to it then.
Quote
2) cheerio's code to retrieve TEMP (a simple and ingenious
Code: [Select]
tx1(0x0d0c);
) produces a word (0xD0C), but  only 0xAA+ACK, 0x0C+ACK, and 0xAB+ACK are sent over I2C. The HI byte of the word never appears on the pins. Surprisingly, the BQ responds with the expected temperature value! (LO byte first). Is this because the arduino's wire library (and the other 8-bit MCU's I"m using) can't cope with a 16-bit word and send only the LO byte? And how is this understood correctly by the BQ34z110?
The chip does auto increment of the address. So you just need to send 0x0C and read 2 Bytes. This way you read the value at address 0x0C first and then the value at address 0x0D (0x0C + 1).
You can also use the extended command 0x2a/0x2b for retrieving the temperature. Auto increment works here the same way.

Quote
3) Is the order of bytes returned consistently LO byte first, as for Temperature()?
As far as i know it is. But don't take my word! You should check the order of all values first before you use it in your code. Just a precaution.

Quote
4) Are the bytes coming from the BQ34 consistently MSBit first, as in the (testable) cases CHEM_ID, DEVICE_TYPE, and Temperature?
They always did for me. I would be stunned if this order changes for any command.

I attach a .rar File with a lot of screen captures. They show you the i2c communication for temperature readings, data flash readings (with values and read order).
Use the communication examples together with the datasheet and you will hit another milestone ;) i promise

edit:
the data flash read communication was not fully captured. But it is repeated the same way for every sub-class.  So there was no need to recapture anything.
Title: Re: TI bq34z100 i2c communication
Post by: klnz on January 23, 2015, 11:26:25 AM
Many thanks cheerio, this will help greatly!

Things look positive, there are no problems or oddities at the moment, and the code returns 'real' readings for instant current and voltage now. I can finally hook it up to a real battery, so will build a rig with a few safety and measurement features. I haven't attempted reading or writing Flash data because I don't expect to need it in normal use, and currently plan to use an EV2300 for calibration.

Re point2 in my my previous posting, I understand the BQ chip's auto-increment when replying. What I didn't understand was why the arduino sent only the LO byte of the 16-bit word. But digging in the wire library a bit suggests that I should have expected this. It has nothing to do with the BQ chip, so I won't let it distract me.

I'm off sailing tomorrow, mustn't forget why I'm building this ;-)

Thanks again!
K
Title: Re: TI bq34z100 i2c communication
Post by: cheerio on January 23, 2015, 21:56:53 PM
if i recall right you need the data flash for calibration. if you use the ev2300 you can just use this and the bq eval software to calibrate it