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.

BQ27421-G1: Undocumented timing requirement for reading data memory?

Part Number: BQ27421-G1

I'm just starting to work with the BQ2741-G1 on our custom board. I2C communications with the part are fine (we're running I2C at 400KHz, and, per documentation, are doing the required single-byte writes and are waiting 66us after each write). However, in preparation for modifying Design Capacity and other key parameters in data memory, I've written code to first read these values and the checksum from data memory, and have run into a few issues:

1) I've discovered that, if I attempt to read Design Capacity (or any other parameter) from the State subclass immediately after using the DataBlock command to select block 0, it consistently returns 0x8000. However, I wasn't seeing this problem if I stepped through the relevant code instead of simply executing it. I eventually determined that I needed to add an approximately 200us delay after issuing the DataBlock command before. I don't see this requirement documented anywhere.

My assumption is that it takes some time for the BQ2741-G1 to populate the BlockData registers with information from data memory. This is important because, if I read bad data when modifying a parameter, this will result in a corrupted checksum for the block (since I have to subtract those data bytes from the checksum as part of calculating the new checksum). What I would like to understand is what the maximum amount of time this will take, so that I can be sure I'm waiting long enough to read valid data. Alternatively, if there's a register I can poll to determine when all of the data has been populated in the BlockData registers, that would be helpful.

Incidentally, I think one reason that this may not have been noticed previously is that in the "Data Memory Parameter Update Example" in SLUUAC5C, this delay is required between Step 6 and Step 7, but because Step 7 is used to read the checksum before the BlockData register is read, this may typically add enough delay to hide the problem. But if you are simply reading parameters from data memory, then there's no need to read the checksum.

2) What will happen if a bad checksum is written for a block of data memory? Will any modifications to that block of data memory and the new checksum simply get tossed out if the checksum written doesn't match the data?

3) We're using the BQ2741-G1B, but I noticed a few discrepancies from what the documentation states I should expect. Before I modify anything, I read a checksum value for block 0 of the State subclass of 0x68, but the "Data Memory Parameter Update Example" in SLUUAC5C says I should expect to see 0xE8. Likewise, I'm reading a default Design Capacity of 1000 and a default Design Energy of 3700, but SLUUAH7B indicates that for the BQ2741-G1B the Design Energy should be Design Capacity * 3.8. Furthermore, the Data Memory Summary in SLUUAC5C lists 3800 for the Design Energy for the G1B. So why am I only reading 3700?

4) Is there a command that will reset all of the data memory back to factory defaults?

5) Is there a way to programmatically determine which BQ2741-G1 variant (A, B, or D) is on a board, for validating boards received from our CM?

