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.

DRV8840 chopping current

Other Parts Discussed in Thread: DRV8840

I am using a DRV8840, and I am seeing an issue with it.  Sometimes, it just stops driving the motor completely.  I confirmed that it's still enabled, and there is no fault indication (the fault flag remains pulled to 3.3V at all times - never goes low).

However, it is constantly hitting the chopping current threshold (set for 5A).  My question is this:  Is there some kind of timeout period for the chopping current threshold such that, when exceeded, it will disable the driver?

I know there’s a timeout for the internal overcurrent protection that’s mentioned in the datasheet (but no value is ever given for it - “OCP time”).  I’m wondering if this time or a similar time also applies to the chopping current threshold?

If that's not it, what can cause the DRV8840 to disable itself with no fault indication?

  • Hi Bill,

    One condition that could cause this is an UVLO (undervoltage). This is not reported on nFAULT but does stop the motor. Could this be the reason?

    There is no timeout on chopping current. Once the limit is reached, the device will enter either fast or slow decay until the beginning of the next clock cycle of the internal clock.

    Can you provide more information, such as scope captures of the area that you are referring? Please include the input and outputs, zoomed out and in.

    What voltage are you running?
    Are you using the TI EVM?
    If your design, can you provide a schematic of the area around the DRV8840 plus bulk capacitors?
    Which decay mode are you using?
  • From what I understand, it would retry after a UVLO fault, right?  It doesn't retry at all, it's just off for me (until I power cycle - toggling reset doesn't work).

    I'm running 24V with 210uF of bulk capacitance, and I don't see any dip in voltage.  I don't have the EVM, but I did just order one.  We've tried both slow and fast decay, and we get the same behavior.

    Here's the schematic:

    The board is very difficult to probe while it's in the system, but we do need to confirm that we are commanding the driver the way I'm saying we are...

    -Bill

  • Hi Bill,

    Thanks for the info. Yes UVLO should recover and start driving again.

    This is puzzling because it sounds like an overcurrent event, but is not reporting it through nFAULT nor recovering by issuing a reset.

    Let me know once you confirm the driver is being commanded correctly.
  • Hi Bill

    One possibility is that you only have one R381 at Pin I3 for the current setting, if any issue happened on R381, the current may be set to Zero then the outputs lost.

    Best regards,
  • I received the DRV8840 EVM, and I cannot seem to get the computer to talk to it.  I installed the USB drivers, restarted the computer (as it told me to do), and I can't seem to command the on-board MSP430 to do anything.  Trying to set the VREF pin, for example, it looks like the command is received (I see green text in the box at the top of the GUI), but  the VREF pin doesn't show any voltage change.  Clicking any checkbox also does not show any updates - ENABLE, PHASE, nSLEEP, nRESET, I0, I1, I2, I3, I4 - none of them are commandable.

    Any ideas there?

  • Hi Bill,

    I will look into this soon, but while waiting can you provide a screen shot of the GUI. There are a couple of items to check.

    First, look at the lower left of the GUI. Does it show Disconnected? If so, please left click the word "Connect" at the top and try again.

    If the word "Connected" shows at the lower left and the controls still do not work, please use the Device Manager to confirm which COM port is used. The GUI is expecting COM4, so if a different port is used this may be the problem. The Settings next to Connect allow changing to a different port. If possible change to the port used by the HW. Then Disconnect and re-Connect.
  • Rick,

    I can "connect" in the program even when no USB cable is plugged in, so I don't think that tells you much.  I can get you a screenshot if you really want it.  I also realized that the "green text" up top shows up even when no USB cable is .  At first, I had some "unknown devices" in device manager that I had to force the FTDI USB driver onto.  After doing that (and even after a restart), it seems to grab COM port 12 or 13.

    The DRV8840 program seems to only look at COM1-COM4, and has no idea that anything beyond that exists.  I don't know how to manipulate COM ports manually.

    I have a feeling that this many be a driver problem, too, but I've tried re-installing it multiple times to no avail.

    -Bill

  • Hi Bill,

    That does tell me a lot. It means that something else on your PC is using COM4. When you press connect, the GUI is connecting to it.

    Is there any other external device connected using a USB cable? Can you remove it and see it COM4 becomes available?

    In the device manager, is COM 1, 2, or 3 available? If so, there is a simple procedure to move the USB port to one of them. If not, this may be more problematic.

    I believe there is a post on this subject. Look for an update in a few minutes after I search for it, but please answer the questions above.
  • COM1 through COM12 are all in use, except when I unplug my USB mouse - then COM2 is freed up.  I have zero USB devices connected aside from my mouse.

    I've forced the FTDI device to use COM2, but COM2 is greyed out in the 8840 application and unusable.

  • Hi Bill,

    This is strange. Would you try the following and provide a screen shot? To attach the screen shot, select "Use rich formatting" at the lower right of reply.

    Bring up Device Manager as you already have done.
    Open the Ports (COM & LPT)
    Select View and Make sure "Show Hidden Devices" is checked.
    Capture the ports and attach this.

    I am using Windows 7, but I think this should work on any version. Below is what is shown on my PC. Many of these are no longer used, so from time to time I have to go in and uninstall the COM ports.

  • I'm on Win7, too.

    Here's the screenshot (note it's now showing up as COM2 now that I forced it):

    I've since forced it to use COM4, and clicked through the dire warnings that Windows gave (it doesn't like having two COM4's active).  The 8840 application now has both COM2 and COM4 greyed out, and it says COM4 is not a valid port number when I try to "connect".

    I'm thinking this is a driver issue, as I had to manually force the "unknown device" to use the FTDI driver.  Can you send me the actual driver files you're using - not the .exe, but the actual .sys, .inf, etc?

  • Hi Bill,

    I will send it. It may take awhile to put that together; look for it in a little while. The driver that I have is an older version of the FTDI driver. There are updated one on the FTDI site.

    Prior to sending, there is an Unknown device in the Other devices section.
    Can you uninstall that and COM2 and try again?

    It is surprising that there are no greyed out COM ports. Have you uninstalled all of them?
  • Hi Bill,

    Please see attached zip file. I am not sure I got everything so be warned.

    I was also using version 2.10.0.0 which has been updated to 2.12.00

    I highly recommend using the most recent FTDI drivers, located at www.ftdichip.com/.../VCP.htm

    FTDI_Driver_details.zip

  • Rick,

    Today is a new day!  I didn't even restart my computer, but it looks like it decided to work suddenly.  I uninstalled both COM2 and the unknown device, plugged in the EVM, rescanned device manager, it automatically installed itself this time.  This time, it put itself on COM4, and now when using the application, it works.

    I have no idea what's going on, but I should be able to continue my testing now!

    -Bill

  • Hi Bill,

    Sorry for the trouble you encountered, but I glad to hear it is working. If you ever figure out the cause, please let us know.