• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 479 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.

DRV8308: Motor must stop before restarting

john sullivan
Prodigy 130 points
Part Number: DRV8308

Hi, I've been using this part for a couple years now and I've run into a problem that happens occasionally due to a race condition.

I make use of the 'coast' feature of the device, by bringing the enable line low, on and off pretty often during use. The motor is used in a case where it can be forced to rotate through external forces at any point.

The issue I'm having is that it seems after the enable has been brought low, the motor needs to come to a complete stop before the motor will start up again.
I found this relevant part of the datasheeet:

"8.3.1 RESET and ENABLE Considerations

Since the ENABLE function doubles as a sleep (low-power shutdown) function, there are some important considerations when asserting and deasserting ENABLE and RESET.

While the motor driver is enabled, the deassertion of ENABLE initiates a stop-and-power-down sequence. This sequence starts by disabling the motor (either braking or coasting depending on the BRKMOD bit), and waiting for rotation to stop. After rotation is stopped for 1 s (as determined by the absence of transitions on FGOUT), the internal circuitry is powered-down, the V5 regulator and power switch are disabled, and internal clocks are stopped.

In this low-power sleep state, the serial interface may still be used to read or write registers. All other logic is disabled.

After this stop-and-power-down sequence has been initiated (by deasserting the ENABLE pin for at least 1.2 µs, or by changing the state of the ENPOL bit), the sequence continues to completion, regardless of the state of ENABLE.

If ENABLE is immediately returned to the active state, the motor slows and stops for 1 s, at which point it starts again. If RESET is asserted during power-down (at any time after the deassertion of ENABLE is recognized), it is acted upon when ENABLE is again asserted, and the part powers-up.

If RESET is asserted when ENABLE is active, the motor is stopped similar to the sequence when ENABLE is deasserted. After it is stopped for 1 s, all internal registers are reloaded with the value contained in OTP memory, faults are cleared, and internal states (that is, the speed loop datapath) are initialized. The motor remains disabled until RESET is deasserted.

RESET and ENABLE may be connected together (if the ENPOL bit in OTP memory is programmed so that ENABLE is active low). When both signals are low, the motor is enabled; when both signals are high, the motor is disabled. As soon as the signals are returned to high, all registers are reloaded from OTP memory, faults are cleared, and the motor starts."

I really need the motor to be able to start up even when it is already moving due to outside forces, without ever coming to a complete stop. I also need the motor to be able to completely coast, just setting the speed to 0 through the PWM input still allows the low side FETs to apply a braking force to the motor which I cannot allow.

