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.

BQ76952: Subcommand lengths don't match the datasheet

Part Number: BQ76952

So I've written the firmware driver to interface with BQ76952 for my company, and I found some data subcommands don't work quite right.

Some commands don't have the right expected length. For example, 0x0002 FW_VERSION is shown to have 6 bytes on SLUUBY2A, but its internal length read is 11 bytes.

0xF081 READ_CAL1, datasheet shows 12 bytes, but it's actually 14. 

0xF090 CAL_CUV, datasheet shows 2 bytes, but it's actually 32. 

0xF091 CAL_COV, datasheet shows 2 bytes, but it's actually 32.

Can anyone from TI confirm if this is a bug on the BQ76952 or datasheet?  

  • Hi Andre,

    We have looked some into this and found that for READ_CAL you are correct that it's actually 14. The two undocumented bytes are in bytes 12 and 13 and contain the cell map for the device (which cells are in use). We will update the TRM.

    For FW_Version, I did some testing and found to get 6 bytes, could you send a screenshot of your result to see what you're getting?

    And, lastly for CAL_CUV and CAL_COV, these were not intended to be read from registers. A test I did suggested that the readback in the command sequence window was a command that was previously in the buffer. If you wanted to read the results you would need to go to Data Memory: Calibration then find CUV and COV Threshold Override.

    I hope this helps. Best Regards,

    Andrew

  • Thanks for answering. For FW_Version, 11 is what I get from the internal buffer length register. It's read with our firmware, I can't really show a screenshot, but other data subcommands work correctly and I've repeated the test a few times for FW_Version. But the number of bytes that contain data within the 11-byte buffer is indeed six, the rest five are all zeroes.

  • Hi Andre,

    Thank you, we looked into it further, and found you are correct that the data length is returning 11 bytes but 5 of the bytes are unused.

    Regards,

    Andrew