• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 448 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.

BQ76952: Using different commands to turn on the discharge MOS tube has different delays

Jia Scofield
Prodigy 60 points
Part Number: BQ76952

Hi Expert，

Use Bq76952-02 to do the following test：

Use 0X0020(DSGTEST) Command to turn on discharge Mos tube Delay time : 1.2ms

Use 0X0022(FET_ENABLE) Command to turn on discharge Mos tube Delay time : 15ms

Use 0X0022(FET_ENABLE) Command to turn on discharge Mos tube Delay time : 150ms、

What are the main reasons for the above differences?

Is it possible to use 0X0020(DSGTEST) Command frequently?

The above is mainly to meet one function: when the device is powered off, it needs to turn on the mos tube to supply power within 35ms

  • 0
    TI__Guru* 81035 points

    Hi Jia,

    Before the FET_ENABLE command is sent, the device is in FET Test mode (FET_EN = 0) and only the FET Test commands can be used. This mode is intended for production test and is not recommended for use in the application. The test commands can enable the FETs very quickly, but there are some features like the transition from pre-discharge to discharge for example that are not supported in FET Test mode.

    In normal mode (FET_EN = 1), the time to disable the FETs is very fast, but the FETs are only enabled on a 250ms period - the device will evaluate whether all conditions are safe for the FETs to turn on at this time period. So it can take anywhere from 0ms to 250ms to enable the FETs depending on the timing of when the command is sent.

    Best regards,

    Matt

  • 0 in reply to Matt Sunna
    Prodigy 60 points

    In normal mode (FET_EN = 1),  it can take anywhere from 0ms to 250ms to enable the FETs depending on the timing of when the command is sent，it is not satisfied when the device is powered off, it needs to turn on the mos tube to supply power within 35ms，So I still consider using 0X0020(DSGTEST) Command when the device needs emergency power supply, but this function is not a commonly used function, and the number of times it is used is very small. Could you please tell me if there are any risks in doing so?

  • 0 in reply to Jia Scofield
    Prodigy 60 points

    Is there any way to shorten the delay of opening the MOS using the formal command (normal mode (FET_EN = 1))?Or can only be 0~250ms

  • 0 in reply to Jia Scofield
    TI__Guru* 81035 points

    Hi Jia,

    When FET_EN = 1, there is no way to shorten the delay for enabling the FETs.

    When FET_EN = 0, the main risk is that the device has not really been characterized for use in this mode. This could work, but you need to test this in your system to make sure it meets the needs of your application. 

    Regards,

    Matt

  • 0
    Prodigy 60 points

    Hello, 

    We would like to monitor the output voltage rising during predischarge mode to make sure we recognize shortcircuit on output asap. So we need precise information of when the PDSG fet is actually opened.

    Our current implementation of predischarge procedure (FET_EN = 1) is to send REG_ALL_FETS_ON command, and then periodically (each 2ms) read back the fet status (REG_FETStatus) to see when the PDSG fet actually opens so we can start checking if output voltage is rising. However we found out that also the information received from (REG_FETStatus) is not reliable. We found out, there can be a variable delay of up to 30 ms (from our tests) between received information that PDSG is ON and the moment when PDSG is actually ON. I have a scope picture of this but I couldn't upload it, I don't know why not.
    Is there some other possible method to know when the PDSG is actually opened? What is the maximal delay between received info of open PDSG and actual open? 

    We also had situations when info (from REG_FETStatus) was received that all fets are ON and then in next reading they were OFF and then ON again after 200ms (I assume this was actual opening of PDSG fet). See our logs below (readings from REG_FETStatus), notice the timings.

    [2236ms] [DEBUG] BQ FET all OFF
    [23081ms] [INFO] SM "Standby" --=> "PreDischarge"
    [23192ms] [DEBUG] BQ FET all ON
    [23201ms] [DEBUG] BQ PDSG: 1, DSG: 1, CHG: 1
    [23203ms] [DEBUG] BQ PDSG: 0, DSG: 0, CHG: 0
    [23387ms] [DEBUG] BQ PDSG: 0, DSG: 0, CHG: 0
    [23395ms] [DEBUG] BQ PDSG: 0, DSG: 0, CHG: 0
    [23399ms] [DEBUG] BQ PDSG: 1, DSG: 0, CHG: 1
    [23550ms] [DEBUG] BQ PDSG: 1, DSG: 1, CHG: 1
    [23585ms] [DEBUG] BQ PDSG: 1, DSG: 1, CHG: 1
    [23595ms] [DEBUG] BQ PDSG: 1, DSG: 1, CHG: 1
    [23597ms] [DEBUG] BQ PDSG: 1, DSG: 1, CHG: 1
    [23626ms] [DEBUG] BQ PDSG: 1, DSG: 1, CHG: 1
    [23737ms] [DEBUG] BQ FET all OFF
    [23739ms] [ERROR] SYS Predischarge timeout! voltage: 43562mV
    [23740ms] [ERROR] ERROR ERR: Precharge/PreDischarge
    [23781ms] [INFO] SM "PreDischarge" --=> "Error"
    [23882ms] [DEBUG] BQ FET all OFF

    Please help, 
    Best regards, Matej

  • 0 in reply to Matej Pinter
    Prodigy 60 points

    Hi again,

    I just want to explain our log printouts a little more. BQ FET all ON printout is when we send command REG_ALL_FETS_ON. BQ FET all OFF prinout is when we send command REG_ALL_FETS_OFF. Printout for fets status is: BQ PDSG: 1, DSG: 1, CHG: 1, this is read from REG_FETStatus and is printed everytime there is change in FET Status.
    Because PDSG fet is not turned OFF in time, we go in errror precharge.

    Best regards, Matej

  • 0 in reply to Matej Pinter
    TI__Guru* 81035 points

    Hi Matej,

    I do not know the maximum delay between the PDSG pin changing and the status register update. I don't really understand your log and terminology ("ERR: Precharge/PreDischarge").

    Also, this seems like a different question issue that is not related to this thread. I suggest starting a new thread for this question.

    Regards,

    Matt