• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 63 subscribers
  • Views 351 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.

BQ76942: AFE reset when query DA STATUS 5 after config mode

Erik Almqvist
Prodigy 140 points
Part Number: BQ76942

Hi!

As we are working with the BQ76942, we noticed the following behavior from the AFE.

We querry the AFE for the DA STATUS 5 (0x75) register periodically. We've noticed a problem when polling this register after altering a parameter to the AFE through the described config mode sequence. The write settings sequence we use is:

- Enter CONFIG_MODE,
- Wait for CONFIG_MODE set in battery status reading
- Write setting
- Exit CONFIG_MODE
- Wait for CONFIG_MODE false in battery status reading

If we querry the DA STATUS 5 register after this, there is "a chance" that the AFE will reset (issue is probably timing related to some extent). We notice this as all our configured registers being set to default values. After writing to the configuration, it seems like the FULLSCAN bit of the alarm status raw register (0x64) has been reset. If we wait for this FULLSCAN bit to become set before reading the DA STATUS 5, there seems to be no issue reading the DA STATUS 5.

There is no mentioning in the documentation of this. I'm using the SLUUBY1 – DECEMBER 2020 (the one from MAY is not accessible from your site at the moment). There is no note on the CONFIG_MODE that full scan bit is reset, and the FULLSCAN bit is claims to never be reset after first measurement in the documentation.

So, as a summary:

- The AFE reset upon the DA5 querry seems like a bug, have you seen this?
- Is the documentation for the CONFIG_MODE and Alarm Status Raw register bit FULLSCAN correct?

Best regards

Erik Almqvist

  • 0
    TI__Guru 54715 points

    Hi Erik,

    It is not a known behavior.  The clearing of registers and FULLSCAN seems like a reset.  Is there any way your code could send a reset, or bus traffic could look like a reset?  Are you using CRC for communication?

  • 0 in reply to WM5295
    Prodigy 140 points

    Hi!

    Thanks for your reply! Some answers below:

    Is there any way your code could send a reset, or bus traffic could look like a reset?
     It is quite hard to answer such generic question in a good way. I havn't been looking at the individual I2C bit communication, so I guess there is always a chance something funky can happen. Generally, the protocol looks quite stable), so this is not the first thing I would suspect.

    Are you using CRC for communication?
    We are currently not using CRC on the I2C communication. Even though I agree this would probably be good, I don't think there is a CRC error here though. We verify that we get the response on the expected subcommand back, and I've only seen this failing on the DA STATUS 5 (0x75). Other commands have been sent after the CFG mode sequence without problems, so DA STATUS 5 is not the first command after config mode. If we wait until the alarm status raw register indicates FULLSCAN, then it seems to work. Is FULLSCAN supposed to reset after config mode?

    Best Regards

  • 0 in reply to Erik Almqvist
    TI__Guru 54715 points

    Hi Erik,

    Config update mode clears FULLSCAN in Alarm Raw Status. 

    Config update exit clears FULLSCAN Enable in the Alarm Enable Register if the Alarm:Default Alarm Mask is default.

    FULLSCAN sets in Alarm status only if enabled and the scan completes.

    If you have found a method which works I'd use it.  Reset is not expected and I have not found a way to confirm you finding.  Sometimes as you say "something funky can happen".