• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 801 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.

BQ76940: Cannot clear OVRD_ ALERT fault

Robert Nunez
Intellectual 570 points
Part Number: BQ76940

Good day,

What causes the OVRD_ALERT bit to become 1? From the datasheet:

"The ALERT pin may also be driven by an external source; for example, the pack may include a secondary overvoltage protector IC. When the ALERT pin is forced high externally while low, the device will recognize this as an OVRD_ALERT fault and set the [OVRD_ALERT] bit. This triggers automatic disabling of both CHG and DSG FET drivers. The device cannot recognize the ALERT signal input high when it is already forcing the ALERT signal high from another condition."

However, the ALERT pin in my AFE is solely connected to my MCU as an input. So I can't seem to see how the ALERT pin is being forced high (About 2.47 V) externally while low. At startup, when I read the SYS_STAT(0x00) register, I get a OVRD_ALERT fault. I have a pushbutton that clears all bits in the SYS_STAT register by writing 1's to all bits (0xBF) to register address (0x00). However, when I read SYS_STAT again, I get the same fault.

EDIT: Note that I have a 499k ohm pull down resistor from ALERT to ground. No capacitors in parallel. Would it help if I used a larger resistance or added a capacitor or both?

Thank you very much,

Robert

  • 0
    TI__Guru* 77283 points

    Hi Robert,

    Adding a capacitor (you can use ~470pF which is the value used on the EVM and many of the reference designs) should help to reduce noise. Make sure your pull-down resistor and the noise capacitor are close to the device with short trace length.

    When the host clears ALERT, there is a 500 us blanking time for the ALERT signal to transition low before the device starts to check for a high again. This is not a parameter in the data sheet, the internal pull down and the recommended RALERT resistor should pull down a normal trace capacitance allowing the pin to go low. If the capacitance is too high the ALERT may still be above the VIL level when the part starts looking at ALERT as an input again. 250 us may be a good maximum time constant for the signal.

    Here are some other similar threads that might give more ideas for debug:

    https://e2e.ti.com/support/power-management/f/196/t/839429

    https://e2e.ti.com/support/power-management/f/196/p/782669/2894218 

    Best regards,

    Matt

  • 0 in reply to Matt Sunna
    Intellectual 570 points

    Thank you Matt, I'll check those threads.

    Quick question though, for the thermistors, from the datasheet: 

    "If not used, pull down to group ground reference (VSS for TS1, VC5X for TS2, and VC10X for TS3) with a 10-kΩ nominal resistor."

    What are the common effects when these are left floating? Because I currently don't have anything in place for the thermistors in my board as I'm not using them yet. Can this possibly have an effect on the OVRD_ALERT fault?

  • 0 in reply to Robert Nunez
    TI__Guru* 77283 points

    Hi Robert,

    If the TSx pins are left floating, they could float high and not allow proper start-up. This will show as an XREADY fault. This should not result in an OVRD_ALERT fault.

    Have a good weekend,

    Matt

  • 0 in reply to Matt Sunna
    TI__Guru* 77283 points

    Hi Robert,

    Were you able to resolve this issue?

    Matt

  • 0 in reply to Matt Sunna
    Intellectual 570 points

    It seems like I did. From the PIC24FJ64GB004 datasheet, section 10.3, it says that the Change Notification pins used in interrupts has a weak pull-up connected to them. This might be the cause of OVRD_ALERT being high. And so I simply disabled the corresponding bit on the CNPU register where the ALERT pin was connected. Now all the bits in the SYS_STAT are cleared.

    I just 'resolved' this issue literally a while ago, apologies for not following up on the thread.

    Thanks Matt! (I've got some other questions though, but about Charging/Discharging this time so I'll make another thread)