3
\$\begingroup\$

We are driving a piezo transducer array with sub-1 μs pulses at an extremely low duty cycle. A single N-channel power MOSFET drives each transducer. Each power MOSFET transistor has a low side gate driver (FAN3229T) ahead of its gate to slew it quickly.

The transducer drive is not push-pull: there is no PMOS pull-up transistor to restore the transducer to its quiescent state. We have plenty of time between pulses so a simple resistor pull-up is fast enough to empty the transducer.

Here's another important piece of information: our 15 transducers all fire within 200 ns of each other.

I parked eight of these dual-port FAN3229T gate driver ICs next to the FPGA that creates the pulses. With no output load on the FAN3229Ts the FPGA is freaking out and resetting itself. The power MOSFETs and transducers are not present.

FPGA reset is caused by the eight FAN3229Ts boinking the ground plane they share with the FPGA. We can see these boinks with a fast scope. If we reprogram the FPGA to spread out its pulses in time (rather than all 16 be coincidental) the reset problem disappears.

Do unloaded gate driver ICs exhibit shoot-through current? The FAN series of gate driver ICs has a pair of push-pull MOS output transistors.

If there is indeed shoot-thru in the FAN gate drivers, I'm multiplying the shoot thru current by 16x when I ask all 16 FAN3229 channels to fire simultaneously.

Thanks in advance to anyone who can shed light on this.

\$\endgroup\$
4
  • \$\begingroup\$ Could you try a single driver IC on a breakout board to confirm your hypothesis? That would also allow you to experiment with ways of mitigating the effect. \$\endgroup\$
    – Bryan
    Nov 4, 2022 at 17:16
  • \$\begingroup\$ Thanks for the response, @Bryan. Technically I can do that experiment with a keyboard and mouse by instructing my FPGA to squelch some of its output pulses. We observe that fewer active transducer channels result in less frequent FPGA resets. Another thing I did earlier this week was spin a simplified PCB with 0.1 ohm sense resistors in the FAN's VDD and ground pins. I will be able to view any shoot-thru (or whatever) currents using a fast 'scope. \$\endgroup\$
    – jimolson
    Nov 4, 2022 at 17:27
  • \$\begingroup\$ Have you checked the FPGA's SSO (Simultaneously Switching Outputs) rating? What happens if you switch 15 IOs without the drivers installed, or on another FPGA IO bank? \$\endgroup\$
    – bobflux
    Nov 4, 2022 at 18:01
  • 1
    \$\begingroup\$ Please post schematic and layout of circuit around drivers. \$\endgroup\$ Nov 4, 2022 at 19:11

3 Answers 3

3
\$\begingroup\$

No, or generally not. But you might be seeing a similar effect.

Generally, drivers are designed to delay their two switches slightly, for obvious reasons. This goes from a convenience in small (200mA?) drivers, to required functionality in large (6A+) types!

There is still the capacitance of the output driver, where the PMOS is turned off, then NMOS turns on, and NMOS discharges its own capacitance (dissipated as power, no external current flow), and charges the PMOS's capacitance to VDD (dissipated as power, impulse current flows through supply bypass).

This capacitance is generally small (it's not rated, but may be inferred from the equivalent capacitance switching loss figure, which it will dominate), so it's not a good sign that it's causing problems already.

These current flows will only worsen once you add the MOSFETs, as their capacitance (and resistance, inductance and whatever other more complex characteristics may be relevant) add to supply and ground-return currents.

The solution in any case is better layout, particularly solid ground plane under each section (drivers and FPGA), with isolation of the currents flowing in the two sections (separate supply loop and return paths). This doesn't mean slotting a ground plane between them (for sure: do NOT route gate drive signals over a slot in the plane), but it can mean increasing the distance between them. Put the load on the far side, so that load current similarly flows in the local loop with the MOSFET, away from the driver. Place local bypass capacitors to source supply/load currents. If the FPGA is also supplied by the driver or load supply, consider an RC or LC filter to help isolate them, then regulate local to the FPGA.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks, Tim. Very good answer. We'll study this angle. \$\endgroup\$
    – jimolson
    Nov 4, 2022 at 17:14
  • 1
    \$\begingroup\$ Also consider adding additional decoupling capacitors near/around the drivers and eventually MOSFETs. These decoupling capacitors need to have tight, low-impedance return paths to the ground plane for the output stage. \$\endgroup\$ Nov 4, 2022 at 18:48
2
\$\begingroup\$

Without knowing the detail or seeing a schematic, the problem is grounding. It isn't shoot through, that is when totem pole transistors are both on, effectively connecting the supply to the ground. Use split plane grounding. In other words, the FPGA and controller have a ground plane area and the piezo and driver has a ground plane area. These two planes are connected at a single point so that the power currents cannot affect the control area. Ignore the following, testing sub and superscripts: V_dd, 10^2.

\$\endgroup\$
2
  • \$\begingroup\$ Yes, @AlStu your suggestion to segregate the FPGA's ground from the FAN3229T grounds is a good one that we plan to try. Thanks for offering it. However, when the basic design of a gate driver IC is that it has stacked NMOS and PMOS output transistors, it should be susceptible to shoot through as are the external power transistors that it's intended to drive. The FAN's output current is spec'ed at 2 amps, so these internal output transistors are huge. I have the FANs powered at 14V, so any time overlap between the PMOS and NMOS outputs is likely a fast sledgehammer to the ground. \$\endgroup\$
    – jimolson
    Nov 4, 2022 at 16:52
  • \$\begingroup\$ So much capacitance dumped to GND all at once!...MOSfet gate capacitance and piezo capacitance on top of that. Even with AlStu's suggestions, it may take a few PCB revisions to get it right, and still be fidgety. \$\endgroup\$
    – glen_geek
    Nov 4, 2022 at 18:25
2
\$\begingroup\$

The attached scope trace has 500mA per div vertical scale and 20 nsec per div horizontal.

The displayed signal is the shoot-through current viewed with a 1 ohm 0402 sense resistor placed in the VDD=+14V lead of a FAN3229T gate driver. Both channels of the FAN are connected together and triggered with the same pulse.

The measurement comes from a custom, postage stamp-sized PCB using nothing bigger than 0402s. The +VDD rail is rock solid. The PCB runs on a battery so it is floating with respect to scope ground.

The voltage across the 1 ohm sense resistor is measured with a U.FL coaxial connector with 4" of coax to the 'scope input.

My interpretation of the 'scope reading is that shoot-through current remains above 1 amp for at least 30 nsec and above 3 amps for a 10 nsec time window.

If I have qty=8 of these FANs running off the same FPGA clocking waveform, the array of gate drivers pounds on my FPGA's ground plane to the tune of ~10 amps.

This explains clearly why the FPGA is resetting.

Shoot-through Scope Trace

Shoot-thru Test Schematic

\$\endgroup\$
2
  • \$\begingroup\$ Great work! Is that the same for rising and falling? \$\endgroup\$ Nov 11, 2022 at 19:56
  • \$\begingroup\$ Tim, the shape/duration of the shoot-thru pulse for the other polarity transition was the same as this one but about half the amplitude. This entire thread about FPGA reset is embedded into a larger study of why my 15 piezo channels "crosstalk" with each other. The observed effect strangely did not scale with transducer current. I think the explanation for the crosstalk is that adjacent channels re-trigger on another channel's shoot-thru current. This was amplified by the extremely narrow Schmitt trigger band on the TTL variant of the FAN3229. The CMOS version was more forgiving. \$\endgroup\$
    – jimolson
    Nov 11, 2022 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.