• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 61 subscribers
  • Views 128 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: Invalid accumulated charge values

Joost Weijs
Prodigy 10 points
Part Number: BQ76952
Other Parts Discussed in Thread: BQSTUDIO

Tool/software:

Hello,

I have a BQ76952EVM board communicating with an external MCU-board over SPI. This mostly works as expected, I can read cell voltages, temperatures, etc. just fine.

The only exception is the accumulated charge through the DASTATUS6()-subcommand. The accumulated charge reads 0xffff8001 for the integer portion and 0x7ffffff for the fractional portion. The fractional part is as expected, but I would expect the integer portion to be zero or very close to it. Accumulated time does increase properly. I have verified using a logic analyzer that this is indeed the data that is returned from the BQ-device.

After booting the device, I issued the RESET_PASSQ()-subcommand as required, which as I understand it should reset the accumulated charge counter to 0. As far as I can tell, there are no Alerts or Permanent Fails active, all other metrics seem to work correctly. I have tried the stock configuration (except SPI configuration) but the result is the same.

Any tips would be greatly appreciated.

  • 0
    Prodigy 10 points

    So far I haven't been able to resolve this issue. I've attached a logic analyzer capture. In this particular capture I added a 15ms delay between writing the command address and reading out the data, because I noticed this is how BQStudio times this command. Unfortunately, this did not resolve the issue.

    The capture can be read using Salae Logic 2.

    BQ_DASTATUS6_CAPTURE.zip

  • 0 in reply to Joost Weijs
    Prodigy 10 points

    For anyone who encounters this problem in the future: I solved it by waiting >250ms after resetting the BQ-chip before sending the RESET_PASSQ() command. It seems that the RESET_PASSQ() command is silently ignored if it is sent too quickly after a reset.