BQ76952: Random Reset / Coulomb Counter Reset Value

Hi Baptiste,

It is difficult to evaluate something if you can't get to status or registers.  

One cause of unexpected reset is if transients push SRP and SRN above the recommended operating range. Perhaps you can discuss operating conditions  with them to see if it may be a possibility and if you can reproduce the situation.

If you have the host watchdog setup and it times out that would cause a reset.  Again discussion with the users may help understand the operating environment to make the situation reproducible. 

I expect you have OTP programmed or a reset may cut power to the Regulators.  Consider your setup of the BQ76952 and the behaviors described by the user compared to the description in the technical reference manual to see what may be occurring.  

Thank you for the feedback.

Indeed the OTP is programmed, otherwise host processor wouldn't reboot.

Any hints regarding the coulomb counter reset value ?

Best regards, 

Hi Baptiste,

No suggestions at this point on the CC.  There are several registers, what commands or addresses are you reading for the errant value?  And what is the timing?  If the part has reset causing MCU reset, it seems it would be some time after the device reset had occurred. Is all the BQ76952 setup stored in OTP or is some done by the MCU on startup? 

Hi,

We retrieve the data from BQ by fetching DASTATUS 6 all at once (32 bytes read with 0x0076 subcommand read, we use the default I2C 400kHz).

The value used for the Coulomb Counting on our side is the integer portion (bytes 0 through 3).

We fetch DASTATUS 6 approximately every 5ms. It is not a communication glitch because once the value has jumped, it doesn't come back to its normal range.

On startup of host MCU : 
wait 100ms
configure BQ registers (only reg1/reg2 are set in OTP) incl. protection, gains, userA and so on
wait 1s
deepsleep twice
start main loop (fetch every ~5ms)

On startup we force BQ to DeepSleep to initiate our FSM to a known state - could it be an issue to force DeepSleep when BQ is starting / is in use ?

Another detail - we use 10mA as userA. But the CC counter is calibrated so it actually returns a value in 1mA unit (we purposedly included a 10x factor in the Capacity Gain). Could that be an issue ?

Hoping this can be useful, 

Best regards, 

Hi Baptiste,

Thanks for the detail.  I still have some difficulty understanding the sequence.  Have you been able to get a system in your facility to evaluate, and/or do you have a log of some sort or other output which you can annotate if necessary?  From the description I think it is something like this, but am confused as to where the Accumulated charge offset occurs:

1. BQ76952 resets unexpectedly causing REG dropout/recovery resetting the MCU.
2. BQ76952 REG output powers the MCU, no other autoconfig of the BQ76952. 
3. MCU waits 100 ms, then configures BQ76952
4. MCU sets the BQ76952 to DEEPSLEEP twice.
5. MCU starts main loop
6. MCU reads Accumulated charge integer portion every 5 ms with DAStatus6.

It is good to know it is not a transient event, communication must be good

Where in the sequence does the Accumulated charge step/offset/error occur, is it -32000 when first read and is that after step 5?

Does the Accumulated Time in DAStatus6 have any discontinuity or unexpected value?

How are you waking the part from DEEPSLEEP?  Does it wake twice or is the command sent twice and wake once, and what is the timing?

DEEPSLEEP mode retains register values, no upset is expected.

The 10 mA user A and calibration scale should be fine as long as the calibration is within range. 

Hi WM5295, 

You got the sequence right.

I cannot be 100% sure of when the jump occurs. We send data to our server every second when not in sleep, and from what I see, jump has occurred before we send the first data. I would be tempted to say it occurs before we even read the value for the first time.

We normally wake up the device with a simple exit deepsleep command (0x000E), which is triggered by a user action.
2 possibilities : 
- bug happens during use and BQ wakes up automatically, triggered by voltage still on the bus (charger detection ?) because we know the users never had to restart it manually (they're not tech savvy but they know when they press a button).
- bug happens while in sleep, and the wakeup happens normally at the next user interaction.

In the first case, bug would be triggered by a nasty transient, which is what I thought of at first. But we treat our packs way (waaay) worse than our clients do, and we never had the bug.

The second case is more worrying because it would mean that the bug happens in sleep. And I suspect the second case is the one happening, because if it were the first case, the host MCU would stay in its sleep state and not send data to the server whilst the pack is running; but it doesn't seem to be happening. (I couldn't find any log showing the whole system running without info from BMS)

We do not use the accumulated time today, but it will be a good idea to check.

I know we have little to work with, I was mostly wondering if you had hints about similar issues.
If you have no more input, I suggest we leave this pending and I can come back with more data when I have some (probably a few weeks from now, when we have more time for these tests).

Best regards, 

Have a nice day, 

hello WM5295, Baptiste.

We also have a similar problem on BQ76952 in the pre-production supplied to our customers.

During use, discontinuities in the state of charge (SoC) were found which are probably due to a jump in the coulomb counting value read by the BQ.

The host processor that queries the AFE is not RESET. We do not know at the moment if the AFE resets completely or only loses the value of the Coulomb Counter. In particular we read both the integer part and the fractional part through DASTATUS6.

    AFE_PrivateData.MeasReg.AccumChargeInteger = (  (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[3]<<24) |
                                                    (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[2]<<16) |
                                                    (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[1]<< 8) |
                                                    (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[0]     ) );

    AFE_PrivateData.MeasReg.AccumChargeFractional = ( (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[7]<<24) |
                                                      (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[6]<<16) |
                                                      (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[5]<< 8) |
                                                      (AFE_PrivateData.BuffData[DASTATUS6_IDX].data[4]     )

The event is quite rare and it is not easy to identify the triggering conditions. Do you have any news regarding the problem? 

Hello,

No news on my side so far - didn't have time to dig into that.
One fact that I didn't mention here is that our clients sometimes let the packs rest for a few days / weeks, but in our own facilities we use them nearly every day. Which comforts me in the idea that the glitch happens during a sleep state (glitch happens at our clients facilities).

Do you know at what value the counter jumps ? Do your packs spend a lot of time in sleep ?

Best regards

Hello, the problem seems to occur in NORMAL MODE. I found either a coulomb counter at 0 or -32768. It would seem to change from revision HW / Fw version of the BQ.

I don't know the revision of the ones we have here; they were samples sent by TI around august/september last year. 
The reference on the package is "P76952A3  07W  A9IF", if it can help.

Hi Baptiste, Massimo,

Do you have a log of the change, and what mode the part was in or recent processor activity or system transition when the unexpected value showed up?  Does the time in DASTATUS6 change also?