BQ27220: Production line procedure

Vignesh Rajagopal

Part Number: BQ27220
Other Parts Discussed in Thread: BQSTUDIO, GPCCHEM, GPCCEDV

Hi all, we are now starting production for our device which uses the bq27220 fuel gauge. On our initial run, we are seeing inaccurate battery percentages after loading the same FlashStream file (that has previously worked on our prototypes) to the bq27220. Digging into this some more, I think that the fuel gauge is not going through enough charge/discharge cycles in order for it to "learn" the parameters of the FlashStream file.

Looking at the following screenshot from the part's TRM:

1. If FCC only reduces by 256mAh at most per update cycle, does that mean that for our application, where we are going from the default 3000mAh to our battery's 600mAh, it will take us over 9 charge/discharge update cycles before the fuel gauge is ready to go? It doesn't seem like a viable option to ship these devices to consumers and ask them to not take the reported battery percentage into account for a few weeks...

2. What is the recommended procedure to be performed on the production line for devices using the bq27220, so that they are ready-to-ship with accurate battery percentage reporting?

3. What is the standard check to know when the fuel gauge has completed its 'learning'?

4. Is there a way to load the battery characterization onto the fuel gauge such that no 'learning' needs to happen? If yes, what would this characterization process look like? It seems like there would be some way to put all fuel gauges into the same initial state since we have the full profile of the battery we will be using.

Would really appreciate some prompt input here so we can move forward with shipping these devices to our customer.

Thanks in advance,

Vignesh

over 5 years ago

0 Wyatt Keller over 5 years ago

TI__Guru** 105760 points

Hello Vignesh,

You should be able to program all the base values for your battery in data flash then use the flash stream file to upload to the gauges.

You should always set the design capacity and other charge termination parameters in the dataflash before export the .fs file. Most of these parameters depend on your battery and charger application.

The setting are described in detail in the TRM: https://www.ti.com/lit/ug/sluubd4/sluubd4.pdf?ts=1596733820979&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ27220

Check the data memory > configuration > current thresholds. Set them so they match your charger application.

Sincerely,

Wyatt Keller

0 Vignesh Rajagopal over 5 years ago in reply to Wyatt Keller

Prodigy 240 points

Hi Wyatt,

Thank you for your response. What you're describing is precisely what we have done. We used the EVK to generate a custom .fs file with parameters such as design capacity (600mAh), near full, etc modified to match our system. This new .fs file then gets programmed into the gauge by our processor on boot. We have already verified that the file is being loaded correctly and all the verification steps are passing.

The question now is, when we read the FCC register, we still see the default value of 3000mAh. Looking at the screenshot I posted, I am understanding that in order for the FCC to go from this default 3000mAh to 600mAh, it will take a little over 9 qualified discharge cycles since FCC can only reduce by 256mAh per cycle. Is my interpretation of this correct?

The issue is that even after loading our custom FS file onto the BQ27220, we are not getting accurate readings for battery percentage. Remaining capacity readings are also sometimes in the 2000 range, indicating that the gauge is still working with the default capacity of 3000mAh. When we read back the design capacity, however, we see that it is correctly set to our 600mAh.

Thanks and looking forward to your response.

Vignesh

0 Wyatt Keller over 5 years ago in reply to Vignesh Rajagopal

TI__Guru** 105760 points

Hello Vignesh,

Could you export your .gg file so we can see your settings?

You can set the FCC value manually in the gauge in dataflash , it is right next to design capacity in bqStudio. You may need to do this to get an accurate reading from the beginning of gauging.

Sincerely,

Wyatt Keller

0 Vignesh Rajagopal over 5 years ago in reply to Wyatt Keller

Prodigy 240 points

Hi Wyatt,

We have set the FCC value manually in dataflash. Here is a screenshot from bqStudio that we used to generate our FlashStream file:

As you can see, we are updating the value of Full Charge Capacity to match Design Capacity. After the FlashStream loading is completed, when we read back Design Capacity using the standard command 0x3C, we correctly get 600mAh. However, when we read back FullChargeCapacity using the standard command 0x12, we still get 3000mAh. Is there anything that we're doing wrong?

Thanks,

Vignesh

0 Wyatt Keller over 5 years ago in reply to Vignesh Rajagopal

TI__Guru** 105760 points

Hello Vignesh,

Is this screenshot after the .fs file was loaded to the gauge? If you have loaded the .fs all the dataflash should update to the values you programmed in the .fs, you wouldn't need to cross them out. Are you in unseal full access mode of the gauge? If not you may not be able to write to these registers and you will have to put it in full access mode.

Sincerely,

Wyatt Keller

0 Vignesh Rajagopal over 5 years ago in reply to Wyatt Keller

Prodigy 240 points

Hi Wyatt,

