BQ78PL114: Cycle Count goes back to Zero

Hello Robert,

Can you clarify the following:

1)

Are you expecting the cycle count to be 1 when it reaches the customer or 0?

2)

How many packs is this occurring on? is it only some of the packs?

3)

Can you run another cycle on these batteries to see if the cycle counter changes?

Sincerely,

Wyatt Keller

It is only on some Packs and we expect the count to be 1. We cannot understand why it gets reset to 0 once it got a cycle and even showed it.

Do u have a Idea what can cause the cycle count to return to zero?

I did some more testing today and found out, that it is possible to reset the Cycle Count by simply changing the Manufacturer Date and Comit that change to flash. It does not get set to 0 when the Change is just put into The Ram. When i change the manufacture Date and Write Pending Changes to RAM the Date gets changed and i have the Option to Comit to Flash. When i unplug the Batterie and Replug it, the Option of Comiting the Changes to Flash is not there anymore but it "looks" like all has been changed allready.

During our Testing and before we start cycling the Batteries we change the manufacture Date on our Batteries in a End of Line Test. What happens when there is for example an Error in Communication and the Manufacture Date gets updated but not commited to Flash ? Is it possible that the Device itself starts the Process of Commit to Flash on its own later down the Line after we cycled the Batteries ?

Hello Robert,

The device does not always write to flash. The device stores the data in RAM and only updates flash periodically. What I believe is happening is that we didn't allow enough time for the flash to update prior to a POR of the pack and that's why your cycle count does not get updated.

Thanks for the answer. Does that mean it could happen with any POR that a Cycle currently shown and not yet saved in Flash can get cleared again ?

Can u please tell me if it is possible to force the Write to Flash and under wich circumstances the Pack does a POR ?

Hello Robert,

Were checking with the firmware team if you can make the gauge do a flash write, there probably is not a way but let us check.

Sincerely,

Wyatt Keller

Hello Robert,

The firmware team says it is not possible to force a flash write before a POR.

If there is a cycle count saved to RAM and the device goes into POR that cycle count will be lost.

Sincerely,

Wyatt Keller

Hello Wyatt,

should there be PORs once we assembled the Pack and do not disconnect anything ?

And is there a way to force a POR without disconnecting the Cells ?

Hello Robert,

No there shouldn't be, unless there's a bad connection somewhere which temporarily disconnects the gauge.

Disconnecting power and reconnecting should be the only way to do a power on reset, it is possible though if the gauge has a brownout condition.

Sincerely,

Wyatt Keller

Hello again, 

after mutliple Tests i cannot see a brownout Situation. The Cells are soldered to the PCB and a bad connection is very unlikely. I also have Packs that do not count Cycles at all. I will attach a File for a Pack that has a "Lifetime Delivered Amp Hours" of 12Ah and still a Cycle Count of 0 Cycles.

With this Pack i Charged it to Full , Discharged until empty (i did see -2212 mAh in Pack Passed Current.)  Then i Charged it to Full again to see that my Pack Passed Current went back up to 6 mAh. Last Thing i did was discharge to Empty ( -2245mAh in Pack Passed Current).  That means i had a combined discharge of 4457mAh. This is also reflected by the Lifetime Delivered Amp Hours that went from 8Ah to 12Ah. But still no Cycle Count of 1. Is there a Mode in wich the Cycle does not get counted ? I am pretty much at the End of my Ideas and really NEED Input or things i can Check or test for that might cause such a behavior. We are now at a Point where we have these 2 Major issues. Those Packs are for essential Gear for the Corona Outbreak and we cannot just send Packs out that behave in a weird or unpredictable way. 

Issues:

1. Cycle Count is rising and is at 2-3 when sent to the Customer but the Customer reports a Cycle Count of 0

2. Cycle Count does not even go up even if the combined delivered Ah is way above the Design Capacity.

Please, i beg of you to help us to find the Cause for this Behaviour and or give us support and Directions what we can test further

Best regards

Robert Andris

This is the attachment for the Post i wrote. Apparently it got flagged and has be confirmed by an Administrator. This is the Attachment that i refered to

Export all Parameter.csv

Hello Robert,

Are you reading the cycle count in the same way the customer is?

This could be a firmware issue we can look into more.

Sincerely,

Wyatt Keller

Hello Wyatt,

since we have this issue regularly now we allready got Packs back from customer and confirmed we read the cycle count the same way as the customer and it really is at 0. Next Test will be that i Relearn/Initialize the Packs and try to see if the Counter is then Rising. But there is no difference in Flags. Algorithm is still Enable. Please give us a Hints where we can Test so this search for the Root Cause can progress in some way. Right now i have nothing to tell the customer except that we are working together with TI/ Waiting on Input from TI to fix the Issue. 

Sincerely,

Robert Andris

Hello Robert,

