• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 62 subscribers
  • Views 431 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: PCHG FET cannot be enabled

Jeff LaBundy
Intellectual 300 points
Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQ25798, BQSTUDIO, , BQ40Z50

Tool/software:

Hi there—we received a customer return with the note that the product cannot charge. I reproduced the issue, and found that our charger (BQ25798) elicits continuous VBAT OVP faults; this is confirmed by the following capture of VPACK:

This is typically a sign that neither the CHG FET nor the PCHG FET are closed, so I connected BQStudio to query the state of the gauge during the failure mode. There was no charging fault (XCHG = 0), and the only safety status (SS) fault was undervoltage (CUV = 1) which is expected:

The register map shows the gauge operates in precharge mode (PCHG = 1), which is expected given the pack voltage was roughly 2.3 V, and our precharge threshold is 2.5 V. When I probed the PCHG pin of the gauge, however, it was only 50–100 mV; this is far too low to enable the PCHG FET:

I then sent the FETControl command (0x0022) to disable FW control of the FETs, followed by PrechargeFETToggle (0x001E) to forcibly enable the PCHG FET. The manufacturing status register changed from 0x0018 (FET_EN = GAUGE_EN = 1) to 0x0009 (FET_EN = 0, GAUGE_EN = PCHG_TEST = 1), but the PCHG pin of the gauge remained 50–100 mV as above.

I then sent PrechargeFETToggle (0x001E) once more to forcibly disable the PCHG FET. The manufacturing register changed to 0x0008 (FET_EN = PCHG_TEST = 0, GAUGE_EN = 1), and the PCHG pin of the gauge was pulled up as follows:

My naive assumption is that there is some sort of HW problem here—is there any other explanation for why the gauge cannot drive the gate of the PCHG FET?

The schematic of our pack is identical to figure 9-1 of the BQ40Z50-R2 datasheet, modified according to the datasheet for a 1S design. Our golden file is linked here: 6683.gg.csv

