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.

BQ27742-G1: Tab Disconnect fault before Over Temperature

Part Number: BQ27742-G1
Other Parts Discussed in Thread: BQSTUDIO

Hello,

I was testing the fault conditions on the BQ27742-G1, in particular the firmware ones given from calling "SafetyStatus(): 0x1A and 0x1B" (See Section 4.14.1 of the Technical Reference Manual)

The UVP, OVP fired as expected when I hooked up a battery simulator and brought it past the thresholds. However when raising the temperature with a heat gun to test for the OTC (or OTD) conditions, the TDD (Tab Disconnect) occurs first sometime around increasing past 100 degC (I converted the 0.1K to C) and then since it shuts down, I can never reach a OTC or OTD condition. I'm printing the temperature to a serial monitor and verifying it does increase as expected. 

Based on what I can read in the manual, I'm not seeing why TDD would occur in this scenario and why OTC would not. Can someone explain why this is occurring and how I can better test for OTC and OTD?

Best regards,
Christopher

  • Is it possible that the manual has a typo and the bit order of the Safety Status is incorrect?

  • The bit order is correct. I just checked both in bqStudio and in the FW source code. TDD depends on SOH and SOH is a function of temperature as well so it's possible that TDD gets set when you change temperature. OTC and OTD require that the gauge is either in charge or discharge state. Please make sure that this is the case in your test.

  • Alrighty. Thank you for verifying! I saw the bqStudio firmware file (.srec) but is the source code available in C or similar? I'm essentially rebuilding it from scratch since I don't want to rely on bqStudio or Windows as I've got several other components that I need to tie into the firmware.

    I'll log the SOH as well and see if that is in agreement with the switching of TDD.

    I recall there might be more things governing the "charge" or "discharge" state than this, but I thought it was charging based on the ~500mA draw shown by the battery simulator. I'll recheck all the constraints on what determines these states again today.

  • I just tested again while logging SOH, and found (StateOfHealth(): 0x2E and 0x2F) to return 0x62 (i.e. ~98%) constantly regardless of temperature, and even more strangle, regardless of voltage on battery simulator.

    According to the manual, "The [TDD] of Flags() is set when the ratio of current StateOfHealth() divided by the previous StateOfHealth() reported is less than TDD SOH Percent." With the default being 80%. Since 98% / 98% !< 80%, I'm a bit confused here.

    Here is the serial log showing the three steps (at 2 second polling interval) prior to the TDD arising:

    Voltage: 3960
    
    Temperature: 72
    
    SOH: 0x2e=62, 0x2f=00
    
    SOH: 0.980000
    
    No error detected in battery protection
    
    Voltage: 3960
    
    Temperature: 78
    
    SOH: 0x2e=62, 0x2f=00
    
    SOH: 0.980000
    
    No error detected in battery protection
    
    Voltage: 3960
    
    Temperature: 84
    
    SOH: 0x2e=62, 0x2f=00
    
    SOH: 0.980000
    
    Tab Disconnect condition detected
    

  • TI USA observes a holiday today so we'll answer on Monday.

  • The firmware sets SafetyStatus TDD only in one "if" statement and this statement is:

    if (newSOH < oldSOH*TDDSOHPcnt/100) ...

    So it looks like you are not reading newSOH and oldSOH as the gauge uses them or you are not reading the latest values (note that TDD won't get auto-cleared so the condition needs to be satisfied only once for TDD to be set).

  • Thank you very much Dominik for looking into that. Upon another review of the firmware on this end, I found a typo in the bit shifting that appears to have been the culprit. I.e. my log was stating TDD was set, when in fact OTC was set. The decoding of the byte was incorrect. Thank you for your time and sorry this ended up being an issue on our end!