TI bq34z100 i2c communication

[cheerio]

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.

[kam]

One day i have to dust off this arduino of mine....   

[cheerio]

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.

[momosh13]

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.

[cheerio]

it's been a while since i did this. i check it out soon

[momosh13]

Thank you, for your help...

[momosh13]

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.

[kam]

and? you test it?

[momosh13]

I'm going to test it today,and the results, i'll post it asap.
Thanks

[cheerio]

ok. i can check it this weekend if i need to. had a lot to do the last weeks

[klnz]

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

[cheerio]

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.

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.

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.

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.

[klnz]

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

[cheerio]

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