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!