DRV8701: H-Bridge Driver

The PWM input is precisely with 600ns pulse width, and so the Jitter-narrow waveform is the correct output, but the driver somehow widen the next output to more than 600ns as can be seen in the Jitter-wide pic. So the driver chip drove the output low late.

Hey Brian, 

Thank you for the detailed information and scope shots in your post!

Brian Dang said:

1. The datasheet spec lists tDEAD = 380ns TYP, but page 21 saysthe chip inserts a dead time of about 150ns, and when I provided an input pulse of 400ns to the EN pin, all 4 gate driving pins were zero volt -- it seems to me 400ns PWM input is not wide enough but I can't find this violates the spec of tDEAD. Only when input with 500ns or wider pulse then the GHx output has signal. Could you comment on this?

For this you're looking for the Propagation delay, tPD, which is 500ns.  See 7.3.8 Propagation Delay for a description.  See this application note for a more thorough discussion on it, specifically the scope shot on page 4:  Delay and Dead Time in Integrated MOSFET Drivers

Brian Dang said:

2. With input supplied with a constant PWM signal with 600ns high and 19.6Khz frequency, the GH1 and GH2 outputs have 80ns jitter on the falling edge, causing audible noise in the driven motor. The IDrive is about 4.2V so the gate signals should have fast slew rate. What is the root cause of the jitter?

Interesting, can you try it at a lower PWM frequency to give the FETs more time to switch?  I wonder if 20kHz is too fast for the FET+iDRIVE combination in this board. I posted on Pololu's forum asking for the specs of the FETs, hopefully they'll tell us, or maybe you can read the writing on the top of the FET on the board to determine what it is.  

Also, can you try a higher VM voltage to see if that solves the problem, maybe 36V?  I am concerned about the rapid decrease in voltage in your scope pictures from 20V down to 12V by the time the FET switches off.  It would also be useful to see the nFAULT signal included in the same images you put above, just so we can rule out OCP or CPUV as the culprit.  

Regards,

Jacob

Hi Jacob,

1. Thank you for pointing out the tPD and I understood now.

2. I reduced the PWM frequency by half to 10Khz, and no change to the jittering issue. Please see waveforms below.

Keep in mind that these waveforms are the FET output, but the same jitter is also on the DRV8701 output gate driver GHx signals.

Regards,

Brian

Jacob Thompson said:

maybe you can read the writing on the top of the FET on the board to determine what it is.  

The FET is 2R304 with small gate charge of 8nC.

Brian

Hey Brian,

The TPN2R304PL has a QG of 41nC according to their datasheet, and for VM>12V IVCP=12mA, so 12mA / 20kHz = 6e-7 = 600nC which is plenty bigger than 41nC.  So I doubt that's the issue.  

Have you looked at your input signals on the oscilloscope to make sure your input signal doesn't have the jitter?  I doubt it does, but worth verifying.  

Did you add additional bulk capacitance to the board?  I found this recommendation on the Pololu page: 

It looks like our EVM uses 2x 470uF 50V capacitors.  That's probably overkill, but I would try at least an additional 200uF total.  

If that doesn't work, is there any chance you could order an EVM and test it out on there to see if the same thing happens?  https://www.ti.com/tool/DRV8701EVM

Regards,

Jacob

Hi Jacob,

Below are the input pics with 600nS pulses: one at the scope triggered point, and the other right after and we can see there is no jitter on the PWM pulses generated by the SMT processor.

As about additional bulk capacitance to the board, I don't think it's the issue because the board already has a ceramic and an electrolytic cap of at least 10uF or 100uF (with marking 100, HFT, 631 on the body) with 6.5mm OD and 7mm height, a good size, and then I only turned on the FETs for 600nS out of 10Khz frequency, or 0.6% duty cycle, so this tiny energy pulse should not cause the VM to have any noise from high current rush.

By the way, even without motor connected to the H-bridge, the DRV7801 still have output jitter. I think it's time to ask the chip designer of what can cause the GHx to delay its falling edge at every other pulses.

First pulse:

Next pulse:

Regards,

Brian

Hey Brian, 

Agreed, I'll put in a ticket to our Design Team and see what they say about it. They typically take about a week to respond FYI.  I'll also bring it up to my manager and see what he thinks, he might have good ideas for other things to test.  

Ahh interesting that it has this jitter without any load connected.  Let me know if you do any further testing in the meantime with it.  

Regards,

Jacob

Jacob Thompson said:

The device digitizes the input PWM for controlling the bridges. Digitization is done by sampling signals with internal clock frequency. Because of digitization/sampling there is an uncertainty based on timing of internal clock and PWM signal. This comes out to be same as the sampling frequency or minimum frequency clock used in Driver control digital implementation.

Hi Jacob, 

Even with quantization of the input pulse the result output should be a stable pulse width signal with a constant pulse width input signal. How can you explain that the output dither between 560nS and 640nS with a 600ns input pulse?