In case I can provide any additional information, please let me know. Thank you in advance!

  • 0
    TI__Mastermind 29125 points

    Hi Jeff,

    Jeff LaBundy said:

    I then sent PrechargeFETToggle (0x001E) once more to forcibly disable the PCHG FET. The manufacturing register changed to 0x0008 (FET_EN = PCHG_TEST = 0, GAUGE_EN = 1), and the PCHG pin of the gauge was pulled up as follows:

    When this was done, was FET_EN still cleared? Is there any change in the performance if a reset is sent?

    Also, is XDSG still set at this time?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 300 points

    Hi Anthony—thank you for your prompt support! I've root-caused this issue, but I still need some help to implement a workaround. In response to your questions:

    Anthony said:
    When this was done, was FET_EN still cleared? Is there any change in the performance if a reset is sent?

    I can confirm that FET_EN remained clear while I sent the PrechargeFETToggle command (0x001E) to manually control the PCHG FET. Prior to this experiment, I sent the FETControl command (0x0022) to enable manual control.

    The behavior does not change if I send the DeviceReset command (0x0041).

    Anthony said:

    Also, is XDSG still set at this time?

    XDSG is set in both manual mode (FET_EN = 0) and automatic mode (FET_EN = 1); this is expected, as the gauge is in CUV. XCHG is set only in manual mode (FET_EN = 0) while both the CHG and PCHG FETs are disabled (CHG_TEST = PCHG_TEST = 0).

    After investigating this further, however, I realized that the PCHG FET is in fact a PMOS, and the datasheet gate drive voltages are understandably specified as VCC - VPCHG. Therefore, the gate drive voltages I measured in both manual mode (FET_EN = 0) and automatic mode (FET_EN = 1) are expected, and the gauge is operating as designed.

    The question then becomes why the BQ25798 cannot push current into the battery and repeatedly triggers an OVP fault, even though the PCHG FET is conducting.

    On a hunch, I shorted across the precharge current-limiting resistor (R1 in figure 9-1 of the BQ40Z50-R2 datasheet), and the battery can charge normally. I loosely suspect the BQ25798 may act as a weak constant-current source in precharge mode, and cannot overcome R1.

    This phenomenon seems specific to BQ25798, so I'll start a separate thread for that topic. In the meantime, we need to chase down a couple questions specific to the pack itself:

    [1] It remains a mystery to us how the battery self-discharged down to 2.3 V. The CUV protection (2.8 V) appears to operate as expected, so any leakage path must be upstream of the gauge.

    I loosely suspect one or more cell(s) may defective, and they will be returned to the vendor for FA; no further support from TI is needed. If you have any additional ideas based on your experience with other customers however, please let me know.

    [2] In the meantime, we're left with this issue of not being able to charge the pack when both it and the BQ25798 are in precharge mode, and R1 is in between the two.

    I think one workaround is to set PCHG_COMM in the FET Options register such that the CHG FET is used in precharge mode, effectively bypassing R1. When I set this field in BQStudio and click the write button, however, BQStudio returns a read verification error, and the field remains clear.

    Is there any sequence I must follow to set PCHG_COMM, or are there any conditions under which it cannot be set? Alternatively, are there any other workarounds I can use to effectively bypass the precharge path of the gauge?

    Thanks again for your continued support—in case I can provide any additional information, please let me know.

  • 0 in reply to Jeff LaBundy
    TI__Mastermind 29125 points

    Hi Jeff,

    Jeff LaBundy said:

    [1] It remains a mystery to us how the battery self-discharged down to 2.3 V. The CUV protection (2.8 V) appears to operate as expected, so any leakage path must be upstream of the gauge.

    I loosely suspect one or more cell(s) may defective, and they will be returned to the vendor for FA; no further support from TI is needed. If you have any additional ideas based on your experience with other customers however, please let me know.

    I agree with your thinking here. With the CUV protection operating as suspected and DSG fet disabled, there should be no current flow moving outwards to the pack connection, meaning the root cause is most likely somewhere on the battery connection side of the fets. 

    Jeff LaBundy said:

    [2] In the meantime, we're left with this issue of not being able to charge the pack when both it and the BQ25798 are in precharge mode, and R1 is in between the two.

    I think one workaround is to set PCHG_COMM in the FET Options register such that the CHG FET is used in precharge mode, effectively bypassing R1. When I set this field in BQStudio and click the write button, however, BQStudio returns a read verification error, and the field remains clear.

    Is there any sequence I must follow to set PCHG_COMM, or are there any conditions under which it cannot be set? Alternatively, are there any other workarounds I can use to effectively bypass the precharge path of the gauge?

    I believe that using the CHG FET for precharge here would be a viable option to get around the PCHG resistor issue. If you can check a couple things for me:

    - Is the gauge in a full access unsealed state?

    - Is Auto-Refresh on at this time? (if so, turn it off)

    - Does this happen to other data flash parameters if they are attempted to be changed?

    You can also try putting the device through a power on reset, or reflashing the .srec (if there haven't been any other changes) to see if there is any change in the behavior.

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 300 points

    Hi Anthony—thank you for your continued support; I am aligned with you on [1].

    Regarding [2]—as far as I know, the pack is in an unsealed and full-access state. The entire register view is shown below; please let me know in case I am mistaken:

    The specific error is shown below:

    I set this field on a known-good pack, and the write was successful. Is it possible some precharge-related fields cannot be modified while the gauge is in precharge mode, or the flash cannot be written while a safety status field is set? Just one more question for now:

    [3] According to my understanding, setting PCHG_COMM only impacts which FET is enabled during precharge mode. The PCHGC protection mechanism is still active, and relies on the precharge current threshold, delay and recovery fields even though the CHG FET is in use.

    In case I have misunderstood, or I can provide any additional information, please let me know.

  • 0 in reply to Jeff LaBundy
    TI__Mastermind 29125 points

    Hi Jeff,

    Jeff LaBundy said:
    Regarding [2]—as far as I know, the pack is in an unsealed and full-access state

    Confirmed. Thanks for sending the image.

    Jeff LaBundy said:
    I set this field on a known-good pack, and the write was successful. Is it possible some precharge-related fields cannot be modified while the gauge is in precharge mode, or the flash cannot be written while a safety status field is set? Just one more question for now:

    I believe if the gauge is in a fully unsealed state, then it should be able to be written to even if there is a firmware protection triggered. I see in those images that bqStudio isn't properly getting the firmware version of the device (seen by the fffffa5 sequence under bq40z50 on the left), what is getting populated there when a known-good pack is attached? 

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 300 points

    Hi Anthony—thank you for the update; that's good to know. What about power supply requirements with respect to writing to the flash? Is there a minimum VCC level required for a write to be executed? Maybe the gauge protects itself from corruption, or the write simply failed internally.

    The reason I ask is because in this case, the voltage at VCC is relatively low (2.2–2.4 V), and there is effectively no voltage at PACK due to the unrelated problem with our constant-current charger. Neither of these issues exist with the known-good pack I tried.

    The variation of 0xFFA5 shown in BQStudio is a great catch, but I think it's a red herring. This happens even for known-good packs, and I loosely suspect this is a bug in how BQStudio reads the device ID for BQ40Z50.

    The value of 0xFFA5 is a special value that the ManufacturerAccess register (0x00) may return after the FirmwareVersion command (0x0002) is sent. I think this is part of a legacy feature hidden within BQ40Z50, and I recall we encountered it in this thread.

    Thanks again for your continued support—in case I can provide any additional information, please let me know.

  • +1 in reply to Jeff LaBundy
    TI__Mastermind 29125 points

    Hi Jeff,

    Jeff LaBundy said:

    Hi Anthony—thank you for the update; that's good to know. What about power supply requirements with respect to writing to the flash? Is there a minimum VCC level required for a write to be executed? Maybe the gauge protects itself from corruption, or the write simply failed internally.

    The reason I ask is because in this case, the voltage at VCC is relatively low (2.2–2.4 V), and there is effectively no voltage at PACK due to the unrelated problem with our constant-current charger. Neither of these issues exist with the known-good pack I tried.

    There is, the threshold value for this is the Valid Update Voltage seen below, which is 3500mV. Please try raising the voltage at VCC and see if this error is still apparent:

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 300 points

    Hi Anthony—thank you for the update; acknowledged on all counts.

    I had to get the original pack on its way back to the vendor already, so I won't be able to perform this final test—however, I think we can be reasonably confident the low voltage was the reason for the inability write the flash in this case.

    Thanks again for your continued support—in case I have any additional questions, I will start a new thread. Have a great weekend!