BQ27427: BQ27427 Current Reverse Issue

Hello,

This question has been assigned within the team and will be reviewed and followed up with a application engineer when possible. In the meantime please attach any associated .log/.gg files associated with the projects

Thank you,
Alan 

20250805-bq27427.gm.zip

Early batches of the bq27427 have an incorrect sign bit for the coulomb counter gain. CC_GAIN must be a positive value. bqStudio will automatically change this but you'll have to include the calibration class in the Golden Image and program this on your system for this to work.

Please make sure that CC_GAIN is positive.

Hi
This calibration has been done before. But now the situation is that out of 500 units, two are experiencing this problem, while the others are normal.
Also, can you determine the positive and negative poles of CC_GAIN based on the information from the above registers?

I can't determine the sign from the provided registers.

Here is what's in your .gm.fs file:

W: AA 3E 69 00
W: AA 40 00 00 0B D3 7F 29 7D 4A

CC_GAIN is in subclass 0x69, block 0, offset 4. Which is 0x7F 0x29 0x7D 0x4A in your .gm.fs file.

This converts to a floating point value of 0.33103 with a positive sign.

The sign bit is encoded in the second byte at offset 5 from subclass 0x69, block 0. Bit 7 is the sign bit. Your value is 0x29, which means that bit 7 is 0 and the floating point value is positive. If you set this to 0xA9, it would be negative -0.33103.

You'd have to read the actual CC_GAIN from the gauges that have the incorrect current:

* make sure that the gauge is unsealed.

Write 0x69 0x00 to I2C register(command) 0x3E++

Read 4 bytes from I2C register(command) 0x44++

These 4 bytes are the CC_GAIN value in hexadecimal format. The sign bit is bit 7 in the second byte (read from I2C register(command) 0x45).

Hi Dominik
I have confirmed that bit 7 is indeed 1. (When charging)
But the problem is, why is there a possibility of inconsistency with the .gm.fs file? (2 out of 500 units) And if you refer to the environment situation I described above, could you please explain to us the mechanism behind this?

You can also see from the above exception register that the ITPOR bit is 0.

We have taken preventive measures: when the polarity is opposite, we will update the parameters again.

But we don't quite understand the reason for the problem. We need to report this matter to the client.

Is there such a situation where the gauge detects charging, but due to the influence of the external power supply environment, the actual process is discharging, and as a result, the gauge polarity reverses?

The second abnormal device restored its polarity (operating in an abnormal power supply environment), which left me quite puzzled.

The only way that the gauge itself has the wrong polarity is if the CC_Gain bit is flipped. As the earlier version had the incorrect polarity bit, a reset is going to cause this problem, hence it's very likely that the reset caused this. That the .gm.fs file has the correct polarity bit doesn't mean that it "sticks" when the gauge erroneously or unexpectedly experiences a reset. It will revert back to the incorrect setting.

What you mean by "reset" is the update (in .gm.fs), right? What could be the reason for this reset exception? Also, what should we do?
We have come up with a solution which is to update the parameters when this exception occurs. Can this completely avoid this exception?

A reset can occur either because of a RESET command or a (temporary collapse) of voltage on the LDO output (VDD).

Note that this gauge uses a chopped LDO voltage during sleep mode which relies on a 2.2uF capacitor on VDD. If this voltage drops too much below 1.8V then the gauge will reset.

The gauge will never change CC_GAIN by itself other than a reset so if CC_GAIN is different from what you programmed (e.g. in the .gm.fs file) then it must have been reset.

Q1: Regarding this situation, what do you think of the solution I mentioned earlier?
Q2: Additionally, there is another issue. The production line conducts current testing. When the charging state is switched to the discharging state and the current is read from the register, it will remain 0 for several minutes. The longest it takes to read the correct negative current is 3 minutes. Why does this happen? Is there a way to solve it?

A1: Because the gauge doesn't flip the sign bit except after a reset, I do not think that the solution changing the bit if you notice the change in current is a good idea. If this was due to a reset then all other configuration reverts back to default as well so you'd have to program the whole .gm.fs file again (which should not happen unless the battery was disconnected and reconnected).