Jacob Thompson said:

Try a much lower PWM frequency, like 5kHz or even 1kHz.  Try to confirm that the variation between pulses is what is causing the jitter. The overall motor noise will probably increase as you lower the frequency, but maybe there will be a sweet spot of minimum noise.  

This is not a practical idea, as nobody want to drive a motor with a PWM frequency as low as 1Khz to 5Khz, as this would cause deaf ears with the audible noise. This is why most motors are driven with 20Khz or higher pwm. The other reason to use higher than 20Khz pwm is for motor with low inductive coil wirings to avoid ripple current.

Jacob Thompson said:

Lower the VM voltage for your motor so you can use a longer pulse-length or duty cycle for a given motor speed.  Trade-off of course is the max motor speed, unless you use a switching circuit to switch the VM from a low value and high value depending on needed speed range.  

In our case, the noise is so noticeable when the motor is stopped, with only a very small pwm from the Integrator of the PID servo control loop. You cannot assume that the motor control dynamic will always have a wider pulse width, because when the motor stopped, the pwm driving signal (result of the PID loop) could be zero or a small pulse, in my case, a 600ns pulse.  Regardless, the pulse width, the driver chip always has the output pulse dithering between two values. 

Jacob Thompson said:

Consider a different motor driver - if you give me the requirements of your system I can suggest a chip.  If you need these very low duty cycle I can ask design team if we have a gate driver or integrated driver that would be best for this application.  

Why the output pulse dithering between two values is not clearly pointed out in the datasheet? I don't expect that the output is the exact pulse of the input, considering the dead time and propagation delay, but the output should be a stable pulse if the input is a stable pulse. 

Ryan Kehr said:

Unfortunately, a lot of our drivers use this same input deglitcher circuit to avoid noise at the inputs passing to the outputs. 

Hi Ryan,

I have been using many kind of FET drivers, from Allegro, International Rectifier, Infineon, STM, Vishay, to name a few, and have never seen anything like this. Could you verify the dithering issue on one of your EVM? As I still don't believe that TI has many of FET drivers that having this output issue, because the dithering is not specified in the datasheet of this chip. If you know any datasheets of other drivers that mentions the dithering then I believe it. 

If this is true, why TI had not revised the datasheet to warn the users of the output dithering?

I understand the benefit of adding features such as deglitching the input noise, but importantly it should not add bad feature to the chip as in this case to guarantee causing audible noise to the motor. I mean the user is responsible for their input signal, and so TI should not try to be a hero that ended up with a bad feature. Just imagine having a cinematic lens with motor driven Focus and when the cameraman pull the focus to 10 feet and stop -- with still a small residue of pwm of the Integrator to overcome the friction -- then the camera continues to record with a 10Khz noise (motor driven with 20Khz pwm). Many TI drivers can work with pwm input up to 100Khz and higher so to be out of the audible frequency, then why the designer was Okay with the dithering audible noise?

I'm curious of what sort of deglitch circuit that causes the dithering on the output. One would imagine the designer just added a digital low pass filter to reject  the narrow pulses, and this should not cause the dithering issue.

Regards,

Brian

Hey Brian,

Check out the DRV8770 and it's EVM - this is our most basic gate driver and doesn't have the input deglitcher.  

I'll let Ryan answer your other questions, as I only recently started working at TI.  

Another option to consider is looking into using a brushless motor driver and just not using one of the outputs, we recommend looking at the DRV8320H.

Regards,

Jacob  

Thank you Jacob, but I just want to see a datasheet that specifies the output dither about. Why TI does not include this important parameter? What if when under other different conditions the dither is more than 200ns? If TI knows there is dither on the output caused by the deglitch circuit, then why not tell the users how much is it?

Brian

The reason I would like to see that TI should specify how much jittering on the output: there are many different applications that the users want to use this driver for, such as drone which doesn't care the low audible noise of the jitter in the motor coil, but for others applications it is a no pass with the high frequency audible noise (indoor security remote control cameras, or Cinematic lens focus control). With the jitter parameter specified in the datasheet, it would save many Motor Control engineers the trouble of debugging and save TI employees the trouble of repeating the explanation.

Brian

Hi Ryan,

Currently the driver chip is used to drive 2 voice-coil motors to move the optical elements on the X and Y axis, to create image shaking movie shots in the movie industry, i.e. earth quake, racing car bouncing, action movie explosion, etc. Before and after the shaking footage, the X and Y optical elements are held at the lens optical center, and the motors are in servo closed feedback loop at the desired positions, and so the PWM inputs are unchanged or very little. 

Currently we have a few prototype products for filed testing, and I will take a look at those suggested driver when we are ready for production run. If TI datasheets not clearly say which drivers have output dithering or jittering, then the selection of the driver will be unclear.

Regards,

Brian