This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: BQ34Z100-G1
Hello,I am using the Bq34z100-G1 battery gauge on a custom design including a TI MSP43053359.I am trying to configure for the first time the gauge using MSP430 I2C, but without success.Here are the steps I follow to configure two values: the design capacity, and the design energy. These entries are found in the sublass with id 48.
When reading the gauge, I expect to get all default values, since I have never configured it before.This is not exactly my results, though, as you will see.First, I enable block data, writing 0x61 and 0x00 to the I2C address.Then, I give the subclass that I target as the block data: wr 0x3E 0x30 (48 <=> 0x30)Then, I give the offset for my entries (here this is 0): wr 0x3F 0x00Then, I read 32 bytes from the block data address (0x40)Here are the 32 bytes I get:0x10 0x00 0x00 0x00 0x01 0x00 0x00 0x03 0x84 0x64 0x03 0xE8 0x15 0x18 0xFE 0x70 0x10 0x68 0x10 0x68 0x10 0x04 0x0A 0x32 0x1E 0x00 0x0A 0x2D 0x37 0x01 0x0B 0x97Here are the expected 32 bytes, according to the documentation of the battery gauge0xXX 0xXX 0x00 0x00 0x00 0x01 0x00 0x00 0x03 0x84 0x64 0x03 0xE8 0x15 0x18 0xFE 0x70 0x10 0x68 0x10 0x68 0x10 0x04 0x0A 0x32 0x1E 0xF6 0x0A 0x2D 0x37 0x01 0x62I notice a shift between expected results and what I get.Anyway, thanks to the easily identifiable default values for design capacity and design energy, I could find their place in the byte stream.So, i update the corresponding values in the byte stream and write them:
Design capacity: bytes_stream = 0xa0; byte_stream = 0x28;
wr (0x40 + 10) 0xa0 0x28
Design energy: bytes_stream = 0x4b; byte_stream = 0x28;
wr (0x40 + 12) 0x4b 0x28
Then I compute the checksum:
0x10 + 0x00 + 0x00 + 0x00 + 0x0I1 + 0x00 + 0x00 + 0x03 + 0x84 + 0x64 + 0x03 + 0xE8 + 0x15 + 0x18 + 0xFE + 0x70 + 0x10 + 0x68 + 0x10 + 0x68 + 0x10 + 0x04 + 0x0A + 0x32 + 0x1E + 0x00 + 0x0A + 0x2D + 0x37 + 0x01 + 0x0B + 0x97 = 0x74
checksum = 0xFF - 0x74 = 0x8b
Then write it:
wr 0x60 0x8b
Then I reset the gauge :
wr 0x00 0x41 0x00
Then wait 300 millis.
But when I read the entries back I get the default values again:
0x10 0x00 0x00 0x00 0x01 0x00 0x00 0x03 0x84 0x64 0x03 0xE8 0x15 0x18 0xFE 0x70 0x10 0x68 0x10 0x68 0x10 0x04 0x0A 0x32 0x1E 0x00 0x0A 0x2D 0x37 0x01 0x0B 0x97
What am I doing wrong ?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to David Hien:
When you write the correct checksum to 0x60 that corresponds to the data you wrote in 0x40-0x5F it will transfer the data to the dataflash block which you previously set up.
The attached spreadsheet can help you to calculate your checksum to check your work above.
One other note is that your voltage must be above the Flash Update OK Voltage setting or else the FW will block flash writes (to prevent possible brownouts). If you use lead-acid, we recommend that you set Flash Update OK Voltage = 1000mV. If you somehow can't write to Flash Update OK Voltage then you can put the gauge in Calibration mode to allow it to ignore the voltage limitation. To do this you would send the CAL_ENABLE (0x002D) subcommand to 0x00/0x01.5516.DataFlash_write.xls
In reply to dMax:
Hi and thanks for your response. Unfortunately it did not help.
I have compared the checksum I compute in my program and the one I get from the attached spreadsheet and found the same. Anyway writing the checksum doesnt 'make the gauge accept my config as I get default values when reading data block again.About the Flash Update Voltage, my voltage is way higher than the configured one.
In reply to user5324968:
In reply to Bryan Kahler:
One other note to make sure you are on the right path:
You will not get good gauging results by simply configuring a handful of dataflash parameters using the block access method you are attempting. The battery profile (aka chemID) needs to also be programmed and those are not in public dataflash locations, so if you try to directly modify a few dataflash settings you will still not have the correct battery profile.
Using a .df.fs file is the recommended way to program/configure the bq34z100-G1 using an MCU. It will contain the entire dataflash image. You use the Golden Image plugin in bqStudio to export a .df.fs file.
Before exporting, however, you need to finalize the settings. Let me run through the high level flow of developing with this gauge:
Use the Data Memory plugin to configure as many dataflash parameters as you need for your starting point.
Then use the Registers tab to log your data while you run a relax, discharge, relax cycle per the instructions in for GPCCHEM from ti.com.
Submit that log with the support files to GPCCHEM and you will be emailed back with a list of recommended chemIDs to choose from which match your battery.
Now use the Chemistry plugin in bqStudio to program the best matched chemID. This will configure some hidden/static parameters.
Now you need to optimize the Qmax and Ra values. There are two ways to do this. The first is to use the GPCRA tool on ti.com (collect more data and upload). Take the values which GPCRA emails you and use the Data Memory plugin to edit them in your gauge.
The second method is to physically run a learning cycle and let the gauge directly learn and update Qmax and Ra.
If you also want to make sure low temp performance is optimized then you can also follow the instructions for GPCRB on ti.com. It will send you a .chem file that is tuned for your cell as well as recommended values for T Rise and T Time Constant dataflash parameters which match your cell self-heating in the thermal environment in which you collected data.
You should probably do some testing to validate all of the settings and optimization are giving you acceptable results at this point.
Once you are satisfied with the tuning then you can export the .df.fs file and use your MCU to program it into your gauge in a real system.
Instructions for parsing the .fs files and some sample code can be found in the Flashstream parser in this app note:
I just want to say thank you for your help. However the problem was in the I2C communication code. As I suspected in a first time, the shift between what I was actually reading and what was expected from the 48 datablock hid a bug in the I2C read. This is fixed right now and I can write to the flash auf the gage following the documented procedure.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.