• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 135 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.

DRV8316REVM: Going to SLEEP after OC fault Bug

Jerome Villapando
Intellectual 290 points
Part Number: DRV8316REVM

Hello,

I was testing latched OCP mode and I found this weird issue. After an OCP occurs, nFAULT goes low and FETs are HI-z as expected. However in this state, if nSLEEP is driven low, the FETs look like they open momentarily:

Note that to perform this test, a short is applied between OUTA and OUTC, hence current spiking up when the FETs open. It is weird that nFAULT is pulsing like so. The next test shows the same procedure except this time without the short:

Here it looks like there are two instances where FETs open? This time, the nFAULT line looks clean though.

Any idea to what might be happening?

Jerome

  • 0
    TI__Mastermind 20085 points

    Hi Jerome,

    Thank you for posting your issue on the BLDC Motor Drivers forum! 

    Would you be able to provide the same 2 waveforms but instead show INHA in place of ISHORT? I want to see if the inputs are still toggling when nSLEEP goes low, and to see if that corresponds to VOUTA going high. My suspicion is that the inputs are not low after nSLEEP goes low which is resulting in the output going high when the nFAULT clears (one purpose of nSLEEP is to clear faults) and when INHA is also high. Since the device doesn't immediately enter sleep mode the moment the nSLEEP pin is brought low, you may still see the outputs following the inputs for some time. If you ensure the INx inputs are low prior to pulling nSLEEP low I suspect you won't see this behavior.

    Regards,

    Anthony Lodi

  • 0 in reply to Anthony Lodi
    Intellectual 290 points

    Hello Anthony,

    I did the captures you requested and it looks like your suspicions are correct. Here are same scope shots with INHA for Channel 1:

    I turned off the PWM input before resetting with nSLEEP and everything looks good:

    One thing to add that I noticed is that after trying to clear all OCP faults with the CLR_FLT bit in the CTRL2 register, everything is cleared except the NPOR bit in the IC_STAT register. I receive a 0x8 from that register, meaning the FAULT bit is cleared (bit 0 of IC_STAT register) but the NPOR bit remains? it looks like only nSLEEP or power cycling clears it. Section 8.3.15.1 in the datasheet states that it should be resettable through CLR_FLT. Am I missing something?

  • 0 in reply to Jerome Villapando
    Intellectual 290 points

    Oh, I guess the nFAULT line oscillations due to the nSLEEP after OCP bug is still unexplained as well.

  • 0 in reply to Jerome Villapando
    TI__Mastermind 20085 points

    Hi Jerome,

    Here are my thoughts as to why you are seeing oscillation on the nFAULT pin: Since a pulse on nSLEEP is used to reset a fault, and during this behavior nSLEEP is low, my guess is that the nFAULT pin is not latching low if a fault occurs during this time since nSLEEP is also low. The pulse on nFAULT seems to be a result of nFAULT going low after detecting overcurrent event, and this is consistent with the fact that the output of the VOUTA signal goes low after the nFAULT pin pulses low. Since the nFAULT pin isn't latching low probably due to the fact that nSLEEP is also low, the moment the overcurrent event clears you see the nFAULT pin go high again and the VOUTA output also go high again, causing another overcurrent event to be detected, and the process repeats which creates a pulsing effect on the nFAULT and VOUTA signals. Ensuring that the inputs are pulled low prior to pulling nSLEEP low will prevent this behavior from occurring.

    Regarding the NPOR bit, this bit is a little confusing, but this bit is set to 0 if either the VM or AVDD voltage drops below their respective UVLO thresholds and then recovers. During the time that an UVLO condition is present the device is off, and then once the VM or AVDD voltage recovers to the appropriate voltage level the device turns back on and sets the NPOR bit to 0 to indicate that the device had previously turned off after a UVLO condition that occurred on either VM or AVDD. So clearing the faults should result in the NPOR bit being set to 1, since this indicates that no power-on-reset condition has been detected. 

    Regards,

    Anthony Lodi