I am awaiting a reply from our firmware team of possible conditions that could reset the cycle count, if the reset was not occurring from a POR or some loss of power, the cycle count should be committed to the DF.

This problem has been occurring since the start of production?

Sincerely,

Wyatt Keller

Hello Wyatt,

we help another company with building those Packs in high volume. So this Pack is actually produced on different Sites and is running for quite some time on the customers company.  To verify the Quality this company does some test with the incoming goods and one is to check for the required cycles that should be made during the manufacture process. This Error is known since we produce the Packs and after we asked if this Error occurs with the batteries produced at our customer we got told that it is known that "sometimes" the Cycle counter gets set to zero but not so fast after pack manufacturing.

This means that this Error might be around for some time but was not occuring or tested that frequently like it is now with the Incoming Goods Test.

We also have Packs that do not count the cycles properly. For Instance we see that a Pack goes from 0Ah to 6Ah with the "Lifetime Delivered Amp Hours" but did not increase the Cycle count. It appears as if it is not counting even though the "Pack Passed Current" is working up/down. We tested the Packs and with me doing a Relearn/Initialize of that Pack it started Counting after i applied 2 more Cycles (1 Cycle only nets around 2200mAh with a Design Capacity of 3100).

In any Case the Cycle Counter behaves weirdly and we could need some help urgently in finding a cause.

Please tell us what Tests we could perform other than just cycling and Initializing etc. to check what this issue is caused by.

Sincerelty,

Robert Andris

Hello Robert,

I am still awaiting the reply of our firmware team, I should hear from them before next week.

I see the issue, so this was not monitored until recently. Is this a required feature for the new application? If the fix cannot be found quickly could you use another feature of the gauge to track the amount discharged over time?

Have you been able to pull the safety history data from the gauge to see if any faults occurred during testing?

Sincerely,

Wyatt Keller

Hello Wyatt,

yes this issue was not monitored until recently. And yes it is required at least for us that we deliver Packs that are Precycled and it is checked by reading the amount of Cycles from our Customer and i do not think that we can convince him to not use the Cycle Count.

We pulled the Safety History from most of these Packs but there where no entrys. We also did additional Testing and found the following Behavior :

1. Packs that are cycled and get logged did not miss any Cycles. Thats why the search for the Error is so frustrating.

2. Packs that are cycled and have a TI Interface Adapter connected but not activated (Switchable Hub) did not count the Cycles properly. Both SMBus Pins are on Low 

3. Packs that are cycled and have a TI Interface Adapter connected and active (Switchable Hub) did count the Cycles properly even if the Software is not logging. Both SMBus Pins are High

I have now a cycling Test running with only some Pullups to 3V3 on both SMBus Pins and will get the Result tomorrow.

Did you hear back from the firmware Team ? 

We are gettin more and more pressure from the customer to deliver Packs but have troubles to meet the numbers because alot of Packs are not counting during the Cycling.

Sincerely,

Robert Andris

Hello Robert,

If you are not getting this error with the TI communication protocols then the error could be based in the communication protocol or circuitry.

Can you capture the communications with a logic analyzer, capture bqStudio and compare it to your own communications to make sure they are the same.

Can you also share a schematic so we can make sure everything is correct? You can send me a request on E2E if you want the design private.

I am still waiting on the firmware team, they have been extremely busy recently and have not had time to review this.

Sincerely,

Wyatt Keller

Hello Wyatt,

we do not have communication at all when we cycle the Battery. Last Night i had 2 Pack Cyclying with 3v3 attached to SMBC and SMBD over 2 10k Resistors and it counted the Cycles Properly. At our company we only use the TI USB Interface Adapter 2006 for the communication so we actually have no 3rd party Tool for Communication.

Is the Battery only counting Cycles when there is actually a Device communicating with it ? Or at least if there is a High Signal on the Bus ?

Sincerely,

Robert Andris

Hello Robert,

The EV2400 pulls the lines high when there is no communication, I would recommend the lines be pulled high even when there is no communication.

In step 2 with the switchable hub, were the communication lines pulled high or were they floating? Are you able to share a schematic?

Sincerely,

Wyatt Keller

Hello Wyatt, 

i have sent you part of the Shematic via DM. I am quite frustrated with the whole Situation. I have not been given a proper Reason from you and/or your Firmwareteam why and under

what circumstances it is even possible to have 0 Cycle Counts with 25Ah+ in Delivered Amp Hours with a Pack that has a FCC of around 2200mAh.

Yes you said there is a possibility that it gets set back to 0 when there is a Flash Commit or someone changes the static Data like SN Numbers etc. But when no one is changing anything

and like you said a Flash Commit is very sporadic and with big times between them, we should have Cycles when we are just cycling those Packs without Communication 10 Times and the SMBus is floating during that Time. 

Sincerely,

Robert Andris