Thank you!

  • Hello Nathan,

    1) 2)

    You are correct, you will need to add a certain delay to the communication between I2C commands, does the delay of 66us stated in the datasheet work for your application, or is it a minimum of 200us?

    You will always want to add a delay after each command to prevent checksum errors and let the all the data become updated before trying to access it again.

    3) 

    The 3.8 volts is from the design voltage, if you have changed that value in your DF the gauge will multiply the design capacity by the design voltage.

    4)

    There is no command that will reset the data, you can export the dataflash of a new gauge and import it to the gauge that needs the default flash values.

    5)

    You can use the command for CHEM_ID, it will output the chemistry ID programmed to the gauge, each version has a different ID.

    It's in section 4.1.6 CHEM_ID: 0x0008, TRM: https://www.ti.com/lit/ug/sluuac5c/sluuac5c.pdf?ts=1597340878189&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ27421-G1

    Sincerely,

    Wyatt Keller

  • Wyatt, thank you for your help. I have a few follow-up questions:

    >You are correct, you will need to add a certain delay to the communication between I2C commands, does the delay of 66us stated in the datasheet work for your application, or is it a minimum of 200us?

    Let me restate my question. Your documentation states that with I2C at 400 KHz, a max delay of 66us is required after each I2C write command, otherwise the next I2C command may not work (presumably because the B27421-G1 is still processing the previous command). We're doing that and it works fine.

    However, what I've found is that the DataBlock command typically requires an additional delay otherwise the parameters read from data memory return 0x8000 instead of their correct value. While my testing has shown that this additional delay needs to be approximately 200us is required, I don't know what the _maximum_ required delay is. In other words, I want to know whether there are cases where the B27421-G1 takes longer than 266us to populate the BlockData registers.

    It's important for TI to tell us what the maximum delay required here is because, if we don't ensure that the required delay is met in all cases, then we risk reading bad data from the data memory. And if that happens when we're modifying data memory, that will result in an incorrect checksum being generated.

    >The 3.8 volts is from the design voltage, if you have changed that value in your DF the gauge will multiply the design capacity by the design voltage.

    I don't see a "design voltage" parameter that we can change. Can you tell me where that's located?

    Also, you said that the gauge itself will multiply the design capacity by the design voltage and use that to set the design energy. But the QuickStart guide (SLUUAH7B) says we're responsible for setting the design energy, and I just tested successfully modifying the design capacity and the design energy was not automatically updated by the gauge. Can you check on this and verify what you told me above? 

    Based on this, I'm still trying to figure out how we're reading a design energy of 3700. When we ready 3700, we hadn't yet made any changes to the data memory or other parameters of the B27421-G1. Also, we definitely have a G1B variant, because design capacity initially read 1000. Given that, I'm trying to understand why we're reading a design energy of 3700 instead of 3800 as described in the Technical Reference.

    >There is no command that will reset the data, you can export the dataflash of a new gauge and import it to the gauge that needs the default flash values.

    I just noticed when I started work this morning that, after leaving our board unpowered and disconnected from the battery all night, it looks like the B27421-G1 data memory had all reverted to its factory settings. Last night, I verified that I had successfully modified the data memory for our battery's parameters, but this morning it was back to original values. And the Technical Reference says this:

    "Most Data Memory parameters reside in volatile RAM that are initialized by associated parameters from ROM. However, some Data Memory parameters are directly accessed from ROM and do not have an associated RAM copy."

    Am I correct, then, that if there is a data memory parameter that we can modify, that means that it is not directly accessed from RAM, and that means that any modifications we make are lost when power is removed from the B27421-G1?

  • Hello Nathan,

    I would recommend reading through this thread, it is discussing some of the timing requirements: https://e2e.ti.com/support/power-management/f/196/t/538858

    The design voltage is in the configuration section of the data memory. For this gauge you will need to configure both design capacity and design energy, flash based gauges you only need to set the design voltage and design capacity.

    I apologize I misread the gauge number, because this is a ROM gauge you can do a POR to reset the values to the standard values, or issue the RESET command and the RAM will be cleared and set to the ROM default values.

    Sincerely,

    Wyatt Keller

  • Wyatt,

    Thank you. I still have a concern that has gone unanswered. When I power off the BQ27421 so that it returns to its factory default settings, and I read the data memory, I end up with the following values:

    Design Capacity: 1000

    Design Energy: 3700

    That Design Capacity is correct for the BQ27421-G1B (which we're using), and only that part, but the Design Energy is incorrect. According to the datasheet, it should be 3800. So one of two things is true:

    1. The actual Data Memory on my part has an incorrect default Design Energy, since the datasheet says that the Design Energy should be set to the (Design Capacity * 3.8), and that's what the Datasheet says the default Design Energy should be. If that's true, I'd like you to verify that  BQ27421-G1B parts in general have this incorrect default Design Energy, so we can eliminate the possibility that this is a problem with my specific part. And if it's a problem with my specific part, we need to understand how the ROM on my part could be incorrect.
    2. The Datasheet incorrect states that the Design Energy for the BQ27421-G1B should be set to (Design Capacity * 3.8), when in reality it should be set to (Design Capacity * 3.7). If this is true, I need to understand that this is true, so that I can configure the Design Energy correctly for my battery. If don't configure the Design Energy correctly for my battery, then the tracking algorithms on the BQ27421 aren't going to work properly.

    One of those two things has to be true; either the ROM on my part is wrong, or the datasheet is wrong.. I need you to tell me which of those two things is true.

  • Wyatt,

    One more interesting datapoint on this question. I just noticed that the version of the Technical Reference from 2014 says that default Design Energy is supposed to be 3700 for the G1B (which is what I see in my ROM). The problem with that is that it contradicts the QuickStart Guide, which says:

    Design Energy should be set to be Design Capacity × 3.7 if using the bq27421-G1A or Design Capacity × 3.8 if using the bq27421-G1B or bq27421-G1D

    However, the newer version of the Technical Reference from August 2016 says that the default Design Energy is supposed to be 3800 for the G1B, which contradicts my ROM.

    Is it possible that somehow I've gotten an old version of the BQ27421-G1B on my board, one that corresponds to this Technical Reference from 2014? When I read the device type and firmware version from my part, here's what I get:

    • Device Type: 0x0421
    • Firmware Version: 0x0109

    Is that not the latest firmware version?

  • Hello Nathan,

    The values may have been updated to a different value in the newer gauges, I will need to ask a colleague because I am not aware of these changes.

    Sincerely,

    Wyatt Keller

  • Wyatt,

    Thank you. But there's still a big problem here. You are saying that the TRM is wrong when it says that the default Design Energy for this part should be 3800. But that also means that the QuickStart Guide is wrong, because it also says that the default Design Energy for the G1B should be 3800, given that the default Design Capacity in my ROM is 1000, and it says this:

    "Design Energy should be set to be Design Capacity × 3.7 if using the bq27421-G1A or Design Capacity × 3.8 if using the bq27421-G1B or bq27421-G1D."

    So your claim here is that both of these pieces of documentation are wrong, and that _really_ the calculation for the Design Energy on the G1B should be (Design Capacity x 3.7). Is that correct?

    This is important, because I have calculate and set the Design Energy for our battery, and clearly it matters to the algorithm on different flavors of the G1 whether this is multiplied by 3.7 or 3.8. We need to get this right, so I need you to tell me what the correct formula is for calculating Design Energy for the G1B.

    Also, can you tell me what the current firmware version for the G1B is?

  • Hello Nathan,

    Current G1B FW should be v1.09.

    Default design capacity is the capacity in which the generic ID was characterized at. We use the term to scale the resistances.

  • Kang,

    Thank you, but that still doesn't answer my core question. I want to you tell me what voltage value I need to multiple the Design Capacity by in order to calculate the Design Energy for the G1B so I can program that on my BQ27421-G1B. Here's teh problem:

    • The QuickStart Guide says i should multiply the Design Capacity by 3.8 to get the Design Energy for the G1B
    • The TRM also suggests I should multiple by 3.8 for the G1B, since it says the default Design Capacity is 1000 and a default Design Energy is 3800 for the G1B. However, Wyatt has suggested this may be in error.
    • The actual ROM on my G1B has a default Design Capacity is 1000 BUT a default Design Energy is 3700. This suggests that, in reality, the G1B expects the Design Capacity to be multiplied by 3.7 in order to calculated the Design Energy.

    So who do we trust here: the values in the ROM or the documentation? I need you tell me what the correct multiplier is for the G1B so I can set the Design Energy correctly for my battery.

  • Hello Nathan,

    Please multiply by the cell spec sheet nominal cell voltage.

    For example, for a Li-Ion cell, it should be ranging from 3.6-3.8 volts. You will need to change design voltage to that value as well.

    Thanks!