Help: My tranny's are committing suicide!

[guru]

Hey. I've made an H-bridge out of IRF9530&530s. I have used a totem pole of two PN2222 transistors to drive each mosfet. A Xilinx 9572 CPLD is controlling the mosfet drivers. I have simulated with xspice the mosfet drivers and hbridge (but with only resistive load) in xspice and it works (although it shows some transients on the switching of the h-bridge due to N/P channel switching delays.) I have breadboarded the design and that works too. I now have a PCB and I am consistently popping transistors. I don't expect a clear solution but I could use some direction in how to proceed.

Yesterday, I apparently popped a P channel mosfet and the base and drain became shorted internally. I would never have expected this to happen. This began shorting that mosfet's PN2222 driver and they would start smoking.

After replacing the P channel the motor would turn under one direction. As soon as I toggled directions I heard a pop and nothing worked.

Could the transients be popping the mosfets? I have footprints for but have not yet installed the antiparallel diodes. I should also be leaving one quadrant of the hbridge on to dissipate the motor reverse voltage but I am not yet. So once I switch I would expect the voltage on the motor (being inductive) to be multiplied and then disspated accross the mosfets internal diodes once they finally turn on. There is also no injected delay in the switching of directions nor am I compensating for the delays in P and N channel devices yet. I should probably let the current in the motor windings dissipate some before switching directions.

The only difference between the breadboard version and this pcb version is I am using surface mount components for resistors and PN2222s, same TO220s fo IRFs. I would expect the transients to blow the breadboard version too but it didnt.

I checked the outputs of my mosfets drivers before placing the mosfets in, and they work correctly. Also, my CPLD is sequencing properly. I have a new tool where I can query the pin states of the CPLD by JTAG and see the traces on my pcb highlighted or shadowed based on the state of the pin. What a useful tool, you can see the working parts of much of the circuit with a glance.

Thanks in advance for the input.

Colin

[sonictj]

did you place diodes for back emf?

[guru]

As I said, I placed the footprint there but I didn't populate them yet. I was going on the internals though I know they are considerably slower to turn on. the breadboard version didn't have a problem. I will place them for my next attempt.

[Soeren]

Hi,

After replacing the P channel the motor would turn under one direction. As soon as I toggled directions I heard a pop and nothing worked.

Replace defective N-ch. device too.

Could the transients be popping the mosfets?

More likely it's a defective (i.e. shunted as you have discovered) N-ch. device directly under the P-ch. that pops.

[Admin]

What voltages and currents we dealing with?

Does the PCB check out fine unpopulated?

How does your Xilinx 9572 CPLD turn on the drivers? If you do the wrong pattern, you can create instantaneous shorts.

Stuff overheats before popping?

[guru]

What voltages and currents we dealing with?

12v right now though  I want to use 24volts. The parts are rated to at least 30v. Mosfets rated to 60v. I can't remember the motor current. But it is around 1amp, 0.7a nominal.

Does the PCB check out fine unpopulated?

Yes, I initially kept the mosfets off and the totem pole mosfet drivers are outputting the proper levels. I also confirmed that 0v was truly 0v and not "hi-z reading 0" on my VM. I also populated half-bridge and confirmed the motor turining. I then populated the opposite side and confirmed.

How does your Xilinx 9572 CPLD turn on the drivers? If you do the wrong pattern, you can create instantaneous shorts.

The code is verilog. My pcb software queries JTAG boundary scan pin states. So the traces visually light up according to the actual real time state. Corroborated with my VM it matches the proper pattern.

To further ensure I dont generate bad states I coded a very basic output verification module that takes A,B,C,D as inputs, verifies it is not an illegal pattern, and overrides with a freewheeling output and an LED if it is.

Stuff overheats before popping?

Not at all. Very cool. My mosfet drivers are designed to get through the resistive zone of the mosfet as fast as possible. ~1ns/v

The one issue I know I have is that I am switching directions too fast. I am in the process of creating a state machine that will switch to dynamic braking for a period then to the other direction. It will also account for the mosfet switching delays by using an external resistor of 10ohms on two io pins and the inherent 10pf capacitance of the cpld io pin (a simple timer) to inhibit output by 100ns when switching directions or braking.

I think the shoot-through of the mosfets due to the 25ns extra that it takes for the p channels to turn off plus the fact that I am trying to instantly switch directions without dissipating the current in the motor windings is causing large transients to blow the transistors. But...I am unsure why my breadboard prototype worked fine without a single blow.

What do you guys think?

[sonictj]

I'm a mechanical engineer not an electrical so I haven't had much formal training on this stuff, but it still sounds to me like your getting too much back emf.  I believe putting faster/ higher amperage diodes in your circuit may help.  The amperage seen will exceed the nominal during direction changes, will it not?  This I think is due to the nature of inductive loads.   Forgive me if I'm being totally ignorant here.

[Admin]

Yeap, sounds like back emf to me too.

Also, got caps across your motor/battery?

[guru]

Yeap, sounds like back emf to me too.

Also, got caps across your motor/battery?

Are you talking about decoupling caps accross the power? yes
Or are you talking about an RC snubber? no, I was thinking of going here.

[guru]

I have been out of the country for a bit, but back on the case now. I think I just discovered the problem, kind of by accident!

Hypothesis: Optoisolators (of the open-collector type) have too slow slew for CPLD inputs. CPLD inputs must transition within 20ns if my memory serves me right. When the open-collectors open, the 10k pullups on the optos would take about 180microseconds to pull the input voltage to Vcc (my opto capacitance is 18pF).

Result: During direction change, jitter occurs causing the h-bridge output decoder to bounce between forward and backward. I would surmise this would either act as some sort of voltage doubler on a inductive load or at the least cause a lot of shoot-through for about 180 microseconds.

Corollary: Circuit worked fine on breadboard with optos when decoder logic was implemented in FPGA. FPGA inputs are more tolerant of slow slew rates and have configurable schmitt inputs.

Solution: Add schmitt inputs. Also lower pullups on optos to 1k.

I caught this when I put my virtual instrument counter on one of the CPLD inputs and it was counting by 1 pulse when the opto closes, and counts about 40 pulses when it opens. It should only count 1 pulse.

Colin

[guru]

Confirmed. The h-bridge now works 100% and the mosfets stay totally cool during full use.

Thanks,
Colin