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.

DRV8834: Enable Pin Timing Requirements

Part Number: DRV8834

I am using DRV8834 to drive a 5V 25Ohm bipolar stepper and I am interested to know what the timing requirements for the ENABLE pin are?

Looking at the datasheet, I see the SLEEP requirement pin requires 1ms before issuing a step command, whereas DIR for example only requires 1.9us. I can't specifically see the ENABLE pin requirements.

What I am finding though, is that if I write a simple sketch that goes: Enable, Delay, 1 Step, Disable,

Unless the delay is 1ms, the step is not made. If I put the delay down to the 2us , it appears that the step is not made.

This may not seem too important, but this feature means that if my sketch goes: Enable, Delay, Many Steps, Disable,

the first step or two is not made, so I have a very slow cumulative error.

From this simple test I conclude that the ENABLE pin timing requirements are the same as the SLEEP pin requirements and a 1ms delay is needed before a step command is issued, otherwise the coils may not have energised and the step will not actually be made, leading to a small but cumulative error. Has anyone found a similar issue, or is my conjecture incorrect?

I am using the indexer step/dir method of driving and no microstepping, with 50% mixed decay.

The second part of my enquiry concerns good practice really: Is it better to go: Enable, complete move, Disable  OR Enable, one step, disable. 

I don't need any holding current and it seems that aside from the enable timing requirements, the second option causes the voltage regulator to run at a much lower temperature, presumably because it is drawing much less current for much less time?

Many Thanks

Alex

  • Alex,

    What is CONFIG pin voltage and nSLEEP pin voltage when you do the nENBL pin test?

    "From this simple test I conclude that the ENABLE pin timing requirements are the same as the SLEEP pin requirements and a 1ms delay is needed before a step command is issued, otherwise the coils may not have energised and the step will not actually be made, leading to a small but cumulative error."

    Do you test nENBL pin? Please make sure nSLEEP pin high and CONFIG pin high when you do the nENBL pin timing test. 1ms delay seems too long for nENBL pin. 

    CONFIG pin can select the Indexer mode and the phase/enable mode. Assume CONFIG pin is high (indexer mode) when you do the test. The motor movement is not related to nENBL pin because nENBL keeps high when the motor is spinning. A STEP pin pulse can make the motor move to next step.

     

    BTW, if CONFIG pin is low (phase/enable mode). Please check figure 15, 21 and 22 to understand the input signal vs output signal.

    Regards,

    Wang Li

  • Thanks for looking at this.

    I can confirm that both the sleep and config pins are connected to logic high voltage permanently (supply voltage rather than McU controlled)

    Does this mean that there is a 1ms wake up time from assertion of nENBL to the assertion of STEP pin? This would match the SLEEP pin timing requirements.

    Thank you

    Alex

  • Alex,

    Yes. If both the sleep and config pins are high before nENBL pin test,  there is a 1ms wake up time from assertion of nENBL to the assertion of STEP pin. 

    It should be OK because nENBL keeps high when the motor is spinning with the indexer mode.

    Regards,

    Wang Li

  • Thank you for this confirmation.

    It would be very helpful if this information was added to the timing requirements section in the data sheet, because although sleep pin requirements are given, I couldn’t find anything about enable. Specifically this is in indexer mode when sleep and config pins are pulled high.

    Both the motor driver I wrote and another open source driver I found have assumed the timing requirement was 2us, the same as Dir pin etc and it appears to work well, but because the delay is not long enough, the first step or two is missed - the error is worse, the quicker the step frequency. Of course if you reverse the direction, the error is reduced or reversed. 

    The best way I found to demonstrate the issue that may be of use to to others was to call for a step of 1 repeatedly. If the time between the assertion of enable to the assertion of step is less than 1ms, the motor doesn’t move, it just buzzes! Another simple test is to call for a complete rotation repeatedly, with a small delay after each rotation and it is seen that the position of the shaft at the end of each rotation, gradually processes, since the first steps of the movement are not made.

    I have looked at some of the other DRV motor driver chips data sheets and they seem to be similar, so perhaps this information has a wider relevance?

    Many thanks for your help

    Alex