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

DRV8353: Fail "Safe" Gate Biasing

Chris Doughty
Intellectual 295 points
Part Number: DRV8353
Other Parts Discussed in Thread: DRV832X

Hello!  After a bit of a rough start and much patient support from TI, I've been able to get my DC motor drivers up and working quite reliably for the past 10-12 months.  Having deployed a number of these control boards, operating outside, it was inevitable that nature would overcome our environmental protections and soak a board.  When it happened (for the 3rd or 4th time - I'm "talking" to the folks building the housing) rather than failing shoot-through on the bridge, opposite corners somehow became activated and the (large, wheeled) device spun in circles rather quickly until it's battery died.  Lot's of things to fix here to prevent this from happening, but I'm curious about anything I can do board-level which would induce a safer fail-state.  From telemetry it appears that contamination on the board caused a gate fault.  The DRV then shut down the gate drivers, allowing the gates to float (?).  Over time the we got enough leakage on cross-bridge gates to turn the bridge on and then we had motion.  My thought is to add a pull-up resistor on the low-side FET gates so that they are enabled when the driver is in fault.  Similarly a pull-down on the high-side gates to encourage them to stay off. 

Any insights from the great minds here as the the viability of this idea and the sizing of the resistors?  Based on the average current specs for the charge pump, it seems like I could get away with at least 1mA of pull-current without stomping on a regulators max average.

Better ideas?

Thanks,

Chris 

  • 0
    TI__Mastermind 18900 points

    Hello Chris,

    I'm still a little confused about the order of events.

    It sounds like something caused a fault, which disabled the gate FETs, and we think that the BEMF or current flowing through the motor coupled onto the gates again, which caused the gates to turn on and current to flow again.

    This is not the same as, some sort of diagnostic circuit in your system decided to turn off the DRV by flipping the enable pin low, while INx was still toggling, and then BEMF or current coupled into the disabled gates, which finally caused the gates to turn on a current to flow again.

    Right now, "spinning until battery died" seems near impossible as having the gates flip perfectly in a pattern to maintain a speed means that nature developed its own commutation algorithm. In these situations, current flowing through the motor might cause a singular low side and high side FET to turn on where the stator's field is held to a constant N/S alignment and the rotor tries to follow that alignment and stalls the rotor quickly (or, like you said, a shoot through occurs).

    So any more clarification on what happened would help.

    Best,

    -Cole

  • 0 in reply to Cole Macias
    Intellectual 295 points

    Thanks for getting back to me!

    It's a bit of a non-standard use; we're using brushed-DC motors (I should have emphasized that a little more) so with the bridge faulted/shorted/whatever on, it'll  commutate itself, spinning that wheel at full speed.

    If I were to word this in a more specific request and less anecdotally:  If I want my FET gates in a known state after a gate-drive fault, what is the maximum current which I could continuously source/sink into/from a gate driver without negatively impacting the on-board regulator or charge pump? 

  • 0 in reply to Chris Doughty
    TI__Mastermind 21805 points

    Hi Chris,

    How is the BDC motor hooked up? Are you using a unidirectional 1/2-H to drive it or a full H-bridge?

    DRV835x fault state should be all MOSFETs turned OFF, which theoretically shouldn't give current a path to flow.

    The DRV835x does integrate passive pull downs on all gates, in an attempt to leak charge out of them when they are supposed to be OFF. There is no issue adding additional gate pull down resistors, the high-side and low-side regulators have up to 25mA DC capability. We normally see 10-100k used.

    Thanks,

    Matt

  • 0 in reply to Matt Hein
    Intellectual 295 points

    Thanks, Matt!

    I hadn't caught that internal pull-down before - we're talking about the 150k Roff.  I'll add a bit in parallel with that on the high-side FETs in my H-bridge.

    For the low-side FETs, I'd really like to go the other way and have them turn on while in a fault.  By doing so my motor windings would be shorted so I'd get some nice braking and, if there was enough damage to the high side that a FET inadvertently turned on, the bridge would shoot through and take itself out rather than making something move.

    • A pullup from GLx to VBAT with a zener shunt to ground targeting, say 1mA into the gate drive?  I'd worry about said zener clamping above VGLS allowing my resistor to back drive the regulator or the zener being less than VGLS and clamping the gate drive. 
    • Perhaps run said pullup from VGLS, still targeting ~1mA ?
    • Use the FAULT line's low-state to fire a switch and add the pullup only when faulted?
    • Better ideas?      

  • 0 in reply to Chris Doughty
    TI__Mastermind 21805 points

    Hi Chris,

    • On a GLx pull-up, bear in mind that the DRV832x does have a semi-active pull-down integrated on the gates outside of the 150k. You may want to measure the impedance of the pin to GND while the device is powered OFF (VM = 0), in sleep mode (VM = xV, nSLEEP = 0), and when active (VM = xV, nSLEEP = 1).
    • When powered ON, you can pull 1mA or so out of VLGS. The regulator is powered down in sleep mode so you cannot use it
    • Implementing a cut-off switch on the supply would give you a separate shutdown path (see this app note)

    Thanks,

    Matt