The screenshot is just a reference to show what changes we have made for our application compared to the default values from the fuel gauge. This was taken using the EVK, and the generated FlashStream file (attached for your reference) is what gets successfully loaded onto our fuel gauge on our PCB. The file is fully loaded successfully, as seen by checking the return value of the gauge_execute_fs() function. Right before this function is called, we are putting the fuel gauge into full access mode by writing 0xFFFF to register address 0x00 twice.

Fullscreen bq27220.txt Download

;--------------------------------------------------------
;Verify Existing Firmware Version
;--------------------------------------------------------
W: AA 3E 02 00
C: AA 3E 02 00 02 20 00 03
;--------------------------------------------------------
;Data Block
;--------------------------------------------------------
W: AA 3E B4 91 00 00 00 00 00 00 00 00 CB D4 1A 05 D4 86 4A C6 B4 C2 6E 2B 03 7C 01 48 FD A3 F6 75 12 58 2D B7
W: AA 60 62 24
X: 10
W: AA 3E B4 91
C: AA 3E B4 91 00 00 00 00 00 00 00 00 CB D4 1A 05 D4 86 4A C6 B4 C2 6E 2B 03 7C 01 48 FD A3 F6 75 12 58 2D B7
W: AA 3E D4 91 1C 98 02 D3 FF B9 30 01 00 EF 05 11
W: AA 60 23 10
X: 10
W: AA 3E D4 91
C: AA 3E D4 91 1C 98 02 D3 FF B9 30 01 00 EF 05 11
W: AA 3E 80 91 FF F0 0B D6 7E 73 B6 45 93 0A A5 22
W: AA 60 CE 10
X: 10
W: AA 3E 80 91
C: AA 3E 80 91 FF F0 0B D6 7E 73 B6 45 93 0A A5 22
W: AA 3E F5 91 00 00 01 C2 00 32 00 C8 10 68
W: AA 60 44 0E
X: 10
W: AA 3E F5 91
C: AA 3E F5 91 00 00 01 C2 00 32 00 C8 10 68
W: AA 3E 01 92 00 64
W: AA 60 08 06
X: 10
W: AA 3E 01 92
C: AA 3E 01 92 00 64
W: AA 3E 32 92 02 26 02 01 F4 02 58 02 02 26 F6
W: AA 60 A2 0F
X: 10
W: AA 3E 32 92
C: AA 3E 32 92 02 26 02 01 F4 02 58 02 02 26 F6
W: AA 3E 06 92 04 84 10 00
W: AA 60 CF 08
X: 10
W: AA 3E 06 92
C: AA 3E 06 92 04 84 10 00
W: AA 3E 0B 92 01 09 00 00 96 00 AF
W: AA 60 13 0B
X: 10
W: AA 3E 0B 92
C: AA 3E 0B 92 01 09 00 00 96 00 AF
W: AA 3E 12 92 02 20
W: AA 60 39 06
X: 10
W: AA 3E 12 92
C: AA 3E 12 92 02 20
W: AA 3E 17 92 00 0A 05 00 32 01 C2 14 14
W: AA 60 2A 0D
X: 10
W: AA 3E 17 92
C: AA 3E 17 92 00 0A 05 00 32 01 C2 14 14
W: AA 3E 28 92 00 3C 00 4B 00 28 00 3C 3C 01
W: AA 60 1D 0E
X: 10
W: AA 3E 28 92
C: AA 3E 28 92 00 3C 00 4B 00 28 00 3C 3C 01
W: AA 3E 40 92 0C 4E 02 0C B2
W: AA 60 13 09
X: 10
W: AA 3E 40 92
C: AA 3E 40 92 0C 4E 02 0C B2
W: AA 3E 7F 92 0C 8C 8C 0B B8 0C 1C 00 05 10 68 10 04 64 5F 0C 80 0C E4 06 08 10 68 10 04 64 5F
W: AA 60 B2 1F
X: 10
W: AA 3E 7F 92
C: AA 3E 7F 92 0C 8C 8C 0B B8 0C 1C 00 05 10 68 10 04 64 5F 0C 80 0C E4 06 08 10 68 10 04 64 5F
W: AA 3E 9A 92 00 10 2A 02 58 02 58
W: AA 60 E5 0B
X: 10
W: AA 3E 9A 92
C: AA 3E 9A 92 00 10 2A 02 58 02 58
W: AA 3E 8F 41 00
W: AA 60 2F 05
X: 10
W: AA 3E 8F 41
C: AA 3E 8F 41 00
W: AA 3E 7D 92 5A
W: AA 60 96 05
X: 10
W: AA 3E 7D 92
C: AA 3E 7D 92 5A
W: AA 3E 51 92 02 BC
W: AA 60 5E 06
X: 10
W: AA 3E 51 92
C: AA 3E 51 92 02 BC
W: AA 3E 5B 92 77
W: AA 60 9B 05
X: 10
W: AA 3E 5B 92
C: AA 3E 5B 92 77
W: AA 3E 64 92 05 DC
W: AA 60 28 06
X: 10
W: AA 3E 64 92
C: AA 3E 64 92 05 DC
W: AA 3E 68 92 14 00 00 00 28 00 00 64 64 08 0E 74 00 64 1F 40
W: AA 60 B4 14
X: 10
W: AA 3E 68 92
C: AA 3E 68 92 14 00 00 00 28 00 00 64 64 08 0E 74 00 64 1F 40
W: AA 3E A3 92 0E 74 00 64 0E 9F 00 95 03 63 0F BE 01 3C 09 00 00 0B D7 01 0D 39 01 0D AD 01 10 4D 0F CB 0F 55
W: AA 60 A9 24
X: 10
W: AA 3E A3 92
C: AA 3E A3 92 0E 74 00 64 0E 9F 00 95 03 63 0F BE 01 3C 09 00 00 0B D7 01 0D 39 01 0D AD 01 10 4D 0F CB 0F 55
W: AA 3E C3 92 0E ED 0E 8D 0E 48 0E 23 0D FE 0D BB 0D 6F 0A 99
W: AA 60 9B 14
X: 10
W: AA 3E C3 92
C: AA 3E C3 92 0E ED 0E 8D 0E 48 0E 23 0D FE 0D BB 0D 6F 0A 99
W: AA 3E 7B 92 02 3C
W: AA 60 B4 06
X: 10
W: AA 3E 7B 92
C: AA 3E 7B 92 02 3C

