• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 35 subscribers
  • Views 331 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.

BQ40Z50-R2: Fuse failure with SOTC parameter, is TSint taken into account like TS1-4

Cedric Milleret
Intellectual 280 points

Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQ40Z50, BQ2947

Hello,


Regarding the use of protections and permanent fails in the context of temperature, I have a question about the detection and action taken on the fuse with respect to the TSInt variable.

I am using the 4 cells and the internal temperature (activated).

- In the settings, when referring to the cells, cells 1-4 are specified in several paragraphs, but also the internal temperature "TSInt", which suggests that TS1-4 and TSInt may have an internal "link" for FW processing.

- TS1-4 explicitly refers to the cells, while TSInt is an internal chip temperature, the use of which is unrestricted.

- In the protection configuration, SOTC and SOTF are differentiated for the cells and the FET, but TSInt is not specified.

I recently experienced an unexplained fuse blown (no cell-related event) with an active PF, and according to the log history, I had a "high" internal TSInt temperature that corresponds to the cell threshold. This internal temperature (i.e., the chip) is on a PCB that integrates the charge converter (which therefore heats up), but is not directly related to the cell temperature. I am therefore wondering if the TSInt temperature could be interpreted in conjunction with the TS1-4 cell temperature in the SOTC configuration?

Regards

CM

  • 0
    TI__Mastermind 37981 points

    Hello CM,

    This question has been assigned to our bq40z50 expert, please allow some time for him to get back to you.

    Regards,

    Adrian

  • 0 in reply to Adrian
    Intellectual 280 points

    Hello,
    Have you made any progress on this issue?

    Regards

    CM

  • 0 in reply to Cedric Milleret
    Intellectual 280 points

    Hello,

    Following the analysis of two .gg files (two faulty BMUs), here are a few observations to help pinpoint my problem:

    - Operation Status [FUSE] is high, then the fuse blows
    - PF Status doesn't seem to indicate anything unusual
    - lifetimes: there doesn't appear to be anything



    In the configuration, I have:

    - SETTINGS \ CFG \ FET OPTIONS: [PACK_FUSE] = 0 (battery stack)
    - SETTINGS \ CFG \ T° enabled: TS1 to 4 and Int
    - SETTINGS \ CFG \ T° mode: TS1 to 4 = cells, TSint = FET
    - PF A, B, C, D: apparently a standard configuration
    I don't see anything abnormal, neither in the voltage levels nor the temperatures

    Therefore, I don't understand what tripped the fuse. Have I missed something obvious?

    Regards,

    data memory_fuse_blow_card1.gg.csv

    data memory_fuse_blow_card2.gg.csv

    CM

  • 0 in reply to Cedric Milleret
    Intellectual 280 points

    Hello,
    I continued my investigations and noticed something very interesting.

    For context, the bq40Z50 is associated with the bq2947 monitoring circuit (as in the EVM, same schematics). The fuse is therefore controlled by the two circuits separately.

    I noticed that the FUSE bit (Operation Status A) indicates not only the internal state of the FW, but also the external state (I imagine the FUSE pin has an auto-sampled input mode). I do some HW manipulation to see HW and FW state

    This led me down the wrong path because I only use FUSE as an output, and the 2LVL setting (settings/PF) is indeed disabled.



    Furthermore, according to the documentation, if 2LVL is 0, it prevents FUSE from being displayed.



    Apparently, this isn't the case, but which FUSE state are we actually talking about: [FUSE] (operation status A) or [2LVL] (PF status C)?

    It's not clear

    Regards

    CM

  • 0 in reply to Cedric Milleret
    TI__Genius 9805 points

    Hello Cedric,

    Are you able to repeat this setup at will? If so, can you try again with the Tsint disabled? It makes sense if you have another IC close to the FG (Fuel gauge), then the FG might start to get hotter, so the Tsint starts to detect the increase in temeperature. 

    Do you have secondary protector in addition to the FG in your system?

    Regards,

    -Miguel

  • 0 in reply to Miguel Castro Gonzalez
    Intellectual 280 points

    Hello,

    a) As stated at the beginning of the ticket, I observed the problem on two boards in service. This is not a lab qualification test.

    b) To investigate, a test would need to be set up and some boards sacrificed.

    c) As stated at the beginning of the ticket, the PCB supporting the chip gauge can heat up via other components such as the charger supply. The Tsint measurement therefore detects heat, but detection does not necessarily mean it reacts according to the configuration; I found nothing abnormal in the thresholds.

    d) As stated in the ticket, I have a BQ2947 monitoring chip such as the EVM (TI demo board). However, the "PF FUSE C" configuration has the FUSE and 2LVL bits disabled, which, it seems to me, should not be taken into account, but I have my doubts about this (like screenshot)...

    Regards,

    CM

  • 0 in reply to Cedric Milleret
    TI__Genius 9805 points

    Hello Credic,

    I will try to run an experiment on my desk, but based on the TRM, all sensors are taken into account. 

    By any chance, do you know any other PF protections that might have set. The PF might not save the event if it is too fast, so even if the PF event happens, there is no guarantee the guage will catch it. If the gauge catches it, then we are 100% sure of what it might have been.

    -Miguel 

  • 0 in reply to Miguel Castro Gonzalez
    Intellectual 280 points

    Hello,

    Given that the analysis was done two months ago, the cards are no longer in the same condition. I've disassembled, inspected, repaired, and reconfigured them.

    At the beginning of this support ticket, I attached the gg.csv files; I don't have any more.
    These files show the status of the recordings.

    If the PF recordings are unreliable, it is indeed a functional problem I hadn't suspected. However, these BMUs were used in a very standard context (far from any potentially harsh conditions), so nothing suggests any suspicious faults (such as over/under voltage, current, or temperature).

    That's why my investigation focused on the 2LVL.

    Regards,

    CM

  • 0 in reply to Cedric Milleret
    TI__Genius 9805 points

    Hello Cedric,

    To answer your question, TSInt does in conjunction impact the decision making of the FW. 

    I did a quick experiment where I disabled all the temperature sensors but Tsint (Temperature Enabled = 0x1). I force a voltage on other sensors to make it think the device is at 100C. With only Tsint, the protections for overtemperature do not trigger.

    -Miguel

  • 0 in reply to Miguel Castro Gonzalez
    Intellectual 280 points

    Hello,
    Noted.

    However, this test only indicates that the deactivated cell probes do not cause a fault, which is quite normal and expected, as it's the direct functionality.

    This doesn't say whether Tsint has any influence since its temperature remains at 23°C.

    Similarly, the questions regarding 2LVL remain unanswered.

    Regards

    CM