• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 927 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.

DRV8876: Fault on motor startup/how to clear?

John Hogan1
Prodigy 70 points
Part Number: DRV8876

I'm driving a 12VDC motor using a DRV8876 controlled by an atmega328p and find when using a high PWM duty cycle coming out of my PID controller, the driver will tend fault on startup (either right off the bat, or after a few stops and restarts).  If I limit the PID range to around +/-70, it doesn't seem to fault.. but when I get above that, it does.  I have it configured for cycle-by-cycle/latched output (quad-level 3) mode.  I'm certain its not current-chopping since I can cause that to occur by changing Vref and the fault that appears clears on its own.  With the high PWM, when it faults and stays faulted and the only way I've been able to clear the condition is to power cycle (remove and reapply Vm).  Looking at Table 7, I'm not sure what the cause is:

When the atmega detects the fault (one that has lasted longer than 500 ms and there's been no change in motor encoder reading .. this is to avoid messing up working current-chopping routine) then to clear the fault, it brings nSleep High, waits 2ms, and brings it Low.  nFault clears after doing this.  However, the driver still seems to have its outputs disabled.  My understanding is that with fault cleared (and the condition removed), operation would resume.  Reviewing Table 7, I would think both Vulvo or Vcpuv would clear on its own pretty quickly since the motor is stopped and the power supply should recover.  A TSD would clear when the temperature drops, but I don't think its TSD since it can happen right on startup.  The only thing perhaps then is OCP, but doesn't that clear on its own as well? This issue doesn't occur when driving smaller motors.

And lastly, this issue didn't crop up when using smaller motors that draw less current.  I can run those at full PWM with no issue.

  • 0
    TI__Mastermind 37683 points

    Hi John,

    It looks like  this is an OCP fault. You have the IMODE configured to Quad-level 3 (R_IMODE=62kΩ to GND) which sets the OCP nFAULT response to LATCH. This means that the outputs will be disabled and nFAULT will LATCH when an OCP event occurs. A device reset will be needed to re-enable the H-bridge and resume operation. In case that the in-rush current during start-up is higher than the OCP threshold, the OCP event will disable the outputs again and another device reset will be required to resume operation. This process will repeat unless the current is regulated below the OCP threshold. To set the OCP response to automatic retry, the IMODE needs to be set to Quad-level 1 or 2. This ensures that in the case of OCP fault, the outputs are re-enabled after t_retry expires (section 7.3.4.3 on datasheet).

    Changing the IMODE to Quad-level 2 (if you require Cycle-by-Cycle current chopping) should prevent the nFAULT from latching in the case of an OCP fault.

    I hope this answers your questions.

  • 0 in reply to Pablo Armet
    Prodigy 70 points

    Thank you for the response.  Does this mean that the datasheet is incorrect?  In Section 7.3.4.3, OUTx Overcurrent Proection (OCP) it states:

    "In latched off mode, the MOSFETs will remain disabled and nFAULT pin driven low until the device is reset through either the nSLEEP pin or by removing the VM power supply."

  • 0 in reply to John Hogan1
    TI__Mastermind 37683 points

    John,

    The description on the datasheet is correct when the IMODE state is set to Quad-level 3 or 4 as you can see in the table 6. In your case, I think what is happening is that when you reset the device (by toggling nSLEEP Low-to-High) after nFAULT is latched, the outputs will be re-enabled but most likely because of the large in-rush current during motor start-up, the OCP fault is triggered again causing it to appear as if the the outputs have remained disabled.

    You mention that by decreasing the duty cycle or when using smaller motors that don't draw a lot current, this issue does not occur. By decreasing the duty cycle, the initial start-up speed (which causes the in-rush current to be below the OCP threshold) is lower which does not trigger the OCP fault. Similarly, smaller motors will not cause large in-rush current.

    An alternative solution to the one I mention in my previous reply is to set the current regulation below the OCP threshold. The in-rush current will be regulated at a current below the OCP threshold preventing the fault from triggering in the first place.

    I hope this answers your question.

  • 0 in reply to Pablo Armet
    Prodigy 70 points

    I agree it seems very much like a continuous OCP fault, but upon re-enabling via nSLEEP, nFAULT doesn't latch again.  nFAULT remains clear but outputs remain off.  I can do some more testing I guess.

    There certainly appears to be work-arounds, but my fear is that in the event something happens unexpected and an OCP fault does occur, I need to be able to break out of it without cycling Vm.

  • 0 in reply to John Hogan1
    TI__Mastermind 37683 points

    Hi John,

    I understand your concern. I recommend changing the IMODE to 20kΩ to GND to set the OCP response to automatic retry. This will ensure that in the case that an OCP occurs, the driver will clear the fault until the OCP condition is removed. The driver will resume normal operation without the need of cycling VM. However, if the OCP condition is persistent, the driver will remain in the retry phase keeping the outputs from driving the load until the OCP condition is removed.

     

  • 0 in reply to Pablo Armet
    Prodigy 70 points

    I added a slow start routine to the PID controller by limiting increases in PID output to 40 per 100ms and 99 out of 100 times, it prevents the controller from going into a fault condition.  I therefore agree that OCP is the problem.  The issue I have, however, is that if it is the problem and if the datasheet is correct, then why don't the outputs reset when nFault is cleared?  Certainly the OCP condition goes away when the fault is detected and the outputs are latched..  I've even tried putting the driver asleep for a full minute before re-engaging the PWM signal at 1/4 the faulting PWM (maximum of 64, which never has failed) and it still won't turn back on.  If I immediately power cycle it, it'll start, even at a higher PWM.  If the datasheet is wrong, I can accept that and work with it (maybe build new boards using level 2 instead of 3), but if its not wrong, what do I need to do to get the outputs to restart?

  • 0 in reply to John Hogan1
    Prodigy 70 points

    Not sure if it is relevant, but I was running my Vref through a RC circuit at 100% duty cycle to try to avoid current regulation as I was testing things, so it was at Vcc (5V).

    I see in the datasheet, Section 6.3, the recommended operating conditions has Vref at a maximum of 3.6V.  Can you provide any insight as to why this is and what issues might be if running Vref higher than that?

  • 0 in reply to John Hogan1
    TI__Mastermind 37683 points

    Hi John,

    I want to confirm a statement you made in the original question. You mention that to clear the fault, the  controller "brings nSleep High, waits 2ms, and brings it Low". Is this correct? If you bring nSLEEP back LOW, then the device will be in sleep mode which would explain why the outputs are not re-enabling while it appears that nFAULT has been cleared (since it is pulled to external supply). The correct procedure for clearing the fault by using nSLEEP is to first bring nSLEEP LOW for some time (t_sleep = 1ms), then bring nSLEEP HIGH to re-enable the device (wait t_wake=1ms before sending the control signals.

    In regards to the VREF voltage questions, this device can withstand an absolute maximum voltage of 5.75V. However, we recommended a voltage of 3.6V as we can't guarantee that the current regulation circuitry or other internal circuitry will NOT be damaged if a voltage above 3.6V is applied for  prolonged time. If possible, I recommend to bring down the Vref voltage below 3.6V.

  • 0 in reply to Pablo Armet
    Prodigy 70 points

    Embarrassing.  I confirmed that's how it was written and when I get back to the machine tonight, I'll correct that.  That certainly seems the most likely cause.  I'll just go ahead and mark it solved and slither away in shame.  Thank you for sticking with me on this.

    I'll bring Vref down to 3.6V, which should then limit current to around 2.4A and I think that would be ok.  Thanks again, great support here.