Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 66 subscribers
  • Views 1459 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.

BQ76952: Need clarification on DDSG and DCHG operation

Manuj Agrawal1
Prodigy 175 points
Part Number: BQ76952

Hi,

The highlighted text in table 5-8, about using OFF() commands and CFETOFF/DFETOFF pins after microcontroller receiving interrupts from the DDSG and DCHG pins, contradicts highlighted text in section 12.9 of the datasheet. Could anyone please clarify why commands should not be used when the pins are in DDSG/DCHG mode.

  • 0
    TI__Guru* 80543 points

    Hi Manuj,

    Thanks for pointing this out to us. In the highlighted text in section 12.9 of the TRM, the "through commands" option needs to be removed. If DCHG and DDSG are used as interrupts to the host MCU, then the MCU should control the FETs using CFETOFF and DFETOFF (or BOTHOFF) pins.

    If the ALERT pin is used as an interrupt to the MCU, then the host FET commands are fine to use. The host MCU would read the AlarmStatus register to determine what caused the Alarm signal to assert.

    Here is a brief explanation why you should not use DDSG and DCHG as interrupts in combination with the host FET commands:

    • If both FET drivers are enabled (such that both DDSG and DCHG are deasserted) and the host sends the DSG_PDSG_OFF() subcommand or the FET_CONTROL() subcommand to disable DSG and keep CHG enabled:
      • the DSG FET is disabled,
      • the DDSG signal is asserted,
      • the CHG FET remains enabled,
      • the DCHG signal will assert briefly for up to 250ms.
    • Similarly, if both FET drivers are enabled (such that both DDSG and DCHG are deasserted) and the host sends the CHG_PCHG_OFF() subcommand or the FET_CONTROL() subcommand to disable CHG and keep DSG enabled:
      • the CHG FET is disabled,
      • the DCHG signal is asserted,
      • the DSG FET remains enabled,
      • the DDSG signal will assert briefly for up to 250ms.

    Best regards,

    Matt

  • 0 in reply to Matt Sunna
    TI__Intellectual 2655 points

    Hi Matt,

    Could you help further explain why DCHG signal will assert briefly for up to 250ms? And why the interval would change within 250ms, not a fixed value?  

    Why only DDSG signal assert, while DCHG would not assert when a CUV event happened? Thanks!

    Sincerely,

    Jayden-Li

  • 0 in reply to Jayden Li
    TI__Expert 4090 points

    Hi Jayden-Li,

    The timing varies because the device runs a regular check every 250ms in NORMAL mode.  When DCHG is asserted briefly in this case, it begins when the command is sent, then it is deasserted when the device runs its next regular check.  So if the command is sent just before a check occurs, the pin will only be asserted a short time.  If the command is sent just after a check occurred, then the pin will be asserted almost an entire 250ms before the next check.

    Regarding a CUV event - this means the cell is overly discharged and needs to be charged.  So it makes sense to disable the dsg path (to prevent further discharge) and enable the chg path (so a charger could be attached and charge the cell back up again).

    Thanks,

    Terry

  • 0 in reply to -Terry
    TI__Intellectual 2655 points

    Hi Terry,

    Very appreciated for your reply!

    But I still don't understand why DSG_PDSG_OFF() is sent, then the DCHG signal will assert for up to 250ms at the same time that the DDSG signal is asserted? Since the DDSG signal is asserted, which indicated that the subcommand has been recieved by BQ76952. So what is the control logic?

    In my mind, the DCHG should remain it's state, because I just want to turn off the DSG, not the CHG. What is the intention of this response logic? And could it be avoided through configuration? If no, how could customer do to prevent this event?

    For a CUV event, I know the CHG should keep ON, so a charger could be attached and charge the cell back up again. But if the response logic of DCHG is same as DSG_PDSG_OFF(), the DCHG would also assert for up to 250ms and then deassert again, right? What I am confused is why the response of DCHG Pin for CUV and DSG_PDSG_OFF() is different, thanks!

    Wish you a happy new year!

    Jayden Li

  • 0 in reply to Jayden Li
    TI__Expert 4090 points

    Hi Jayden,

    Unfortunately, we didn't catch this functionality until it was too late to change, I agree it isn't ideal.  So at this point the best approach is to understand it and work around it.  One approach is to use the CFETOFF / DFETOFF pins whenever the host wants to disable the FETs, these pins do not cause this effect.

    Thanks and Happy New Year to you too!

    Terry