Any suggestions?

  • 0
    Prodigy 130 points

    Hi,

    I found a potential workaround that works for my specific implementation. I changed the FGSEL from using the halls to using the TACH input, which is unconnected in my design. This 'tricks' the chip into thinking the speed is always 0 since there's no output on the FG signal. This works for my implementation since I use the chip in basic mode, BASIC=1, so none of the features which utilize speed are in use. 

    Is there any potential downside to this workaround? This means that the chip will go into the power down state before the rotor comes to a stop. Is there any potential for damaging the chip if it powers down while the motor is still spinning? I don't really see how that could damage things, but if the chip was designed to enter standby after stopping so there must be a reason for that.

    Thanks,
    John

  • 0 in reply to john sullivan
    TI__Mastermind 18900 points

    Hello John,

    Suggestions:

    In general, you're right, there's no real coast + initial speed detect type features within this device.

    Have you tried changing DIR during motor operation when BRAKEMOD = 0b0? Knowing the device, I would be surprised if we had the logic to see if the halls are toggling or when we make DIR back in the intended direction, but your interesting FG workaround gives me some hope.

    Comments on the workaround:

    When the chip powers down, VREG, VINT, 10V LS Gate Drive, and VCP go down. So my only concern is about BEMF decays in the coasting conditions and back driving other paths within the device. This exactly why the FG is checked in the enable circuitry. You'll just need to check the rails during the worst coasting conditions and see if anything pumps up. If there's nothing, then there's no concerns.

    The other piece of the equation is that the DRV8308 power on, ENABLE on, and RESET was designed with the assumption that the motor was not spinning and had no energy stored within it. As such, this is uncharted territory that may result in unexpected behavior. From that perspective, its just risk, there's no inherent problem.

    But the follow up is, if we run into problems with digital or control as a result of the workaround that can't be solved with some sort of analog workaround or interaction within the datasheet, then we're stuck and we're going to recommend you revert the change as the device wasn't designed in a straight forward manner to do what you want it to do.

    Hope this makes sense, let me know if you have any questions.

    Best,

    -Cole

  • 0 in reply to Cole Macias
    Prodigy 130 points

    Hi Cole,

    Thanks for such a quick and detailed reply.

    I am actually using the device in an application which does position control using a PID motor control loop algorithm which outputs the speed and direction. So the DIR input to the device is changing extremely often. This works very well and I'm able to do some pretty high performance motor control, the motor is also geared. Are you suggesting that if I pulse the DIR in the opposite direction during the stop sequence it may also start the motor back up?

    My device was designed to handle quite a bit of back-driving, so the back EMF is no issue and is easily dissipated by the rest of the system.

    I will definitely do some testing regarding unexpected control. From what you're saying, it doesn't seem like my workaround has potential to damage the device aside from BEMF issues which are already under control, is this correct?

    Thanks,
    John

  • 0 in reply to john sullivan
    TI__Mastermind 18900 points

    Hey John,

    Yes, the process would be flipping DIR to start the coasting process and then flipping the DIR back to the original direction after the desired coasting time (where the rotor is still rotating) to see if the DRV8308 catches the hall sensor inputs and continues to drive. Again, it probably won't work but it might. Let me know if I'm not understanding your intended sequence correctly.

    That's good. Yes, essentially the only potential damage I can see is BEMF related and if you say that BEMF is handled well then I don't see any issues with your work around.

    Best,

    -Cole 

  • 0 in reply to Cole Macias
    Prodigy 130 points

    Ah I see what you mean now about the DIR. However the device actually will do powered breaking rather than coasting when you flip the DIR which is what allows me to do position control.

    Very good to hear, thanks!

  • 0 in reply to john sullivan
    Prodigy 130 points

    Cole,

    Do you know what the input circuitry looks like on the FGIN_TACH pin? Since I left it floating I am slightly worried about spurious changes in the FG signal. Worst case if that pin picks up some continuous EMI then it could cause the chip to think it is at a constant speed of some sort. 

    Thanks,
    John

  • 0 in reply to john sullivan
    TI__Mastermind 18900 points

    Hello John,

    DIR:

    Good to know about DIR. The datasheet specifically shows if the BRKMOD is changed to coast, it will coast when DIR is flipped (table 5). Its always better to trust the bench data over the datasheet though.

    FGIN:

    I suppose that's fair. We can trust the FG circuit diagram in the datasheet, Figure 5. So, its an op amp and you can use all your op amp knowledge there. E.g. if you left the FBFG floating, the output is railed and you'd need some pretty high noise to couple in and flip the input. By I'm going to assumed you tied FGINN_TACH to FBFG which means its a voltage follower. GBW = 500kHz so anything higher than that should be attenuated. Otherwise, tying FGINN_TACH to FGINP would have been the way to go to get the constant output of "0V". I'll leave it up to you guide the conversation towards calculated risk or if you want to do a redesign.

    Best,

    -Cole

  • 0 in reply to Cole Macias
    Prodigy 130 points

    Cole,

    DIR:
    Are you referring to Table 5? I wasn't sure how to interpret that table so that is helpful, its possible that I'm wrong here since my system has relatively high friction. It doesn't freewheel though it is backdriven.

    FGIN:
    Unfortunately I did not connect FBFG to either pin, all 3 pins are unconnected. It seems that if I set FGSEL=2 then signal that reaches 2.7V could flip the output and if I set FGSEL=3 then the signal reaching 1.5V would flip it. The datasheet lists the input bias current as a max of 1uA, if that was 1uA typical then I might not worry. 

    I will definitely make a change for the next rev, but I need to decide between the current coast-and-stop behavior vs. the risk posed by the floating input for my units in the field.

  • 0 in reply to john sullivan
    TI__Mastermind 18900 points

    Hello John,

    DIR:

    Its pretty easy to verify on the scope if you have a voltage and current probe. Attach the voltage probe to U and current probe to U as well, trigger on DIR flip. If there is voltage on the phases after the DIR flip then you know the motor is coasting (as BEMF should be generated for the time it is coasting). If there is "no voltage" and current oscillating through the motor phase, then you know its Braking (as the phase has been connected to "GND" and current circulates through the low side FETs.

    FGIN:

    You know your system better than me I suppose. 1.5V or 2.7V sounds like a lot to me, the extrinsic noise would have to be huge to be coupled in. I'd just encourage you to test as much as you can and see how real of a problem it could be.

    Best,

    -Cole