A2: The only reason why the current may be 0 for several seconds (up to 40 seconds, not minutes), is if the gauge went to sleep mode and the current is less than the hardware wake-up threshold. The gauge will not wake up for up to 40 seconds so you will not see a current for up to 40 seconds if the gauge entered sleep mode.

I recommend disabling sleep mode to check if this is related to your problems (both the sign bit and the current reading delay). I suspect that the capacitor on VDD isn't sufficient. It has to be 2.2uF over temperature and at 1.8V, check the de-rating. Many 2.2uF chip capacitors in 0201 package (for example) that are rated for 6V are de-rated to <1uF at 1.8V and that can cause temporary drop out of voltage on VDD, which can cause random resets, which would explain your problems.

Q3: So, could the root cause be that the reset was caused by a hardware issue? And it might also depend on the situation of the external power supply?

Q4: Regarding Q1, let's clarify this point. We programmed the gm.fs only when we detected the reverse current. We did not update it based on any current changes. Is this approach acceptable to avoid such situations?

Q5: We also encountered a problem in our low-temperature experiment. The equipment was placed in a -20°C environment for 12 hours. Then, when we plugged in the charger and turned it on, we found that the battery level was 0 and it shut down. That is to say, the BQ27427 reported a battery level of 0 under this condition. What kind of anomaly is this?
Register: 00 = 0202 02 = 0A15 04 = 0F6C 06 = 410E 08 = 04DD 0A = 0636 0C = 0000 0E = 0159 10 = 0000 16 = 06CD 18 = 0000 1A = 10AE 1C = 0000 1E = 0A15 20 = 0063 28 = 0000 2A = 0000 2C = 0159 2E = 0159 30 = 0000 66 = 1050 68 = 0400 6C = 000A 6E = 014F 70 = 209

Q6:Hi, this is our design schematic. The capacitor parameters on the VDD are: CERCAP, 2.2uF, 10%, 6.3V, X6S, 0402, auto.
Could you please evaluate if there are any issues or risks in our design?

A3: Yes, unless you sent a RESET command, the underlying mechanism for a sign change in CC Gain is a HW reset.

A4: The only time that you should program the .gm.fs file is if the gauge was reset (either RESET command (not SOFT_RESET) or a HW reset). This is indicated with ITPOR = 1. DO NOT PROGRAM the .gm.fs file at other times as this will interfere with the algorithm performance.

A5: Cell resistance can increase dramatically at -20deg.C. It's an exponential curve. See attached training material.

0763.gauge_fundementals_advanced_DominikHartl.pdf

If your load (Avg I/P Last Run in the State Class (this is a dynamic parameter that is part of the Golden Image but will change automatically based on what the gauge measures in use) is high enough to cause a voltage drop over the internal cell resistance at extreme freezing temperatures like -20deg.C for cell voltage to drop below Terminate Voltage when you would apply this learned load, then the gauge will report 0% SOC as there is no usable capacity left in your cell.

In order to understand if this is inaccurate for your cell, you'd have to check what happens to cell voltage, if you apply the load in Avg I/P Last Run to your actual cell. Does the cell voltage drop below Terminate Voltage? Then SOC = 0%.

Please attach the datasheet for this capacitor. Tentatively, it looks ok (fairly large package) but the 6.3V rating could be a problem if it's de-rated to <2.2uF at 1.8V over temperature. The only way to know is by checking with the datasheet. If the de-rating is not compatible, there will be suitable ceramic capacitors in 0402 package. It's usually a problem is 0201 package where most are significantly de-rated at 1.8V.

3140 190 89231.pdf

Hi Dominik, the spec of 6.3V/2.2uF package(0402),please look the attachment.

and the capacitor rating related to temperature  graph as follow:

 DC Voltage and AC Voltage Characteristic

The screenshot shows the data for a 0.1uF 50V rated capacitor. Do you also have this for your capacitor?

Hi Dominik,

Of course, the capacitor we use is 6.3V/2.2uF,
In Murata's spec, not every capacitor rating will be explained because 0.1uF and 2.2uF are a series of capacitors, and Murata used 0.1uF as an example. When the ratings of 2.2uF and 0.1uF are the same, we can see from the process that as the temperature changes, the maximum rating is 10%

Q7: How do you usually verify whether the .gm.fs file has been updated successfully?