This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ40Z50-R1: Cycle count / Design Capacity mAh issue

Part Number: BQ40Z50-R1
Other Parts Discussed in Thread: BQSTUDIO

Hi Team,

Now customer have to 2S-1P MP product w/ TI bq40z50-R1.

We found two kinds of fail from customer return.

Case1. Cycle count just show once in the before products. But now the we found the cycle counts is 65535.

Case 2. The correct battery capacity is 4830mAh, but we get the capacity 11565 mAh.

This is MP product and we ship 20,000 unit. We  found the fail number is 16 pcs of 200 pcs recently.

customer want to know what causes this issue and do you have any comment or suggestion? 

  • Tommy

        Does customer seal the flash before they ship the battery? I have ever seen similar case caused by not sealing the device before shipping.

        Do they check the signature of each battery before shipping? I mean is there any log information showing the data is correct before shipping

  • Hi Steven,

    thanks for you great help and reply.

    Actually, customer didn’t seal FW before shipping due to end customers need to read gas gauge configuration in system assembly.
    We’ll also advice our customer to update the regulation on sealing FW before our shipment.
    Here may comes another questions as below:
    1. If there will be lower or no defectiveness happed that we adopt the solution on sealing FW before shippment ?
    2. According to battery had been already done shipment, either in EMS or in end user sides, if there any assessment to
    seal the FW, once if our end-user didn’t have jigs and bqstudio SW.

  • Hi, Tommy

        Below are my reply for your questions

        1. If there will be lower or no defectiveness happed that we adopt the solution on sealing FW before shippment ?

            Sealing the flash before shipping is just a suggested conventional measure to be applied to the battery to exclude any possible temptation or unintended operation to the dataflash. Ideally, the issue should not occur anymore. But it is still possible to occur, for example, if the end customer's software for modifies the dataflash configuration occasionally impinged some flash address unexpectedly.

        2: Seal the device can be done by sending a command. If there is no fixture for SMBUS communication, then it can be done at host side by issuing a patch or something