• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 327 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

BQ27Z561: Can BQ27Z561 support 0.75m ohm sense resistor?

BQ27Z561-R1: Checksum Valid

Ryan Wang
Expert 6050 points
Part Number: BQ27Z561-R1
Other Parts Discussed in Thread: BQSTUDIO, BQ27Z561

Dear expert,

What is PF condition?

BQ27Z561R1 will monitor voltage and disable flash write? What voltage level will trigger this?

Thanks

In ControlStatus() CheckSumValid (Bit 9): Checksum Valid
1 = Flash Writes are enabled.
0 = Flash Writes are disabled due to low voltage or PF condition.

  • 0
    TI__Expert 6050 points

    Dear expert,

    Customer has built 300pcs board. 3pcs BQ27Z561R1 ControlStatus CheckSumValid (Bit 9) become 0 after some days running. Their flash cannot be written from either host or BQtudio.

    Need your guidance what might cause  CheckSumValid become 0.

  • 0 in reply to Ryan Wang
    TI__Expert 8245 points

    Hi Ryan,

    PF condition can refer to a variety of Permanent Fail conditions related to Current, Voltage, or Temperature. Either some PF is being triggered or the battery voltage is too low. If you can provide a .log file of when this happens I can take a look and see the status of all PF registers and the cell voltage.

    Thanks,

    Jackson

  • 0 in reply to Jackson DiGiovanna
    TI__Expert 6050 points

    Jackson,

    I will send you log today.

    Can we disable this CheckSumValid to do a test?

    Is 0X00  /  0X01  ManufacturerAccess()  /  ControlStatus     register writable? 

    We find even we cannot write bqstudio data memory but we still can reprogram whole srec file. Is it expected? And after srec reprogramed, CheckSumValid  is still 0, data memory stil cannot be written.

    Flash use 1.8V of internal LDO to program or some internal high voltage?

    Thanks

  • 0 in reply to Ryan Wang
    TI__Expert 6050 points

    Jackson,

    BTW, When the phenomenon happen, it is permanent in customer system. After we resolder the silicon to TI EVM it appears "sealed" status and become normal after we unseal it.

  • 0 in reply to Ryan Wang
    TI__Expert 6050 points

    Jackson,

    At customer environment, sometimes their battery might drop to 2.3V, external NTC might doesn't connect during test setup. But when everything back normal, CheckSumValid=0 should not be permanent , right?

  • 0 in reply to Ryan Wang
    TI__Expert 6050 points

    Jackson,

    sorry for so many questions, customer mass production process is pending for this issue.

    CheckSumValid is set to 0 when gauge monitors some hardware(voltage, current, temperature) failure or it calculate flash data checksum failure during flash write operation?

    Is there any threshold for voltage, current, temperature?

    Thanks

  • 0 in reply to Ryan Wang
    TI__Expert 6050 points

    Jackson,

    There are 3 pcs this kind of BQ27Z561R1. One of them phenomenon is gone after "soft reset" (CheckSumValid back to 1 and data memory can be written). But after around 40 min, the problem happen again. Below is the log during this 40 min.  GG file is also attached.

    Other two BQ27Z561R1 phenomenon is permanent. They can only be recovered by reprograming srec file in TI EVM.

    Thanks

    2#--fcc-yichang--1711.log

    reg-log--2#--fcc-yichang--1713.gg.csv

  • 0 in reply to Ryan Wang
    TI__Expert 6050 points

    Jackson,

    Because customer cannot stop mass production, they want to know the risk. If flash cannot be written in the field, does our gauging algorithm need write flash frequently? Or our algorithm only run at RAM, then this won't impact end customer too much, correct?

  • 0 in reply to Ryan Wang
    TI__Expert 8245 points

    Hey Ryan,

    Sorry for just getting to this now. Let me take a deep look at all of these questions first thing tomorrow so I have time to get back to you with in depth answers to all of your questions.

    Thanks,

    Jackson

  • 0 in reply to Jackson DiGiovanna
    TI__Expert 6050 points

    Jackson,

    Because customer mass production is pending due to this issue, they wish to have a concall with you on your next Monday. 

    Is it possible?

    Great thanks

  • 0 in reply to Ryan Wang
    TI__Expert 8245 points

    Sure thing Ryan,

    I am free Monday afternoon. Feel free to set a meeting up on my calendar and we can discuss all of these questions. 

    Best Regards,

    Jackson

  • 0 in reply to Jackson DiGiovanna
    TI__Expert 6050 points

    Jackson,

    I will book your calendar.

    Still need you provide all above questions answers in advance to improve meeting efficiency.

    Thanks

  • 0 in reply to Ryan Wang
    TI__Expert 8245 points

    Hey Ryan,

    Let me try to summarize some info here.

    Writing the data flash directly is not possible. Attempting to do so may be what is causing this error. When changing the values directly in BQStudio, there is an underlying sequence that writes the value to the physical parameter address. The process for writing to change data flash values can be seen in section 13.2.48 of the BQ27Z561 TRM. To address the customers concern, flash can be written in the field, it is just not done in the same manner as when wishing to read block of data.

    In terms of the PF concerns, if the battery voltage drops to 2.3V, this could trigger a PF which will fully lock the device from being written to or from charging/discharging. This will only happen if PFs are enabled.

    Thanks, and I look forward to discussing with you on the call tomorrow,

    Jackson

  • 0 in reply to Jackson DiGiovanna
    TI__Expert 6050 points

    Jackson,

    Really appreciate concall with you at your mid-night.

    Need your help for below questions during the call:

    1. The purpose of 5ohm resistor in front of Vbat in TI EVM.

    2. If customer set "valid update voltage" to like 1.5V, is it not safe for Flash write protection?

    3. What period AVG_I_LAST_RUN is calculated and updated? Is it updated every time when SoC reach 0? Average for one discharge cycle?

    Great thanks

  • 0 in reply to Ryan Wang
    TI__Expert 8245 points

    Hi Ryan,

    I consulted my team today and have some clarification on these questions.


    1. The purpose of this 10ohm resistor is to limit inrush current into the capacitor. The capacitor is a design requirements on the BAT pin for the device to operate reliably and the 10ohm resistor protects against any large underdamped voltage overshoot on the BAT pin caused by some parasitic inductance from initially connecting the battery. This is also the reason for the BAT_SNS pin. To make sure the measurement is accurate and it is ignoring the voltage drop across the 10ohm resistor on BAT, the battery is connected directly to the BAT_SNS pin.

    2. The LDO is operational until 1.7V so setting the value of "valid update voltage" to 1.7V should be low enough to not trigger the checksum valid bit while also being high enough so that the chip is still functional.

     
    3. AVG_I_LAST_RUN updates so long as the discharge has been long enough to cross a gridpoint update for impedance. To clarify, the 14 Ra table values are all updated according to DOD gridpoints that are predefined. When the DOD reaches a certain level, the gauge will determine the cell impedance at that level and update the Ra table. Once this happens, the gauge will update AVG_I_LAST_RUN upon exiting discharge mode. So the trigger for the update is exiting discharge mode (at any time into relax or chg mode) and the gating condition is if a gridpoint was crossed during that discharge and an Ra table value was updated.

    Hope this clears it all up

    Best Regards,

    Jackson

  • 0 in reply to Jackson DiGiovanna
    TI__Expert 6050 points

    Great thanks, Jackson