• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Answers 6 answers
  • Subscribers 63 subscribers
  • Views 437 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.

BQ35100: SOH value stored in the Data Memory

Ryotaro Fukui
Intellectual 2345 points
Part Number: BQ35100

Hello team,

My customer has a question about BQ35100, SOH data.

The BQ35100 has a built-in ROM, and the number of rewrites is specified to be 20,000 times. And the SOH value stored in the Data Memory does not seem to disappear when the power is turned off (This means, SOH value should be written in ROM).

Assuming that the number of rewrites in the SOH area is min 20,000 times, if you try to keep it for 3 years, it can be calculated as 20,000 times / 365 days / 3 years = 18.3 times. In other words, measurement of SOH should be less then only 18 times a day. Is this correct?

If there are information like following, they would like to know it:
"The SOH data is also written in RAM, so it does not disappear unless the power is turned off".
It is acceptable for this product to reach 100% after the power is turned off.

I am looking forward to hearing from you.

Best Regards,
Ryotaro Fukui

  • 0
    TI__Guru** 105590 points

    Hello Fukui-san,

    I believe you are referring to the data flash (DF) memory of the gauge, Yes during the sequence to capture SOH data the value will be saved to DF.

    The SOH is written to RAM first before DF that's correct. When the sequence of "gauge_stop" is reached the gauge saves the values to DF.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    Sorry for the late reply. My customer got some additional concerns about the previous answer.

    Writing Step1. Store SOH in RAM

    Writing Step2. Store in DF with gauge_stop

     

    What will happen when you write after reaching 20,000 times?

    They assumed that ROM cannot be written when it reaches 20,000 times. Will SOH acquisition perform correctly after this?

     

    ・ Does an error occur and stop when writing to DF is not possible?

    ・ If the previous measured SOH would be read from the DF at Step 1 without stopping, it means the read value will  not be updated. They have a concern that the correct value cannot be obtained.

     

    And, in order to prevent this, is it possible to set registers so that the SOH capture result will not be written to ROM?

    Sincerely,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    The gauge will only save the data when you send the gauge stop command, the gauge won't prevent any flash writes after 20,000, this is just the minimum number that it will be reliable, after 20,000 some of the data cells may not hold charge as well and become corrupted.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    So, in order to prevent malfunctions, they should operate so that the number of writes does not exceed 20,000.

    As a confirmation, was the gauge stop command refers to the sequence of "gauge_stop"?
    (SOH measurement stops at GE terminal H → L, but is it okay to think that it is not written to DF yet at that point?)

    Sincerely,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    Yes, that's the same for all of our gauges dataflash.

    Actually I just verified the gauge_stop is only for ACC mode, in SOH it will update every time the GE pin is toggled.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    Thanks for correcting.

    For confirmation, minimum reliable number is 20,000 times in SOH mode too, right? (Also want to confirm that ROM writing cannot be stopped in SOH mode too)


    ■ Can ROM writing be stopped? Question Backgrounds
    The maximum amount of change in SOH is 2% by default. Assuming that the number of rewrites is 20,000, it can only measure 18 times / day (25 ° C) with a 3-year life.

    When the temperature fluctuates, the battery voltage fluctuates, so it is necessary to activate New Battery command frequently in order to correctly grasp the SOH.
    However, with batteries with low SOH, the number of measurements by GE increases, so 20,000 times can be reached quickly.

    On the other hand, does SOH need to be written to ROM?
    If the battery is removed and restarted, it is natural to think that the battery has been replaced, and I don't think it is necessary to keep the SOH.

    Are there a way to use the SOH value in RAM?

    Sincerely,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    Yes, 20,000 is always the minimum number of writes we say the data flash is good for, it could last longer but that's the minimum.

    The new battery command should only be used when you insert a new battery, you don't need to send it multiple times in any mode.

    I confirmed with another team member that the gauge will update each time GE is cycled in SOH mode, unless the value is not changed then it isn't written to DF.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    Thank you for the advice. However, sorry for the confusing description about the new battery. What they want to know is that,

    • "Is there a way to operate it without writing SOH data to the DF?"

    Since it is operated for a long period of time, the number of writes will soon reach the Max. Therefore, it seems that they are considering whether it is possible to complete the processing such as calculation only with the data in RAM without saving it in DF.

    If it is not possible, please let me know if there is a workaround to reach the maximum value.

    Sincerely,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    As I mentioned, the SOH will not be written to DF unless it changes, so if the battery was replaced 200 times and the SOH DF was updated at every percentage point (it's an integer) then it would be at the 20,000 limit. The other calculations are saved in RAM and SOH is only saved in DF IF it changes.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    I had misunderstood about SOH until now. The data was an integer.

    If it is 100 (%) * 200 (batteries) = 20000 (writes), it seems that it can be used for a very long time.

    Since it seems to function for such a long time, I think the customer's concern about writing will be resolved.

    Thank you for all your advice.

    Sincerely,
    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Intellectual 2345 points

    Hello Keller-san,

    Sorry, just one more quick question.

    Looking at Figure 6-2 of the Reference Manual (page 26), there is a branch of "Are DF Updates enabled?" in the Data update Phase.

    Is it possible to disable this by register value or FW setting?

    I'm guessing that "6.2 Flash Updates" on page 27 is relevant, is that correct?

    www.tij.co.jp/.../sluubh1c.pdf

    I saw the description, but couldn't find out how to disable it.

    Sincerely,
    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    I believe that is most likely internally used parameter, and like I mentioned you can decide if the DF is written in accumulation mode, and in SOH the DF should last for hundreds of battery replacements.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    Sorry, I was misunderstanding. This inquiry was similar to what you answered before.

    Thank you for reminding me.

    Best Regards,
    Ryotaro Fukui

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    I received few more additional questions from our customers. I would be grateful if you could give me some advice too.

    Related to the previous question, about the definition of 20000 times (writes) in 6.13 Data Flash Memory,
    (1) It says 20000 times are "Specified by design. Not tested in production", but could you tell me the actual result case if there are any? (approximate value is fine, it does not have to be the guaranteed value)
    (2) They think that the number of 20000 times will decrease as the temperature rises. In general, they think that it will decrease with the Arrhenius approximation (10 ° C double speed), but is this product also applicable?

    Sincerely,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    The 20,000 value is the minimum by design, so chances are it will last much longer. I'm not aware of any tests done to verify, because the DF could last much longer.

    I don't think it is applicable for this case, if it is within the recommended operating range for temperature the minimum number of writes is 20,000. If they go outside the recommended operating range then nothing is specified for that.

    Sincerely,

    Wyatt Keller 

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    The customer is planning to execute the New Battery command for each measurement in order to correctly know the SOH, in order to match the discharge curve in the IC with the battery discharge curve even if there is a temperature fluctuation. Is this usage effective?

    If so, please also answer the following questions.

    • They think that the data on the DF is initialized every time the New Battery is executed, but in this case of use, should they think that the minimum execution limit of the New Battery is 20000 times?
    • Also, if there are any problems with the above usage, other than the life of the IC, they would like to know it.

    Sincerely,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    The new battery command should not be sent each time they need to take an SOH measurement.

    You can refer to the app note here: www.ti.com/.../slua904.pdf

    0.11.1 SOH Mode Fundamentals

    SOH mode takes in the battery voltage and temperature. The gauge uses these two values and references them to the OCV lookup table in order to determine the SOH. One important variable to adjust in the Gas Gauging sidebar is the” Sate of Health Max Delta”. This variable determines by how much you SOH can change with every cycle of the GE pin. If you plan on sampling very frequently and reading the voltage lower values will work. However, if your delta value is low and the voltage drops very suddenly you will not observe a change immediately but rather it will take multiple cycles to catch up to the new voltage.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    I told the customer that the measurement using the New battery command is a special and deprecated usage, but it seems they want to stick with it because of the design.
    I'm sorry that their requests are irregular, but I want your advice for the following questions if possible.

    They plan to use the New battery command to measure once a day.
    On top of that, they intends to solve the cycle problem by maximizing the SOH Max delta.
    Are there any disadvantages to increasing Max delta?
    By the way, if the value changes significantly, they are willing to avoid saving it programmatically.

    Also, they are thinking of reducing the number of writes by executing the New battery command multiple times with GE kept High.
    Will the data be stored in DF exactly the moment GE goes high? Or is the write complete every time they run a New battery with GE kept high?

    I'm sorry that questions are all about special usage, but I would like you to answer if it is feasible.

    Best Regards,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    I would not recommend using the new_battery command each time they turn the gauge on with the max delta increased. This is not the intended use for this mode.

    If they plan to keep sending the new battery command I believe this will wear the DF out quicker because it will write the SOH and then clear it on each wakeup. By using it based on intended operation the DF will only update if the SOH changed from the last measurement.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 2345 points

    Hello Keller-san,

    We are currently convincing our customers to stick to the recommended usage.

    However, they have already planned using the method described above, and it seems that in this stage, they need to explain the end users why the change is necessary. He wants us to provide clear persuasive material as to why the change of usage must be made.

    • Since the New Battery command is scheduled to be used 3 times a day, and with the current settings, the write limit will not exceed 20000 times for 1 year of use. Any reason they can explain that they should stick to the recommended usage?
    • And other issues that might occur, else than the ware out speed of Data Flash

    They are already in their production stage and I don't think they'll be convinced by just telling them it's not recommended, so I think it's a strange question, but I'd appreciate it if you could give me some advice.

    Best Regards,

    Ryotaro Fukui

  • 0 in reply to Ryotaro Fukui
    TI__Guru** 105590 points

    Hello Fukui-san,

    If they aren't planning to use the gauge for longer than a few years it should be okay, but if they increase the max delta for SOH it can lead to large changes if they take a measurement when the batteries aren't fully relaxed.

    Sincerely,

    Wyatt Keller