• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 505 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: I2C checksum mismatch

Jules
Prodigy 66 points
Part Number: BQ76952
Other Parts Discussed in Thread: BQSTUDIO,

Dear community,

I can't figure out why my calculated I2C checksums don't match those of the BQ. Only the first checksum after startup matches. All others differ.

After reading for example Comm Type from 0x9239 and retrieving 0x12 as a result, my checksum is calculated as follows: 0x39 + 0x92 + 0x12 = 0xDD --invert--> 0x22 (34 DEC)

Reading from 0x60 however returns 0x10 (16 DEC).

I sticked to the technical reference ch. 3.1 Direct Commands and Subcommands. Am I misunderstanding something here? Thanks in advance!

  • 0
    TI__Guru* 79213 points

    Hi Jules,

    There are a couple of examples of writing to registers in the BQ769x2 Software Development Guide. There are also many examples in the BQ769x2 Code Examples. Have you reviewed these already?

    How are you communicating with the device - are you using a microcontroller or BQStudio?

    Regards,

    Matt

  • 0 in reply to Matt Sunna
    Prodigy 66 points

    Hi Matt and thanks for the reply!

    The communication is working. I can read and write values and all seem to be valid. However, following the approach of the BQ76952 Technical Reference, it seems to be a bit more complicated to do it 'correctly'. Just to cite the reference:

    ----

    The most efficient approach to read the data from a subcommand (to minimize bus traffic) is shown below:

    1. Write lower byte of subcommand to 0x3E.

    2. Write upper byte of subcommand to 0x3F.

    3. Read 0x3E and 0x3F. If this returns 0xFF, this indicates the subcommand has not completed operation yet. When the subcommand has completed, the readback will return what was originally written. Continue reading 0x3E and 0x3F until it returns what was written originally. Note: this response only applies to subcommands that return data to be read back.

    4. Read the length of response from 0x61.

    5. Read buffer starting at 0x40 for the expected length.

    6. Read the checksum at 0x60 and verify it matches the data read.

    ----

    And the last step - step 6 - is causing inconsistency. I calculate the checksum as explained in the manual which also corresponds to the code examples. Maybe there are scenarios for which the checksum is calculated differently? It seems that in those cases the BQ calculates the checksum over the whole tranfer buffer even though only sub addresses should be used.. 

    Communication path is MCU <-> BQ but I think thats not the root cause.

  • +1 in reply to Jules
    TI__Guru* 79213 points

    Hi Jules,

    I think you may be right that the checksum in Step 6 is calculated on the entire 32 byte transfer buffer. The length returned from 0x61 is 0x24 in this case (32 decimal). 

    In general, I recommend the Software Development Guide examples and the example code over the TRM sequence. For example on Step 3 (Read 0x3E and 0x3F) until it returns what is originally written - most users prefer the simpler method of waiting 2ms. I have seen cases where reading 0x3E/0x3F too frequently can actually slow down the command from completing. 

    Best regards,

    Matt

  • 0 in reply to Matt Sunna
    Prodigy 66 points

    Hi Matt,

    alright, I'll switch to the non-TRM approach then.

    Thank you and best regards,

    Jules