• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 432 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Currents value issue

ArTzy
Genius 17415 points
Part Number: BQ76952

Hi Team,

Good day! I have this query from client about battery monitor - BQ76952.

With SPI interface, he has a loop to acquire the measurement of cc2 current (command 0x3A); userA unit is set to 10mA.

When the current is in charge or discharge, the measured values are stables. However, when there is no current (0.0mA), there are some peaks read in negative or positive current to - 2.55 A or + 2.55 A. The value of the cc2 is saved to 2 bytes. It's sound like the low byte is read and a new current measurement is done before the high byte is reading.

Any solution for this?

Thank you for your support.

Regards,
Archie A.

  • 0
    TI__Guru* 81034 points

    Hi Archie,

    It sounds like the current is likely changing between 0 and -1 between reading the two bytes. When reading with I2C this is usually not an issue because when you read the first byte, it latches the 2nd byte so that they are both from the same reading. 

    This is true for SPI as well, but with the SPI there is some repeated reads from a register to make sure the data is ready. I'll take an example from the BQ769x2 Software Development Guide (https://www.ti.com/lit/an/sluaa11b/sluaa11b.pdf ).

    In the example below the Cell1 voltage is being read which is two bytes located at 0x14 and 0x15. For SPI, we recommend reading until the data is reflected back on MISO. In the section where is says "MISO is reflecting command written", this shows the first byte of the reading. However, when we start to read from 0x15 in the next step, it reads 0x14 (previous command again). This is the safer data to record because it is latching the 0x15 data too. So for 2 byte readings, they should grad the data in the circled section since it can safely be paired with the data coming on the 2nd byte.

    Best regards,

    Matt

  • 0
    Prodigy 30 points

    Hey Archie,

    We actually ran into this problem too and we just fixed it. We tried Matt's answer and we couldn't get it working consistently. It seems like block transfers don't work for direct commands over SPI. You can however do block transfers using subcommands. We ended up using the CC3 value from the DaStatus5 register and it worked perfectly. Not seeing any more spikes. Good luck!

    -Harmander Sihra