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.

DRV8837 Overcurrent Protection Question

Other Parts Discussed in Thread: DRV8837

I am using the DRV8837 in a very small motor controller.  One thing that I noticed when going through some of my final checks is that the overcurrent protection does not seem to work the way it is described in the datasheet.  To test the overcurrent protection I stalled a motor which cause the overcurrent protection to kick in.  The datasheet says that after the load has been removed, it will re-enable the mosfets.  I found that this was not the case.  I had to actually reverse the direction of the motor, and then go back in the original direction.  Once I did this, the motor ran as expected.  I tested waiting after stalling the motor and tripping the overcurrent protection to see if the bridge would re-enable after a few seconds.  I waited a minute and it still did not re-enable.  I did the same procedure as before of commanding the device to the opposite direction, then back to the original direction.  Once again this worked and the bridge was fine. 

I am just wondering, am I doing something wrong, or is this the expected behavior?  If it is, then this is not what is indicated on the datasheet.  Thanks for your help.

Adam

  • Adam,

    Can you put a current probe on one of the motor outputs to see if it is really OCP?

    Also, put a voltage probe on VCC and also on one of the outputs.  Please post a scope shot showing these 3 channels.

    If really an OCP, you should see the motor outputs cycling every 1ms and your current should remain above 1.9A.

    When you are reversing the motor, you are flipping the direction of the current and essentially using "fast decay" to decay the current out of the motor winding below the OCP threshold.  Using  a current probe to see this in action would help prove this theory.

  • Ryan,

    I will see if I can get you that information with the tools that I have.  I can say that I have also tested the device without a motor connected to the outputs, but an LED in its place.  I then shorted the outputs to ensure an overcurrent protection action (as is stated in the datasheet, a short should also trigger the same behavior as a standard overcurrent).  In this case too, it behaved the same.  I had to reverse the device and then go back in the original direction to get the LED to come back on.  If I just waited, nothing happened.  In this case, I also waited over a minute to see if it would work (I had to go and grab a drink and came back, so it was a good amount of time).

    Adam

  • Disregard, this seems to be a case where a short is causing the microcontroller to drop out as well and it puts it into a failsafe mode.  There is no issue with the part.  Thanks again for looking into it.

    Adam