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.

DRV 8840 not changing direction under certain conditions by using PHASE.

Other Parts Discussed in Thread: DRV8840

I have a condition where the PHASE is changed by the microcontroller and sends to the DRV8840 but the direction of the motor does not change.  We notice this when the Direction is set one way for short distance then told to move the other way.  We set PWM off (PWM through ENABLE pin) prior to changing the PHASE.  We noticed that if we put a delay of 25msec between the two moves then the direction will change with the PHASE.  I don't see anything in datasheet about a timing specification for changing the PHASE.  I just would like to know what is going on and that we are not just patching a problem with a 25msec delay. 

 

Thanks,

Wendy

  • Hi Wendy,

    Can you provide some additional information, such as scope captures of the PHASE, ENBL, OUT1, and OUT2 signals during this time.

    The scope captures will help determine if the device is operating as expected. If it is, this could be a motor limitation.
  • Hi Rick,
    Thanks for responding quickly to my issue. We are in process of getting the scope captures for you. Yesterday we put 10inch wires on the PHASE, ENABLE and ground and our issue was there for one or two moves and then disappeared. For two moves we were able to see the PHASE changing and going into 8840 but direction not changing. After the two attempts It started working as it should. We couldn't get it to fail. The Motor direction was changing with the PHASE. When we removed the oscilloscope and the wires, the problem came back consistently.(Issue where PHASE changing but motor direction isn't changing) We will try to get the signals and hopefully it shows up for us with oscilloscope on.

    You mentioned above that it could be a motor limitation. We have another design that this movement is not an issue. This previous design has been in use for many years with these exact motors. We are in process of upgrading our boards/design.

    Thanks,
    Wendy
  • We have several scope captures as you requested above. How do I get them to you? I don't see a way of including them here.
  • Hi Wendy,

    Please click Reply as you have done previously. Then select "Use rich formatting" to the right. This will bring up a set of icons including Insert file (a paper clip).

    Let me know if this does not work.

  • For the below captures: Phase=Yellow, Blue=Enable, Purple=Output1, Green=Output2.

    During the capture below(TEK0001),  After the 1st Low on Phase,  Motor continued to drive in direction of Phase=Low although Phase was switching to Low  at some points.  As you can see a strange waveform exist on Output2.

     

  • Hi Wendy,

    Thank you for the scope captures. This appears as though OUT2 has stopped driving for some unexpected reason.

    Do you have a current probe? Can you capture the current when OUT2 stops driving (PHASE=logic high, ENABLE=logic high).
    To recover and start driving again, are you toggling NRESET or cycling power?
  • Hi Rick,
    The moves where the phase changes is each considered a new move.
    With each new move we do the following
    DECAY=0
    RESET=0
    PWM= off

    reset some of the variables and registers

    Just prior to allowing PWM to calculate, the following is done:
    DECAY=1
    RESET=1

    I can see about looking at current if need be.
  • Hi Wendy,

    Thanks for the confirmation of toggling NRESET. This makes it appear as though OCP (over current) is being exceeded when switching directions.

    The scope capture of current zoomed in at the switch point will help confirm this. Expect to see current at the reversal of greater than 6A for several microseconds. This may cause the overcurrent protection circuitry to assert which disables the outputs until NRESET is toggled.
  • Hi Rick,

         I am not able to get a capture of current today.  In a day or two I will be able to confirm.  If the issue is what you suspect then how would you recommend fixing it.  Right now we are fixing it with a delay but delay is causing other issues. 

     

    Thanks,

    Wendy

  • Hi Wendy,

    You can also take a look at the nFAULT pin when reversing. If an overcurrent is detected, it should assert low.

    Once it is confirmed that the overcurrent is asserting and the scope capture can show the magnitude, then we can recommend a potential fix.
  • Hi,

        Just wanted to claify how you wanted us to measure the current.  Do you want us to put a sense resistor on outputs and measure voltage and calculate current from that?   On one side that is kind of what we have already provided. 

     

    Wendy

  • Hi Wendy,

    There are two choices:

    Ideally place a current probe (if you have one) on the wire from the DRV8840 to the motor. Zoom in to the point where the motor is changing direction. You may need to zoom in to about 10us/div.

    Place a probe on the top of the sense resistor. This is sometimes difficult to read but it is a good backup. If you do this, please let me know the value of the sense resistor. It can then be converted into current.

    Thanks.
  • Hi Rick,

         You ask that we measure the current.  The only way we really have of measuring the current is by measuring the voltage across a sense resistor and then calculating the current.  Is that what you want?

     

    Wendy

  • Hi Wendy,

    Yes that is what I would like to see.

    I am assuming there is a sense resistor between the ISEN pins and GND. Is that correct? If so, what is the value of the sense resistor used?

    I am also assuming that by measuring you are referring to a scope capture. This is required because we are looking for instantaneous current.

    Thanks.
  • Sorry, For last Replay I didn't see your prior one . But we do not have a sense resistor between ISEN pins and GND. They are just tied to ground. The I0,I1,I2,I3,I4 & NSLEEP are all tied to 3.3V
  • Hi Wendy,

    Looks like this will be a little difficult to determine the reason. With the current set to 100% in the motor the VM voltage and motor parameters can help us determine what may be occurring. I hope we can figure it out with the minimum amount of effort.

    What is the DRV8840 VM voltage?
    Can you provide a specificiation of the motor (R, L, C) or better yet a datasheet link?
    When you are initially starting the motor in the opposite direction, what is the duty cycle and PWM frequency?

    Is it possible to place a small resistor (about 100 to 200 mOhm) in series with one of the motor wires? Doing this and placing scope probes on both sides of the resistor with respect to GND may provide the information. If you have a math function determine the difference between the two voltages and knowing the resistance, the current can be calculated.
  • The VM voltage is 27V.

    The PWM Frequency is 15.68KHz

    The PID We are using PID to control the duty cycle so it starts off in off state and gradually increases.

    I have attached the motor datasheet.

     

    Torquemaster Brush servo 2100.pdf

  • Forgot to mention in last post, we will work on your suggestion of the small resistor in series with one of the motor wires. I will send when we get good captures.
  • Hi Wendy,

    Based on the 27V and the 3Ohm, the DRV8840 could see as much as 9A when the motor is starting. It is difficult to say for sure because I could not find the inductance listed, so it is unknown how fast the current will build.

    There are a couple of things that could be tried to see if the motor continues to run. This will help identify the overcurrent as a possible cause with minimal effort.

    Can you lower VM to 18V? This should prevent an overcurrent event. If it does the motor should continue to run although you will not achieve the maximum speed.

    What is the DECAY pin set to? If set to 3.3V, can it be changed to GND. This may help by allowing the current to build more gradually as the PID loop increases the duty cycle.

    Please let us know the results of these two experiments. Thanks.
  • Hi,
    I think it will be difficult to lover the VM to 18V in the system but I can check on it. The DECAY is controlled by the micro-controller chip. I wasn't sure if the DECAY was being controlled right. I put it on one of my earlier posts when I was showing you that we toggle the RESET.



    The moves where the phase changes is each considered a new move.
    With each new move we do the following
    DECAY=0
    RESET=0
    PWM= off

    reset some of the variables and registers

    Just prior to allowing PID to calculate PWM , the following is done:
    DECAY=1
    RESET=1
  • Hi Wendy,

    Sorry, I missed that earlier information about DECAY. In general using DECAY = 1 in brushed motors creates more current ripple, and lowers the system efficiency. Most brushed motors use DECAY = 0 when running the motor.

    Based on all the information provided to date, here is the best course of action (in my opinion):
    1) Place the resistor in series with the motor to allow basic monitoring of the current ( Do this with no other changes in the system for a baseline). Also monitor nFAULT, but I suspect it is asserting.
    2) Set DECAY to 0 at all times and monitor the current. Hopefully that will allow the current to build more slowly.
    3) If step 2 does not work, lower VM to about if possible with DECAY set to 0

    If you can capture the current at each step, it will help prove that this is an overcurrent event and determine the next step.
  • Hi, 

    We worked on your suggestions last week.

    Step#1:      We did place the resistor in series with the motor as you described in step #1.  We were not able to take good captures.  We may try again today but we did visually see current of 13amps.  And we did see the nFault asserting every time.  We have the nFault line connected to a LED on the board so very easy to see.

    Step #2:  I set DECAY to 0.  What  I immediately noticed was our movements became more erratic with normal moves but then noticed that PID values needed to be adjusted very low compared to with the DECAY=1.  The lower I made them the smoother the moves.  I am still in the process of adjusting the PIDs for DECAY=0.

     

  • Hi Wendy,

    Thanks for the update. Currents of 13 amps for as little as 3us can explain the nFAULT asserting. The OCP current is rated at 6A, so anything over that can trip the overcurrent circuit. The DRV8840 is designed to protect itself and the motor from large currents like this so it shuts down, and asserts nFAULT.

    As you mentioned the PID values can be lowered with DECAY = 0. By using DECAY = 0, the PID loop can potentially build the current slowly. This may keep the current below the overcurrent trip point. The problem is that without a current probe or some other method to measure the current at startup, it is difficult to determine how much margin is there.

    Please keep me posted on your progress.
  • Hi Rick,
    I changed the DECAY to 0. All our testing today was with this new version with new PID values to allow smooth movement. During times of running motor without fault, we saw current mostly at 5.6A and every now and then saw current spike to 8A and 9.6A. This was occuring with motor at low PWM value. This PWM value was low enough to be not moving( holding position and nothing is applying pressure on it). We saw no fault during this. while moving we saw 560 almost exclusively. Although we saw it reach the high current values here it did not trigger the fault condition.

    During fault time we saw almost simular. 5.6 while moving normally before fault. Then when moving erratically and causing a fault we saw 8A and 9.6A. We didn't observe 13A today.

    We will try and test again tomorrow with a different oscilloscope that should be faster.

    Thanks for your help,
    Wendy
  • Hi Rick,

           Looking at the Fault line, We see that it is toggling in the 100s per second.  RESET=0 for this instance.  I am not toggling the RESET.  The Fault is toggling on it's own.  Before we even start using the Motor.  I suppose it justifies what we seen in the earlier post about the current spiking every now and then.  Do you know what could be causing this issue? 

  • Hi Wendy,

    I am not sure what would cause this. nFAULT is an indication of overcurrent (which stops the device and does not allow it to continue) or overtemp (which resets the device).

    Is the thermal pad soldered down?
    What are the inputs levels of PHASE/ENABLE/nSLEEP/I4:0 during this time?
    Can you provide a schematic of the inputs and outputs of the DRV8840?
    Can you provide a layout of the DRV8840 and the area around it?
  • Yes, I can give me a minute to get it together
  • Do you mean a board layout?
  • I have attached a page of the schematic and a pictorial of layout.  If you would like to see the PADS PCB file, I can send that too.1700-0009-0130 Rev 0A.pdfmfgsharp_20150311_112041.pdf

  • Hi Wendy,

    Have you made any progress on the system? It is possible that adding a ferrite bead or inductor in the motor lines can prevent the overcurrent.

    Using a value of approximately 20uH or greater should help, but may require experimentation.

    Assuming adding an inductor works, it is recommended to change the schematic to take advantage of the protection of the DRV8840 if possible. Maximum current is seen at startup and stalls. By using a sense resistor, VREF, and I4:0 to set the maximum current to around 4A, the motor current is automatically limited during startup and stalls. The PID code used may no longer be required.
  • Hi Rick,

          I was on vacation this week.  Back at work today.  I have not made too much progress.  We did try and add a Capacitor at one time but didn't appear to make a difference.  Do you think a ferrite bead may be a better option?

        We will look into the current protection feature on DRV8840.

     

    Thanks,

    Wendy

  • Hi Wendy,

    I think you will find the current protection feature beneficial. In many cases, there is no need to run maximum current through the motor.

    Adding a capacitor typically makes the problem worse, because they demand more current and create overcurrent events faster.

    Using a ferrite bead or inductor slows the rate at which the current can increase, with the intent of allowing the PID loop time to turn off before the overcurrent is triggered in the DRV8840.
  • Hi Rick,

         We have made many of recommended changes you have described.  We still do need PID though. We are not experiencing the high current anymore. I think I am having a problem with one of the changes made.  The change from FAST to SLOW decay.   We have a 10micron encoder and we need to be able to stop the motor precisely at a value in a range from 0 to 60000.  With previous FAST decay, I had no issues in accomplishing this with the PID.  Now that I am using SLOW decay,  I seem to be having issues with accomplishing this task without vibrations of the motor and other issues.  Is there something about SLOW decay that could prevent my accuracy in stopping where I need the motor to stop?

  • Hi Wendy,

    Can you describe the other issues that you are experiencing? Also can you provide a list of changes that you made? Of particular interest is whether a sense resistor was added, and if the DECAY pin is controllable by the firmware.

    Once the changes are identified, we can look at possible methods to avoid the vibrations and other issues.

    In general, the motor may stop at higher duty cycles when using slow decay vs fast decay. This is because slow decay (also called brake) is used to quickly stop the motor, while fast decay (also called coast mode) allows the motor to coast to a stop.
  • Hi Rick,

         Sorry I didn't see that your response earlier.  I usually get an email when you respond but didn't.  Everything has cleared up with the last issue I described.  We have not added a sense resistor yet but is planning to try because we are still getting over current in certain conditions.

    Thanks for your help,

    Wendy