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.

DRV8412 Overcurrent / CBC Issues

Other Parts Discussed in Thread: DRV8412, DRV8834
Hi,

We are using the DRV8412 configured in parallel-full-bridge mode connected to a DC motor.  The OC-Adjust Resistor is set  to 30k which according to the datasheet sets the maximum current before OC occurs to be 8.8A.  M1=0, M2=1, M3=0 to select PFB CBC limiting.

Here's a typical scenario:
With the motor stopped, the PWM input to the driver is stepped from 0 to 50%.  When looking with a scope, the output (read across the motor leads) goes from 0 to 50% and you can see current ramp up (read via a current sensor).  The transient current spike reaches ~9A at which point the driver shuts off in what appears to be a fault mode.

A couple questions:
1.  As current ramps up, it appears the output duty cycle does not get reduced.  Based on the datasheet, I am expecting the DRV8412 to limit duty cycle (CBC Mode) to try and control the current.  I've attached scope plots of the event at three different frequencies - 2.1khz, 10khz, 100khz.  Yellow is the voltage trace across the motor and red is the current in amps.




2.  When this overcurrent fault occurs the FAULT line is not pulled low.  Should this overcurrent fault cause the Fault line to be pulled low or is there another indication that a fault has occured?

After this fault occurs, a toggle of the RESET line is required in order to get the driver to run the motor again.

Can you provide any clarification on the current limiting abilities of the DRV8412?  We originally selected this driver chip because we read the datasheet to indicate that the chip had some ability to limit duty cycle based on driver current.  Did we miss something in our application?  I've attached our driver schematic below:



Thanks
Adam

