• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 639 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

DRV8308: Motors must finish coasting before ramping up

DRV8308: When the motor stops, it sticks for about 0.5 seconds

AndrewJ5367
Prodigy 160 points
Part Number: DRV8308

Hi Everyone,

I am using the DRV8308 to drive a 77W Brushless DC motor.  It is working quite well at the moment in "clock frequency mode".  However, I'm suffering one minor glitch.

Whenever I bring the motor to a stop, I do so by bringing my clock close to 0Hz, and then disabling the clock peripheral on my microcontroller (TIM_Cmd(CL_PWM_TIMx, DISABLE);).  When I do this, the motor does stop, but "sticks" for a fraction of a second afterwards.

It's almost as if chip is taking a moment to come to the realization that the clock has finally stopped. 

Pulling the ENABLE line low fixes this, but I need to read FGOUT so this is not an option for me.  Is there another register setting or GPIO that can be used to stop the "sticking"?  Is it a well-known issue?

Thanks for your help!

Andrew

  • 0
    TI__Guru 61280 points
    Andrew,

    When you say "sticks" do you mean the motor is braking? If this is the case, try flipping the state of the BRKMOD bit, the device might be attempting to Brake the motor as the clock disappears to make sure the motor isn't still spinning.

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    Prodigy 160 points

    Hi Adam,

    Thanks for the quick response.

    The BRKMOD bit is set to 0 on initialization of the chip.  I have tried re-writing the BRKMOD bit to zero every time the motor comes to a halt, but so far, the situation has not changed.

    As for your question re: braking.  It does feel very much like braking.  The odd thing is, it doesn't happen every single time the motor comes to a stop.  Sometimes it is free to move and can coast after coming to a stop, and sometimes it exhibits the short duration of braking followed by freedom.  This happens about 50% of the time.

    Andrew

  • 0 in reply to AndrewJ5367
    TI__Guru 61280 points
    Andrew,

    Can you send me a plot of the "sticking" and "not sticking" behavior?

    I'd like to see the same phase Hall input, SH node, GH, GL.

    Have you checked to be sure that the Hall input matches the phase input when connecting to the board?

    For example, if the phase input and hall input were mismatched, it may cause a weird braking that randomly comes and goes if the phases randomly align certain ways when slowing down.

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    Prodigy 160 points

    Hi Adam,

    I am unsure what you mean by SH, GH and GL.

    I did manage to get an oscilloscope capture of f_clkin compared to FGOUT.   They have the same frequency, but they are not locked in phase.  FGOUT is always "walking" off compared to the f_clkin.  Does this indicate a problem?

  • 0 in reply to Adam Sidelsky
    Prodigy 160 points

    Hi Adam,

    Just looking at Table 5 of the datasheet.  Is it possible that I could be facing an unavoidable situation of braking?  According to this table, as soon as the clock stops, and ENABLE is still asserted, the brake will be applied.

  • 0 in reply to AndrewJ5367
    Prodigy 160 points

    I have a hypothesis about what is happening here.  I have tried de-asserting ENABLE and putting it on a timer to re-assert 100ms, 200ms, 500ms and even longer.   Eventually when ENABLE does get re-asserted, the motor inevitably locks up (brakes) for about a second before letting go.

    What I think is happening here is that it doesn't matter how long you wait.  So long as ENABLE is asserted and f_clkin (clock) is quiet (even if BRKMOD=0) the brake will be applied.

    I am thinking that the brake eventually relinquishes itself when the ENABLE is asserted, the clock is quiet, and nothing happens for over a second, and the device enters low-power state, letting go of the brake.

    -----------------------------

    Datasheet: 7.3.3 Enable, Reset, and Clock Generation.

    "After motor rotation has stopped (when no transitions occur on the FGOUT pin for a period of 1 s), the DRV8308 device enters a low-power standby state. In the standby state, the motor driver circuitry is disabled"

  • 0 in reply to AndrewJ5367
    TI__Guru 61280 points
    Andrew,

    Can you slow the clock to almost zero but keep it running slowly and then use the Brake intentionally?

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    TI__Guru 61280 points
    Andrew,

    I have seen no update on this thread, did your issue get resolved?

    I will mark this thread as closed but please post if you need further assistance.

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    Prodigy 160 points

    Hi Adam,

    Sorry for my slow reply.


    My ultimate objective was a "coasting start" where I could push the outdoor vehicle, command a speed (eg. 100Hz from the DRV8308) and go straight away from that speed.

    In summary:
    We had a bit of a "chicken and egg" problem, whereby if I had ENABLE asserted, I could read FGOUT with no problems.  But before I could "coast", the brake would be applied for 1 second (f_clkin == 0Hz), which turned out to be unavoidable.  But of course having ENABLE dis-asserted meant we couldn't read FGOUT.

    Solution:
    The solution was a complete workaround not involving FGOUT.  We had magnets inside the hub of the vehicle's wheels with a hall sensor on each wheel.  The resolution of these readings was nowhere near as good as FGOUT, but had to suffice in the end as a workaround.  We take the wheel magnet hall sensor readings (might be 50Hz), and then assert ENABLE and ramp up to that speed with the DRV8308.