The issue is that even after this attached FlashStream is loaded, the value of Full Charge Capacity (read back using standard operating command 0x12) is still 3000mAh. The value of Design Capacity (read using 0x3C) is, however, correctly updated to 600.

I know you asked about the .gg file in the other post, would this be beneficial in helping us debug this? I can connect to those lines on our hardware and see if I can use Battery Management Studio to extract the .gg file if so.

Thank you for your support and hoping we can find a resolution on this soon.

Vignesh

(edited to fix comment about full access)

0 Wyatt Keller over 5 years ago in reply to Vignesh Rajagopal

TI__Guru** 105760 points

Hello Vignesh,

Okay I see what you are showing now, thanks. The gauge should correct the FCC value after the first full cycle, when the design capacity is changed. Are you seeing that this is not the case after the first cycle? The gauge needs to go through a full cycle in order to update the FCC.

Yes if you could log the cycles showing the FCC is not adjusting correctly and export the .gg file this would be the best for debugging the problem.

Sincerely,

Wyatt Keller

0 Vignesh Rajagopal over 5 years ago in reply to Wyatt Keller

Prodigy 240 points

Hi Wyatt,

Thanks for your explanation. That brings forward two main points:

1) What is considered a full cycle?

2) What is the production solution for this? Does every single gauge need to go through a full cycle before shipping the device to a customer? How does one confirm that the gauge has gone through a full cycle prior to ship?

Also, would you be able to point to me any documentation on how we can go about exporting the .gg file?

Thanks,

Vignesh

0 Kang Kang over 5 years ago in reply to Vignesh Rajagopal

TI__Mastermind 24870 points

Hello Vignesh,

1. Full cycle is charge to full, relax 2 hours, discharge to terminate voltage, relax for 5 hours. You can also refer to GPCCHEM.

2. You will need to have configured GPCCEDV tool, then start testing in the product to determine if the golden image is acceptable.

3. bqStudio should export the gg file. It is in the EVM user's guide.

0 Vignesh Rajagopal over 5 years ago in reply to Kang Kang

Prodigy 240 points

Hi Kang,

Thank you for answering those questions. I want to clarify the GPCCEDV tool process just to ensure that I'm understanding correctly:

First, we will perform battery characterization using the GPCCEDV tool and send the data as a zip to TI. TI will email back a report with which we load the "golden image" onto the fuel gauges.

Is there a guideline on what the battery characterization process should look like on our end?

What is the golden image? Is it similar to a FlashStream file, and loaded the same way?

Once we obtain the golden image, will each device's fuel gauge still need to go through the full cycle (i.e. 7+ hours) before it can be shipped to a customer?

I'll look into exporting the gg file to hopefully help understand this better.

Thanks,

Vignesh

0 Kang Kang over 5 years ago in reply to Vignesh Rajagopal

TI__Mastermind 24870 points

Hello Vignesh,

Yes, the zip data is just a collection of CEDV parameters in which you program the gauge. The golden image is the flashstream file, except it is just an image in RAM. It's loaded via the same way as you would any other fs file. Please refer to the TRM on how to change parameters.

The golden image can be shared and can be programmed via a host controller. We have an app note, gauge communications that shows how one may do this.

Thanks!

Power management

Power management forum

BQ27220: Production line procedure