Step45_F2p1_Hang_Whine.png

  • Hi Adam,

    There could be several things going on here, so I will throw out a few things for you to try and perhaps we can narrow down the cause of the issues you are seeing.

    1) You are correct in that the DRV8412 will use the CBC current control to disable the outputs to your motor if the output current exceeds the preset determined by the OC-ADJ resistor. This should result in a varying PWM width as your current increases if you are operating at the regulated current limit. However, according to the data sheet, there is up to a 20% device-to-device variation in OC threshold measurements. Because of this large variation, the CBC current limiting function is only intended to be a system protection feature and is not intended for precise current control.

    I take this to mean that, given the worst case scenario, this variation could result in the circuit not tripping until 8.8A+/- 10% which is an upper limit of around 9.68A. Assuming that your O-scope capture is a 1:1 ratio of voltage to current measured, you are operating at a continuous current of ~9.7A which is so close to the upper limit of that variation that there may not be a noticeable difference in duty cycle. To see if this is truly what is causing your problem, I would suggest temporarily replacing your current resistor with a larger resistor value and seeing if the CBC current limiting function engages at a lower threshold.

    For more precise current limiting, in this case it may be more useful to measure the voltage across a sense resistor and adjust your PWM accordingly. Unfortunately this device does not advanced current regulation techniques like our stepper motor drivers (i.e. DRV8834).


    2) I'm unsure of why your FAULT pin would fail to be pulled low as every fault the device encounters should assert the pin low. Next time you run this experiment, please monitor the OTW pin as well as both are needed to figure out why the device may have failed. Are you monitoring the FAULT pin only through microcontroller or have you seen this behavior on the oscilloscope as well?


    My first inclination is to guess that you may actually be seeing a overtemperature shutdown (OTSD). This is based on my eyeball measurement of the O-scope captures, but it seems that your device is pulling current for about the same amount of time in all three captures before it is disabled. In the 3rd capture, your device appears to be on for a slightly shorter amount of time. This earlier-occurring failure may be attributed to the fact that switching losses are much more substantial when operating the device at a 100KHz switching frequency, so the heat generated by the power FETs will increase and OTSD will occur sooner.To test this theory, please let me know about the following questions:


    In your experiments do you see that there is an approximately constant amount of time in each case before the device fails?

    In order to resume normal operation, is it necessary to reset both the RESET_AB pin and the RESET_CD pin or can the device be restarted by only enabling only one of the two pins?

    Is the PowerPad on the bottom of the device soldered to an exposed copper area on your footprint, or is it left floating?

    It may just be coincidence, but does the device always fail on an edge transition of your PWM?


    Hope this helps! Please let us know the answers to these questions and we will continue to help you solve this issue.

    Best regards,
    Casey

  • Thanks for the quick response Casey. 

    I've finally gotten a chance to followup on some of your questions.

    -  When commanding a large duty cycle that trips out the motor out the FAULT line does go from high to low indicating a fault.  We caught this with a scope but missed reading it into our microprocessor.  The OTSD line does not change so I don't think we are causing an over temp shutdown. 

    - I don't see the duty cycle change at all.. It looks like it matches the duty cycle we are inputing to the DRV chip and it delivers it until the fault occurs.

    The FAULT line is shown above the yellow line (changes from turquoise to blue as it goes from high to low)

    - It does appear like the fault occurs on the falling edge of the voltage trace

    - The power pad is soldered to the footprint on the board

    - For the failures I've just recently tested with a driving frequency of 2khz it looks like it consistently fails after about 3 cycles which seems to line up when the current has ramped up.

    A little more info on our motor --  the stall current of the motor is >10A or so.  My thought how this would work is that the DRV delivers the desired duty cycle and the motor current begins to ramp.  Due to the inductance of the motor we don't or won't see a current spike greater than the 9A limit.  As current ramps above some threshold the DRV chip will reduce the duty cycle output to limit current. If the max limit is exceeded the chip will fault out.

    Based on the current rise shown by our plots, would another resistor allow more time for the duty cycle to be limiting for exceeding the fault threshold?

    Maybe I didn't follow it in the datasheet but is there a relationship for a given resistor like..

       current > 9A for XX us -> Driver will fault; fault line goes low

       current is between 5A and 9A -> Driver will limit duty cycle to try and reduce current

       current is below 5A -> Duty Cycle Output = Duty Cycle Input

    Let me know if you have any other comments or suggestions to test.

    Thanks

    Adam

  • Hi Adam,

    Sorry for my delayed response. After doing some digging, there are a couple of experiments I would like you to try:

    1) Try disconnecting the diodes on your output windings, see if this has an effect on the transient current spikes in your waveform.

    2) From the schematic you posted earlier, it looks like you have included ferrite beads or inductors in series with your outputs. To rule out the possibility of shoot-through, try disconnecting two of your ferrite beads (L17 and L18 in your schematic) so that you are only driving the motor with one bridge. This will eliminate the possibility of the outputs fighting each other though it may cause thermal issues. 

    From what you've described it sounds like you are encountering an overcurrent condition which is causing the device to latch off. Even though you're in CBC limiting mode there is a redundant protection system that is designed to trigger in case of high-current transient situation (i.e. short to ground). This secondary function is a latching OC protection that required a device reset to re-enable the FETs, which matches your description of the issue.

    A quick clarification on the OCP_ADJ resistor: this resistor affects the current trip level per bridge. With the 30K resistor in normal operation this would limit you to around 9 amps through the motor winding. In paralleled mode however the current is split between two bridges, so the effective current limit level doubles to 18A. This is why you are not seeing the cycle-by-cycle limiting on your outputs. Try using the 68K resistor (4.1A CBC limit, 8.2A effective limit in paralleled mode) and see if this gives you the desired results.

    In order to trigger a latching shutdown your transient spike would be around 6A or more greater than the programmed CBC limit level (with your current resistor value that's 18A +6 for a total of 24A current spike) and only needs to persist for 250nS. This may be easily caused by a shoot-through condition in the FETs when operating in paralleled mode. This does not seem like the case in the o-scope capture you most recently posted since the transient current spike doesn't look that bad, but that could be attributed to the scope averaging a large current pulse due to low bandwidth. From your first post the transient current spikes look much more severe.

    If you zoom in closer on the current waveform and turn on "Glitch Capture" on your scope, is the transient current spike much higher?

    Please let me know the results of the experiments and I will try to help you troubleshoot further. If you are using a PCB, it may help to troubleshoot if we took a look at your layout. If you would like you may send your Gerber files to casey.leavitt@ti.com so we may rule out the possibility of anything in your layout causing this issue. Hope this helps!

    Best regards,
    Casey