BQ35100: Large jump in accumulatedCapacity value

Jp Zometa

Part Number: BQ35100
Other Parts Discussed in Thread: BQ25100, , BQSTUDIO

We have an issue w.r.t. the value of accumulated capacity. We have around 500 that use a BQ35100 to monitor the accumulated capacity of a SAFT LSH20 battery (nominal capacity 13 Ah). The BQ25100 is in ACC mode. The devices are exclusively powered by this battery. The devices sleep most of the time (e.g. sleep for an hour, wake up, send some data (including accumulated capacity) and go back to sleep). All devices have been running for months already delivering normal accumulated capacity readings. At different points in time, some of the devices show a large jump in the accumulated capacity. The new accumulatedCapacity readings are higher than 31 Ah (i.e. more than double the nominal battery capacity). All batteries so far continue operating without issues. Here are some examples of how the actual readings on some devices look like:

Device ID	Value before jump (hex)	Value after jump (hex)
1	`-1912855 (0xE9CFE2FF)`	`-31724460 (0x54EC1BFE)`
2	`-1412638 (0xE271EAFF)`	`-31722796 (0xD4F21BFE)`
3	`-1396580 (0x9CB0EAFF)`	`-31722404 (0x5CF41BFE)`
4	`-760949 (0x8B63F4FF)`	`-31722796 (0xD4F21BFE)`
5	`-1406343 (0x798AEAFF)`	`-31722796 (0xD4F21BFE)`

The main things I have noted so far are that:

The values are all around 31 Ah, much higher than the nominal battery capacity. This is an indicator that the value cannot come from a correct measurement.
The values after the jump are very similar, in some cases identical, for example: (0xD4F21BFE).
The last 2 most significant bytes are identical (i.e. in little endian they are '0x1BFE')
After the jump, the accumulated capacity readings seem to be as expected in differential terms (i.e. current_accCap - previous_accCap ~ expected battery discharge between accCap readings).

Can you provide any hint on how to solve/prevent this issue?

over 5 years ago

0 Andy Liu (BMS) over 5 years ago

TI__Guru 52115 points

We will take a look and get back to you next week.

Andy

0 Jp Zometa over 5 years ago in reply to Andy Liu (BMS)

Prodigy 40 points

Update: I noticed that some of the devices that present this issue, reach after a while a specific value of accumulate capacity, namely:

-32767000, which in hex is 0xE8030CFE (little endian format, as received via the I2C interface). The interesting thing is that 32767 = (2^15) - 1. So, I guess it has to do with some saturation value that is internally reached,. Still the values that are delivered via the I2C don't represent the actual accumulate capacity of the battery, nor match the documented saturation point.

0 Vos over 5 years ago in reply to Jp Zometa

TI__Genius 10370 points

Jp,

I think the focus here should be if the "Current" register is calibrated correctly. If the battery design capacity is only 13Ah approaching 31Ah would indicate either a constant offset or calibration being incorrect. When the device is powered down via the GE pin or the gauge stop command is issued it will stop taking measurements which should protect you against any noise.

The accumulator will rollover when a max value is reached so it is expected as 32767 (2^15) is reached a large jump would be seen. This statement is incorrect. Verified by Eric Vos 06/16/2020

My suggestion at this point is to enable the gauge on the bench, apply a known load, and verify Current is reported correctly.

Thanks,
Eric Vos

0 Jp Zometa over 5 years ago in reply to Vos

Prodigy 40 points

Hello Eric,

Thanks for your answer. Here are my comments:

I think the focus here should be if the "Current" register is calibrated correctly. If the battery design capacity is only 13Ah approaching 31Ah would indicate either a constant offset or calibration being incorrect. When the device is powered down via the GE pin or the gauge stop command is issued it will stop taking measurements which should protect you against any noise.

As you correctly noted, we have a constant offset that appears suddenly, it's extremely large, and it's approximately the same value (sometimes it is the same value -31722796). So, I doubt this is a calibration issue. The question is why does this happen and how to avoid this from happening. The MCU properly "starts" the Coulomb counter during wake up, and "stops" it before going to sleep.

The accumulator will rollover when a max value is reached so it is expected as 32767 (2^15) is reached a large jump would be seen.

Can you clarify what you mean in that sentence? We see the jump before reaching -32767000, and there is no roll-over happening. Once we reach this value (-32767000, or in hex 0xE8030CFE), the counter does not increase, which makes no sense for a 32-bit value. According to the TRM, the AccumulatedCapacity is a 4-byte value, and "If the value reaches full, it will hold at the full count and not roll over". [p.38]

Thanks again! :)

Regards,

0 Vos over 5 years ago in reply to Jp Zometa

TI__Genius 10370 points

JP,

I will correct my comment. I confirmed with the team, when the counter reaches max value it will no longer roll over. It will hold at the -32K number.

Thanks,

Eric Vos

0 Jp Zometa over 5 years ago in reply to Vos

Prodigy 40 points

Hi Eric,

thanks again for your reply. I still don't understand why "It will hold at the -32K number"? Shouldn't it hold at 1 - (2^31) = -2147483647, as per the documentation, or is the documentation wrong? Nevertheless, this still does not explain why the sudden jump in the accumulated capacity. Do you have any insight from your team regarding this in particular?

Regards,

Pablo

0 Vos over 5 years ago in reply to Jp Zometa

TI__Genius 10370 points

Pablo,

It will hold to the max value in the TRM.

4.29E9 μAh.

Thanks,

Eric Vos

0 Vos over 5 years ago in reply to Vos

TI__Genius 10370 points

Pablo,

Is your host writing this register at all?

Can you replicate this using bqStudio?

What is your exact procedure?

Thanks,

Eric Vos

Power management

Power management forum

BQ35100: Large jump in accumulatedCapacity value