TI E2E Community
Motor Drivers Forum
I'm going to fabricate my first PIC-like F28027 main board, where I'm going to drive a small motor using TI's DRV8832.
BUT before that, just a quick question: I'm just wondering if it's necessary to put resistors and diodes in between the pins of the F28027 to the DRV8832? I'm caught between two outcomes if I don't put any; whether it might induce erratic behavior due to the motor's spikes OR if I do put diodes/resistors might it render the output current too low?
In case for PICs, the use of diodes and resistors in series are usually desirable for stability when I'm connecting it to a driver. However, I don't know if there are already internal designs in the DRV8832 which takes care of such things.
Hope for your replies soon.
Vortex Electrica Corp.
The DRV8832 device has an internal pre-driver stage which isolates the IN1/IN2 inputs from the motor outputs, so you don't need to worry about using diodes to protect your F28027. Most of our devices have weak pull-down resistors on the inputs, but if you are worried about the logic pins floating whenever the MCU is reset then it would not hurt to put an additional pull-down resistor to ground on your logic traces.
Any extra circuitry on the IN1/IN2 pins also will not affect the current output of the device because of the electrical isolation the pre-driver stage provides between the inputs and the outputs of the device. The current output is limited only by the value of the current sense resistor connected to ground on the ISENSE pin. The current limit is calculated by using Rsense = 200mV / Current Limit. Keep in mind that this does not guarantee that your device will deliver this much current to the motor - rather, it is designed to keep the current from exceeding this value in situations such as motor stall or high inrush current on motor start-up.
Hope this helps! Feel free to ask if you have any other questions.
I am not certain what was the use of the resistors and diodes in between a microcontroller and a power stage, but maybe it was the power stage you were dealing with on the previous project. Rest assured that with the DRV8x family of power stages, there is no need to place any component in between the microcontroller and the power stage as the power stage is well protected against pretty much any control structure I can think of (MCU, FPGA, etc).
You will see in our EVM's we use resistors in between the microcontroller and the device under evaluation. The reason for these resistors is so you can easily evaluate the device with your own microcontroller without needing to desolder the MSP430 from the board. Other than that, the EVM would have worked perfectly fine without the resistors.
Do note the only signals where you will in fact require resistors are those open collector outputs, such as nFAULT.
Hope the info helps. Best regards,
To Mr Casey and Mr Jose Quinones,
Thank you very much for your replies. I'm entering the final stages of design and will be submitting soon. The reason of my inquiry is that it is my personal experience, when using a standard issue driver like ST's L293D, and if I don't use any diodes for Microchip's PICs, the PIC will behave erratically. Now, the option of using resistors are pretty easy when dealing with through-hole devices. But the DRV8832 is certainly pretty small for me to add resistors plus when I'm unsure of the necessity to do so anyway.
I'm using Texas Instruments' very own DSP: TMS320F28027, in case you're wondering. The application is to drive a CD-drive motor, which has a very high drop of revolution ratio at the driving end.
1. Quote from the datasheet:
if VREF is connected directly to VSET, the voltage will be regulated at 5.14 V
So does it mean it'll be regulated at 5.14 even if the supply is less than 5.14V? I suppose extra resistors for voltage division will make it difficult for soldering when I'm only doing double layered PCBs.
2. Also as the datasheet said regarding the FAULTn:
If this analog current limit persists for longer than the OCP time, all FETs in the H-bridge will be disabled, and the FAULTn signal will be driven low.
The device will remain disabled until VCC is removed and re-applied.
Does this mean the FAULTn pin will stay at high when it's functioning? Is there any necessity to monitor the pin via the DSP?
Any other advice is very much appreciated.
Thanks a lot guys.
I took a look at the ST L293D data sheet, and at first glance it looks as if it lacks the protection circuitry the DRV8832 has built in. Rest assured that motor interference will not be a problem for your application.
To solve your resistor problem, the TMS320F28027 comes equipped with internal pull-up resistors on all the GPIO pins. These are individually programmable on a pin-by-pin basis. It's my experience though that these will not be necessary with TI motor driver parts as I have gotten all of our devices to respond to digital logic with no external circuitry required (except, as Jose previously pointed out, on the FAULTn pin where an external pull-up resistor is required because it is open-drain).
1) The DRV8832 voltage regulation feature does not boost the voltage to the regulated level. A PWM technique is used to limit the output voltage for a constant-speed application with a varying voltage supply, such as a 9V battery.
For these applications, a lower voltage (such as 5.14V) can be set as the chosen regulation level, and the device will scale the 9V input down to 5.14V. As the battery discharges and the voltage output decreases, eventually a point will be reached where VCC=VSET*4. At this point the PWM is at 100% duty cycle and your output will match your supply voltage but cannot exceed it. As the battery continues to discharge below this setpoint, the output voltage will be unregulated and fall with the supply voltage.
Depending on your application, your may or may not desire this feature. But, in effect, what this does mean is that if you choose to use the device-supplied VREF and connect it directly to VSET, your maximum voltage output for the device will be 5.14V. If you are operating at a point where your VCC is below this level, your voltage output will be un-regulated. If you desire to operate at a higher output voltage than 5.14V, you will need to supply VSET externally or through some voltage divider off of VCC. Keep in mind that the measured output voltage is divided by 4 before compared to VSET, so your maximum output voltage = VSET*4.
2) During normal operation, FAULTn is floating and will only be logic high if connected to a pull-up resistor. I don't suppose it's absolutely necessary to monitor this pin with DSP. However, if the pin is not monitored at all, you will have no feedback on if the device is properly functioning.
In our EVMs, it's pretty common practice to include the pull-up resistor with an LED in series on the FAULTn pin for visual feedback when the motor is in fault condition. This will at least let you know that something has gone wrong - but you will need to disconnect and reapply power to your entire system if an OCP fault is encountered. This is not necessarily a bad thing, as the OCP function is designed to fault only if something serious such as a short in the motor winding has occured. In this case, you would probably want to turn th power off anyway.
Good luck with your design, feel free to ask if you have any other questions!
That's a VERY elaborate reply. Thank you very much for your time. I have completed wiring up the rest of the DRV's pins. Next phase is the testing part.
I'm glad I could be of assistance! Please let us know how the testing of the device goes or if we can help out in any other way.
Best regards, Casey
I too am developing a small µC controlled device with a motor and I am using an 8832 driver. My entire board and the motor run at 3.3V and I do not want to use the PWM voltage level control feature of the 8832 so I tied Vset to Vref. However, when the µC sets IN1 HI and IN2 LO the power applied to the motor is ramped up via pulses. I do not expect this based on the data sheet statements "Note that if the programmed output voltage is greater than the supply voltage, the device will operate at 100% duty cycle and the voltage regulation feature will be disabled. In this mode the device behaves as a conventional H-bridge driver." In addition, when the µC sets both IN1 and IN2 HI, the power applied to the motor is pulsed down to 0 over many miliseconds.
Is my expectation that when the voltage regulation feature is disabled, the power applied to the motor will directly follow the µC signals incorrect? Or do I have a malfunctioning device? Or is perhaps something else going on?
In case you're wondering, my circuit worked out quite well. Thanks a lot for your help.
..............and hi Kerry,
I'm not sure what you meant by "ramped up via pulses"?
The way it worked was pretty straightforward, but I only turned either pin 1 and 0 without any pulses. Perhaps Casey can elaborate more.
What I meant by "ramped up via pulses" is that the power applied to the motor was ramped up (and down) using a voltage across the motor terminals that looked like a pulse width modulated signal. Initially on the way up, the voltage was HI for a short duration and LO for a long duration. As time progressed, the HI voltage was present longer and the LO voltage was present shorter until the power applied was continuous. During this entire time, the voltages on IN1 and IN2 from the µC were constant. So the inputs to the 8832 were constant but the output was pulsed like a PWM signal.
I hope this clarifies any confusion caused by my imprecise use of the English language.
Your expectations on how the part should work based on the datasheet are correct.
I recreated the setup you described in your first post using our DRV8832EVM and was able to see the same output PWM on motor startup.
I believe this is being caused by a feature other than the integrated voltage regulator. On Pg. 9 of the datasheet under "Current Limit" it is described that the DRV8832 limits the output current without disabling the device in situations such as motor startup or stall. The device monitors the voltage across the Isense resistor and the output PWM duty cycle is reduced automatically if the output current exceeds the 200mV threshold.
In your case, I believe on motor startup the inrush current demanded by the motor trips the current-limit threshold and the PWM is generated to try to limit the output current. After several milliseconds, the motor has spooled up and the current demanded by the motor decreases. Then the PWM is disabled because the current limit threshold is no longer being tripped.
There are two ways I can think of around this. If you still desire to use the current regulation feature, you may increase the size of the Isense resistor and the current limit threshold will be adjusted according to Eq. (1) on Pg. 9 of the datasheet. By raising the current limit threshold to something higher you may avoid seeing the PWM on startup due to inrush current. If the current regulation feature is not desired at all, you may connect the Isense pin directly to GND with no sense resistor and this should remove the PWM problem entirely.
Alternatively, if you need neither the current regulation feature nor the PWM voltage regulator feature, you may want to consider using our new part DRV8837 instead. It is a bare-bones H-bridge IC where outputs respond directly to inputs. You can check it out here: http://www.ti.com/product/drv8837
Hope this helps! Let me know if you have any other questions.
You're very welcome, I'm glad to hear everything worked out!
Thank you for your detailed description. You mention that you see pulsed output power on your setup at start-up time. Did you see it at shutdown time too? This is the behavior that I am trying to understand. The power pulsing at motor start-up is not really a problem. I simply do not expect to see it. But the 10s of ms delay between placing the 8832 device inputs into BRAKE configuration and the voltage across the motor terminals pulsing "down to zero" is unfortunate and confusing.
Unfortunately for me, I have already tried tying Isense to GND and that does not change the motor power output of the 8832 device. I intended to mention this in my first post but forgot. It may be that the inrush current through the 12ohm motor coil is sufficient to trigger a thermal shutdown.
When I combine this newly confirmed understanding with the facts that the 8832 power output also lags the input at power shutoff time by 10s of ms and that the Vref voltage is 2.6 V (which is incorrect but probably shouldn't matter) I am hoping/becoming convinced that the device I am using is not functioning correctly. I have been using it for some hours. I suppose I may have damaged it somehow. I will have to get another one and try it to see if the behavior is consistent.
Also, thank you for the reference to the 8837 part. I was aware of it but chose the 8832 because I do want to use the current sense feature in my final design.
I do not see any pulsing when I go into the BRAKE configuration, but I do see the voltage ramp down similar to how you described when I go into the COAST configuration. I've grabbed a couple of oscilloscope waveforms to show you what I see on my device. These traces are all referenced to the GND of the power supply. You mentioned measuring the "voltage across the motor terminals" which may look different.
Similar to what you see, when I go from "off" to "forward" by bringing IN1 high, I get the pulsing due to inrush current.
When I put the device in BRAKE mode by bringing IN2 high as well, I don't see any pulsing on either side of the H-bridge.
If instead I put the device in COAST by bringing IN1 back low, I see this waveform as the voltage decays to 0. With the particular motor I was using, it took >1s for the voltage to settle down to 0 completely. This is the expected operation of the device since when put into COAST, the H-bridge is put into Hi-Z mode rather than shorting the motor terminals as in Brake mode.
I don't think the motor you are using has enough resistance to cause a thermal shutdown since this would disable the device completely until the temperature drops to a safe level. Do you see this kind of behavior in startup?
Based on the information you have provided I would agree that your device is most likely damaged. The Vref output of 2.6V is above what is specified as the absolute maximum by the datasheet - this is a sign that the internal reference circuitry has suffered a failure and I would not trust the rest of the chip to behave exactly correctly if this is the case.
Hope this helps! If you still see this kind of behavior on the next device you test please let me know and I will help you to troubleshoot further.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.