DRV8825 temperature behavior on different microcontrollers

Hey guys,

I’m using the DRV8825 to power a Nema 17 42BYGHW811 stepper motor.
When I hook those things up to my Arduino Uno R3 everything works just fine.

If I hook it up to my Spark Core (docs.particle.io/datasheets/core-datasheet/) the temperature rises really quickly. In 10-20 seconds i can measure temperature peaks up to 70 degree celsius. In the final system I need the drivers to run for 10-30 minutes. Right now I have no cooling installed (but I will cool the drivers with passive + active cooling). Right now Vref is set to 0,85V so the current to the stepper is 1,7A (70% = 1,2A) … so … nothing special.

I’m so confused because the Arduino setup with those drivers is soo much cooler. Any ideas? Can it somehow be related to the faster clock speed of the Spark Core?

Hello.

70C sounds reasonable for the DRV8825 at that current range. How did you measure that temperature and did you measure the temperature with the Arduino? The thermal protection for the IC activates at about 150C, so I do not think you need to be concerned about thermal damage to the board at 70C.

The operation frequency of the microcontroller controlling the DRV8825 should not affect power dissipation, but other things can, like operation mode and the step rate. Can you tell me which pins on the stepper driver you had connected to your Arduino UNO and which ones you have connected to the Spark Core? Could you also post pictures showing the connections?

-Nathan

Hey,

I notice that the DRV8825+Arduino temperature get likely as hot as the DRV8825+Spark Core setup… but not soo damn fast like with the Spark Core. I measured the temperature with a temperature gun. But okay … I’ll keep an eye on the temperature and now I know when to be concerned.

The wiring of both setup is identical. The stepper is running in fullstep mode and the same code is executed on both Microcontrollers. But there is another issue I experience: When I the AccelStepper library the stepper with the SparkCore setup behaves differently than the Arduino setup. I made a quick video, here:

Top upper stepper, that is connected to the Spark, is running really slow compared to the Arduino connected stepper (the lower one). Again, same code is executed. When I use microstepping the effect gets worse.

When I don’t use a library, the steppers are in sync:

Do you have an idea how to solve this? I think its a bug with the library (the SparkCore uses an own version: github.com/alotaiba/AccelStepperSpark) … but nevertheless maybe you got an idea that I can share with the authors.

Thanks for your kind help!
Vinzenz

Hello, Vinzenz.

It sounds like it could be a difference in the implementation of stepping in the different libraries, but I am not an expert in those libraries. Both of these microcontrollers should send HIGH or LOW voltages to the digital pins on the stepper driver. The communication protocol is pretty simple, the mode pins are held either HIGH or LOW to place the driver in the appropriate microstepping mode and, while the drivers are in this mode, any LOW->HIGH pulses to the STEP pin should result in the stepper moving a single step/microstep. You can read more about the modes on the product page for the DRV8825 carrier board, though since you have implemented your own code, it sounds like you might know some of this already.

To determine why the library behavior is different, you could set up some code that you expect to maintain a single microstep mode for several seconds and measure the outputs to the MODE pins on the stepper driver boards with a multimeter to ensure the output signals are what would be expected. Also, many inexpensive multimeters have a frequency measurement mode, which could be a good way to measure the rate of stepping signals on the STEP pin if you have code that keeps the stepping frequency constant for several seconds.

Checking those things might give you a little more information to post in a forum that has members more familiar with how those libraries are written.

-Nathan

Hey Nathan,

the different behavior was a result from the Spark Core with very poor performance when it is connected to the cloud. Standard settings force a steady and stable connection to the cloud, which requires a lot of computing power, and therefore only few capacity is left for the calculation of the steps.

So, putting the Spark in a manual mode (SYSTEM MODE(MANUAL)) solved the problem for me, therefore this topic can be closed.

Hello, Vinzenz.

Thanks for letting us know you were able solve the problem. In general it can often be useful in systems like this to have a separate microcontroller handle real-time operations like driving a stepper motor and use a higher level system to handle higher latency operations like network communications. It sounds like you were able to put the Spark core into a mode that somehow gives higher priority to your stepper motions, though.

-Nathan