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.

BQ34Z100-G1: Configuration does not apply

Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: EV2400, BQSTUDIO, GPCCHEM, GPCRB

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 0x00

Then, 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 0x97

Here are the expected 32 bytes, according to the documentation of the battery gauge
0xXX 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 0x62

I 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[10] = 0xa0; byte_stream[11] = 0x28;

wr (0x40 + 10) 0xa0 0x28

Design energy: bytes_stream[12] = 0x4b; byte_stream[13] = 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 ?

  • Hi Aurelien,
    Your post has been assigned to one of our BMS experts.

    Regards,
    David
  • 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

  • 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.

  • Hi User5324968,

    As a debug step, are you able to write values to data memory and read them back when using bqStudio with an EV2400?

    We need to rule out the Flash Update OK Voltage as being the culprit (preventing writes to data memory).

    The value input for for cell update OK voltage is not a pure voltage, but relies upon many variables including your Voltage Divider parameter.

    1) Please confirm that you are able to save values and read back these modified values from data memory (preferably with bqStudio and an EV2400 to reduce potential sources of error)

    2) If the error persists after a successful confirmation of being able to write and read the modified value to/from data memory, please provide more information about your system such as the number of series cells, voltage supplied to the device, external voltage divider resistor values and include your gg.csv file.

    Sincerely,
    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:

    SLUA801
  • Hi all

    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.