• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 1234 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.

DRV8303 Overcurrent Protection: OC Latch Shut Down Mode

Barrett Heyneman
Prodigy 90 points
Other Parts Discussed in Thread: DRV8303

Hi,

We're using a DRV8303 with the overcurrent protection in latched shutdown mode. If we reset the fault condition (either via SPI or the quick pulse on EN_GATE) is there any additional delay for detecting subsequent overcurrent events on the same (or other) half-bridge?

While we haven't exhausted other potential causes, we are seeing behavior which suggests an additional overcurrent event following a reset receives a delayed response and would like to rule this out as a contributing factor.

Thanks,

-Barrett

  • 0
    TI__Mastermind 21320 points

    Hi Barrett,

    I will have to look into this.

    How quickly after the RESET is the next overcurrent event arriving? Can you provide a scope capture and schematic of the system?

    What is the failure mode? Does the DRV8303 miss the overcurrent event or is the nFAULT and SPI reporting simply delayed?

  • 0 in reply to Nicholas Oborny
    Prodigy 90 points

    Thanks for the quick response Nicholas.

    After further investigation, we don't think this is actually what's happening in our case, instead I think there's some confusion on our part concerning the exact behavior of the "quick reset" on the EN_GATE pin.

    The plot below shows behavior when turning on into a short.

    Green - GH_A
    Blue - EN_GATE
    Yellow - FAULTb
    Pink - Vsense (Current by measuring voltage across low-side sense resistor)

    The overcurrent protection should trip at Vsense of ~0.5V and it does at ~ -3us when GH_A and FAULTb both go low.

    Initially, based on just GH_A and Vsense traces, we had assumed that the second longer GH_A pulse was due to ann additional ~3us delay in the DRV8303 responding to the second overcurrent event.

    However, it now looks like we're holding the EN_GATE line low far longer than we need to, and GH_A going low after the second overcurrent event is actually due to our PWM input changing.

    Our current theory: the falling edge on EN_GATE initiates the quick reset behavior. The faults are reset and GH_A goes high again (tracking PWM input) after ~400ns. While we continue to hold EN_GATE low the system does not respond to faults in the same way. Our PWM input goes low at ~2us and GH_A tracks this, all while we're still holding EN_GATE low.

    Does this make sense? Is there a spec for the a) the minimum low pulse on EN_GATE that will trigger the quick reset behavior or b) the delay between the EN_GATE falling edge and the system resetting the faults?

    Thanks,

    -Barrett

  • 0 in reply to Barrett Heyneman
    TI__Mastermind 21320 points

    Hi Barrett,

    A quick note, you may want to monitor the PVDD supply throughout this event. There looks like there is significant voltage ringing occurring due to the short circuit which may be having other effects on the systems (possibly sending the device into undervoltage).

    A) An EN_GATE pulse <10us will trigger the RESET functionality of EN_GATE. I will investigate into the minimum pulse and get back.

    B) This would be related to mainly propagation delay in the device once the RESET is registered. This should be less than 200 ns typically.

    C) Let me check into how faults are handled after the falling edge of EN_GATE, before EN_GATE goes back high.

  • 0 in reply to Nicholas Oborny
    TI__Mastermind 21320 points

    Also,

    If you try clearing the FAULT through the SPI bit is the behavior different?

  • 0 in reply to Nicholas Oborny
    Prodigy 90 points
    Nick,

    A - Thanks, we'll check it out. The scoping here was a bit sloppy. Given how we were grounding and the proximity to motor phase wires we think a significant amount of that ringing is due to our setup.

    B - That sounds more in the range of what we're seeing (~300ns) before the PWM signal is passed through to GH_A

    We haven't tried with the SPI. We were hoping to tie this in to lower level hardware interrupts on our micro in order to get nearly immediate response.

    On our end, we've setup our micro to blank out the PWM signals as soon as we start the EN_GATE pulse, and we are no longer seeing GH_A come back up after ~300ns. Given the behavior we're trying to implement we'll likely need to do this no matter what, so the exact behavior of the DRV8303 is no longer blocking our progress. That being said, I'd still very much appreciate hearing what you find out.

    -Barrett