• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 181 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.

DRV8350: Regarding Fault Response Table(8.3.6.9)

Johnson David
Prodigy 110 points
Part Number: DRV8350

Tool/software:

Dear Ti.

I have a question regarding Fault Response Table (8.3.6.9) in datasheet (I'm using "DRV8350RH")

By looking at the attached capture image below, I interpreted that the basic setting of the Gate Driver Fault (GDF) is 0b, and when a Gate Driver Fault (GDF) occurs, it will show a negative FAULT (LOW) and the gate driver goes into a Hi-z state. To clear this state, the fault condition must be removed, and an ENABLE reset pulse (tRST) must be transmitted.

1. When the gate driver is in a Hi-z state, does it mean that it is not operating?

2. After removing the cause of the fault, can the issue be resolved by simply keeping the Fault pin HIGH without transmitting the ENABLE reset pulse (tRST)?

3. I want to know if it is mandatory to transmit the ENABLE reset pulse (tRST) to clear this state. If so, how often should the tRST signal be sent with high→LOW pulses, how long should the LOW signal be maintained, and how many times should it be sent to ensure safety?

  • 0
    TI__Genius 12231 points

    Hi Johnson, 

    Thank you for posting to our forum! 

    Johnson David said:
    1. When the gate driver is in a Hi-z state, does it mean that it is not operating?

    When the driver goes into a Hi-Z state, this means that power-stage MOSFETs are shut off/put into a high-impedance state by turning off all the driver gate outputs (GHx). Depending on the specific fault registered, certain additional functions of the driver are disabled (such as the internal charge pump). 

    Section 8.3.6 - 8.3.6.8 delves into exactly which functions are disabled during each fault. 

    Johnson David said:
    2. After removing the cause of the fault, can the issue be resolved by simply keeping the Fault pin HIGH without transmitting the ENABLE reset pulse (tRST)?

    No this will not work, as the nFAULT pin is actually just an output response for the driver to let the user know a fault has occurred,  but does not have any input functionality regarding fault states.

    For faults that are not able to have automatic-retry, a reset pulse will need to be sent or the fault-bit must be cleared through SPI if an DRV835xS variant device is used — or, the device can be fully power-cycled (as this will reset the internal fault registers)

    Johnson David said:
    3. I want to know if it is mandatory to transmit the ENABLE reset pulse (tRST) to clear this state. If so, how often should the tRST signal be sent with high→LOW pulses, how long should the LOW signal be maintained, and how many times should it be sent to ensure safety?

    Yes, it is mandatory to use the reset pulse or CLR_FLT bit in this case.  Regarding the pulse structure,  please refer to section 8.4.1.3 of the datasheet that helps cover this operation:  The reset pulse should be a high-low-high pulse, where the low pulse is withint the Trst window of 5-40uS, with no restriction on the high pulses.  

    Only 1 pulse is necessary,  but there is no harm in doing more if desirable, especially if there is expected variance in the timing/reliability of the source of the pulse that would put the low-pulse outside the range of 5-40uS. 

    Hope this information is helpful!

    Best Regards,

    -Joshua