• State TI Thinks Resolved
  • Locked Locked
  • Replies 30 replies
  • Answers 7 answers
  • Subscribers 64 subscribers
  • Views 1373 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ20Z95: Instantaneous increase in RM when charge starts from 0mAh to 1300mAh

Jeffrey Chase
Intellectual 510 points

Part Number: BQ20Z95

On one of our product lines, we are experiencing occasional fallout for inaccurate RSOC when the battery has been cycled. We cycle the battery through a full charge/discharge cycle, then charge it to 30% state of charge based on added capacity. In one of the failure modes for RSOC failure, when 30% of battery capacity is added, the battery comes back reporting RSOC at 60%. 

When the battery was cycled with SMBUS being captured, it was found that when the battery is charging from RM = 0mAh, RM jumps to 1300mAh as soon as charge current is supplied. The protection PCBA is based on the reference design for this gas gauge. Can you provide any insight on why this might be occurring on the particular battery? I have attached the SMBUS log along with flash readings for every five minutest that the battery was runnining and a senc file pulled when the cycle test was completed.

Data Files for RM Jump.zip

  • 0
    TI__Mastermind 42535 points
    yeah, your RSOC depends on load and resting voltage when the gauge changes modes. If you're not optimized for average discharge rates, a high instantaneous dsg rate can bump you to 0% rsoc
  • 0 in reply to Batt
    Intellectual 510 points
    This battery has been through the Chem ID calculation process at least twice. This is not happening with an instantaneous discharge rate. It is happening at the beginning of the charge cycle when the battery is already at 0% SOC. As soon as the charge cycle starts, the remaining capacity jumps from 0 to approximately 1500mAh, which in turn causes RSOC and ASOC to jump to approximately 20%. This has occured in one battery out of approximately 5000 that we have manufactured in the last month. My concern is that a piece of code was incorrectly programmed when the golden .dfi file was loaded, but it does not appear to be anything in the flash settings that are accessible in the .gg file.
  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Can you please send me the gg file from the failed unit and your golden iage for comparison?
  • 0 in reply to Batt
    Intellectual 510 points

    The gg file from the failed unit was included in the original post in an attached zip file. In fact, gg's were taken every 5 minutes while cycling. Also included are a Senc file pulled after the cycle test was complete and an SMBUS log in 5 second intervals. Golden image is attached to this post as a zip file.EMP00191-03.zip

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Thanks for the golden image. I will look into this and reply back within a day.
  • 0 in reply to Batt
    TI__Mastermind 42535 points
    Sorry, this is going to take me longer to analyze. I will reply back to you within a week since I need to get another evm as mine failed and I can't load your image.
  • 0 in reply to Batt
    TI__Mastermind 42535 points
    Hi Jeffrey,

    I'm unfortunately unable to load your dfi file. However, on analysis of your Ra values, it looks like there is a weak connection or weak solder in the pack. The evidence is in the Ra table, the values are supposed to be monotonic from Ra0 to Ra14. However in your failed pack I see Ra3 to be much higher than the values up to Ra6 or even Ra7. This either indicates a bad connection or a manufacturing defect.

    Ra4 is basically what can possibly be the characteristic resistance of the battery. Given that high a value, given your selection of load select, on charging looking at the OCV, it appears that for your chem ID the battery finds itself estimating a 20% capacity. This is why it reads 20% on start of charge when the gauge does remcap simulations.
  • 0 in reply to Batt
    Intellectual 510 points

    Batt,

    Before I destroyed the battery to inspect welds, solder joints, etc., I reprogrammed the battery with the dfi and recalibrated. I then cycled the battery several times without SMBUS, and found that it was meeting the expected RSOC/RM every time. I then cycled it monitoring SMBUS/Flash. As you can see from the attached chart, the jump from 0% to 20% immediately upon charge current being applied is no longer occurring.

    I still intend to open the battery to inspect the workmanship, but would appreciate if you could continue on the path of investigation regarding the programming in parallel. I have uploaded a zip file that contains the SMBUS log, the flash logs after reprogramming the battery with the dfi file, and the golden dfi, rom and gg files (EMP00191) . While I don't think there is anything wrong with the gas gauge itself, I still suspect there was an error introduced in the program while being loaded from the golden file by our supplier's automated system. 

    CycleChartPostReprogramming.pdfE6879 Post DFI Reprogram.zip

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Thanks for the file. I'll check it out and reply back here by next Thu.
  • 0 in reply to Batt
    TI__Mastermind 42535 points
    Hi Jeffrey,

    On looking at both your logs, we do see a significant difference in the resistance tables that the files with the jump and without the jump. We believe that this calculation resulted in bad RSOC estimation. The reason for the difference was that your senc file with the RM jump had corrupt OCV tables which resulted in bad OCV readings. So, you are right. It was some issue with programming in the production line.
  • 0 in reply to Batt
    Intellectual 510 points

    Thank you for confirming. Is there any way you can provide a comparison of the correct vs corrupted data? As an aside, I have other batteries that exhibit similar issues, but for different reasons. In one example, the battery runs fine, with correct RSOC and remaining capacity when the cycle completes, but then after it rests for several hours, remaining capacity drops suddenly, which also causes RSOC to drop. In another, during the discharge cycle, remaining capacity doesn't change for at least ten minutes after discharge current starts. In both cases, I have been able to resolve the problem by reprogramming and recalibrating the affected battery. The tables of correct vs corrupted data would help in two ways. First, I can prove to our customer that the root cause is a problem with programming, and I can submit a rework process for approval. Second, I can get this back to our PCBA supplier, who is programming the boards for us, so they can review their manufacturing process and work towards eliminating the problem from reaching us.

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Hi Jeffrey,

    Unfortunately no. If you had an srec vs an senc I can point you to the hex data which shows you the data corruption. Unfortunately in an senc there is no such option as it is encrypted. What I can tell you is this, your OCV table data which is internal and confidential to TI and pertains to your chem ID was corrupted with about 32 entries not matching expected data. This is static data and is not expected to change through the lifetime of the gauge.
  • 0 in reply to Batt
    Intellectual 510 points

    I understand that the OCV tables are confidential to TI. I am not aware of any way to create an srec from the bqEVSW software, but will look into that with another battery. Otherwise, the only recourse I have at this point is to continue running these tests and forwarding teh data to TI through this forum until our supplier is able to correct the situation. I am open to any other suggestions you may have on how to provide evidence to them. 

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Jeffrey,

    The easiest way that you can show that is by changing the chem ID to another one and comparing the 2 srecs. If you see a block that changes when you just change the chem ID, that will just be the OCV table and Ra table data. The Ra block will be at the end of the OCV block.

    This can conclusively prove data corruption.
  • 0 in reply to Batt
    Intellectual 510 points

    How do I go about pulling an srec file using bqEVSW 0.9.80? I found a method of programming an srec, but not pulling. 

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    You can open the programming tab and select export from the menu bar options.
  • 0 in reply to Batt
    Intellectual 510 points

    There is no export option in the menu bars of the programming section, only an option to read a .senc

  • 0 in reply to Jeffrey Chase
    Intellectual 510 points

    Batt,

    There is no function to pull an srec on the bqEVSW for the bq20z95 gas gauge, and it is not supported by bqStudio. What other options do I have to prove where the errors are to our supplier so they can work on fixing their process. 

  • 0 in reply to Jeffrey Chase
    TI__Genius 9410 points
    Hi Team,

    Can you please respond to Jeff's questions above? I am unable to run bqEVSW to check without the HW. How can the .srec be exported from the gauge?

    Thanks,
    Antonio
  • 0 in reply to Antonio Fadhel
    Intellectual 510 points

    Is there an option to have a small script that pulls the OCV tables from a battery and verifies it against the expected tables from the selected Chem ID that is a simple pass/fail test?

  • 0 in reply to Jeffrey Chase
    Intellectual 510 points

    Haven't heard anything on this in a couple of weeks. Just wanted to check in to see if there has been any progress in determining a way to verify OCV table data.

  • 0 in reply to Antonio Fadhel
    Intellectual 510 points

    Is there any progress?

  • 0 in reply to Antonio Fadhel
    Intellectual 510 points

    Still no response on how OCV tables can be verified on individual batteries after programming. Next step will be to start gathering data from failing batteries with suspected issue and uploading them. Up to approximately 25 batteries at this point. 

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Hi Jeffrey,

    Sorry, I had been on leave of absence for the past 2 months and this thread got dropped in the meantime. Allow me the next 2 days and I will respond to this thread. I will find out from fw engineers if there's a method to verify OCV tables off of senc files. The newer srec files allow you to do that easily but I don't see any being available for this part.
  • 0 in reply to Batt
    TI__Mastermind 42535 points
    Hi Jeffrey,

    On the old parts like the bq20z95, there is no way to verify your OCV table from an senc. The reason is because unlike an srec this file is encrypted. Also, unlike the newer bq9000 based gauges like the bq40z50 we don't have a chemistry checksum. However, in production after sealing the gauge will not allow the user to write df and will only write df itself. This way and with other df write protection features, we try to keep the static data accurate.

    Hope this helps.
  • 0 in reply to Batt
    Intellectual 510 points

    While I understand that the senc file is encrypted to protect the proprietary information within the OCV table, this doesn't really help my situation. As we are having the gas gauges programmed by the PCBA manufacturer, we have no control over incorrectly programmed tables. This leaves us in an awkward position in which we need to be able to reduce scrap, but can't due to the inability to verify that the tables were properly programmed.

    I would expect that the algorithm used to encrypt the data could be reversed to decrypt the data and compare to a golden file. It's not a matter of determining what the values are, only that they are correct. It seems that a small app could perform that function without compromising the proprietary nature of the data. If it is something you need a formal request from us to do, please let me know how to go about getting that done.

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points
    Jeffrey,

    Yes. I understand your situation. That was in fact one of the proposals I had to dump a hex file from an senc and then use that for comparison. However, the tools engineer for the project is on vaction. I have posted this to my manager to see if he can get a developer assigned to this. I should have a reply back to you in 3 days on this thread.
  • 0 in reply to Batt
    TI__Mastermind 42535 points

    Jeffrey,

    I talked to the fw manager. His suggestion is for you to go into fw upgrade mode and do a fw dump across all addresses. You can then use the hex dump from that to compare. As of now, TI has no tool for old parts that can do such a hex dump and they don't intend to get a tool to reverse the encryption.

  • 0 in reply to Batt
    Intellectual 510 points

    I'll give this a try. When you say go into fw upgrade mode, does that use the same steps as setting up to read a .senc file?

  • 0 in reply to Jeffrey Chase
    TI__Mastermind 42535 points

    That is correct.