BQ76952: Alert Pin goes high randomly and disturbs our application processes

Also, I'd like to know in what all conditions does the Alert pin goes high and how to configure those conditions ?

HI Team, we need to know the reasons why WAKE bit in ALARM status register is getting set and AFE Alert is generating ? ALL the reasons for the same. 

This is very critical for us.

Please assist.

Hello Sourabh,

Apologies, yesterday was a holiday.

Do you know which ALERT bit is being set? What configuration changes did you make to the ALERT pin? Table 6-8. Alarm Raw Status() Bit Definitions in the TRM shows all the bits that can be set. 

Best Regards,
Alexis

Hi Alex, we have recently made modifications for alert pin to go high through ALARM Status register making masking Wake bit to generate an AFE alert.

In our older configuration, we have only made these two settings (bit 14 and bit 15, ie SSA and SSBC, ie alarm mask was 0xC000) to generate an AFE Alert through Alarm Status register.

Recently, we have developed a new firmware in order to detect the presence of charger through AFE. And for that we have used wake bit to generate and interrupt (AFE Alert pin going high) and thus wake up the host microcontroller.

And now we see, that randomly due to some unknown reason, wake bit gets set, it generates AFE alert and wakes up our BMS. 

Below are the recent configurations that we made in order to develop charger detection firmware:

Hello Sourabh,

Is this ‘randomness’ occurring once the charger is detached or while the charger is still connected? If it is while the charger is detached, since SLEEP mode is not disabled, there is a chance the device entered sleep mode at some point before waking up again causing the Alarm Raw Status() [WAKE] bit to be asserted briefly.

I see you have your Sleep Current threshold set to 32000mA. This means that when the CC1 Current measurement falls below that threshold, the system is considered in RELAX mode, and the device can autonomously transition into SLEEP mode.

Can you check if the CC1 measurement is consistently above the threshold or verify if the part is always in NORMAL mode before the bit randomly asserts? 0x12 Battery Status() [SLEEP] bit indicates whether the device is presently in SLEEP mode or not.

Best Regards,
Alexis

Hi Alex,

The randomness occurs when the charger is detached. Basically we don't have it connected and even then at some point the AFE wokes up, WAKE bit gets set and then probably AFE ALERT gets issued and MCU wakes up.

And the CC1 current is well below the threshold when the AFE is in NORMAL (awake) mode. It is 7 mA to be precise.

I just wanted to know if there is any indication that will tell us that the WAKE bit was set to do any specific condition. Like is there any register which upon read might give us this info that has triggered the WAKE bit.

Hello Sourabh,

Unfortunately, there isn’t a register that can be read to tell what triggered the WAKE bit.

You would have to manually check for either: 1) protection fault occurs, 2) if current begins flowing above the threshold, 3) if a charger is attached.

If you have set CB_SLEEP = 1 and CB_NOSLEEP = 1 to allow for cell balancing during SLEEP, then the device exits SLEEPs mode to begin balancing as well.

Best Regards,
Alexis

Hello Alex,

We haven't configured the BalancingConfiguration 0x9335 - Settings:Cell Balancing Config:Balancing Configuration, so, it is at is default i.e., CB_SLEEP = 0 and CB_NOSLEEP = 0.

And also how will we check manually since the AFE itself performs the check and as an outcome either triggers an ALERT or sets some register. Just not aure what exactly do you refer to while suggesting to check manually ?

Hello Sourabh,

The AFE itself would check for it and trigger the ALERT, however, if you want to know which one is triggering it, you would need to manually check yourself which one of the possible conditions could be triggering it.

For example, you can check the CC1 current measurement to see the current amount the AFE is seeing to check against the threshold setting. I believe the subcommand 0x0075 DASTATUS5 can give you the CC1 current measurement. Table 4-5. 0x0075 DATSTATUS5() Subcommand Detail  and Section 4.6 Subcommands 0x0075-0x0077 DASTATUS5-7(), Additional Measurements in the technical reference manual gives further detail regarding it.

Something else to consider is the Power:Sleep:Wake Comparator Current as well.


Best Regards,
Alexis

Hello Alex,

We have set up a test wherein we configured the wake Comparator Current threshold to 32000 just to verify that whether changing this solves the issue. ANd to our observation, we see that the issue did not occur for the entire 2 days period in which the device was under test.

How can we determine whether this was the exact root cause in our case ?

Can we manually verify using some testpoints on AFE for this hypothesis or is there is register value upon read will show us that this entity was the only thing that has caused the issue.