Re: Strange Bridge Controll issues(again)

Everything works up until this point. I get problems when going into the max

>chips(which simply take the output's of the logic as input's). > >The circuit is extremely simple > >
formatting link
> > > >Now that I think about it, the fets could be getting warm due to >"shoot-through" since I'm not delaying the signals but I imagine the >transitions on the logic are just fine. I don't recall the fets getting warm >when using a small load(led's) so it seems to be load dependent which would >point to a different problem. >

You can't troubleshoot this thing blindly - You'll need to scope input signals, corresponding gate drive and actual Vgs waveforms for integrity. This should be possible, firstly, without fets attached (HS grounded), effectively reducing scrap at the early stages of troubleshooting.

Gate waveforms can be modified, after the fact, to slow down turn-on, while maintaining turn-off speed, if logic can't be trusted to provide appropriate dead-time intervals.

Shoot-through issue investigation will benefit from fet current waveforms, after logic and drive integrity is established and fets are actualy in place.

60KHz switching of the large gate charge mentioned in previous postings can be expected to produce losses in the driver. It doesn't take many 100's of milliwatts to raise driver IC body temperatures. These driver losses can be intentionally distributed into the series limiters present in typical gate drive turn-on delay networks, reducing actual driver loss by nearly a factor of two.

If you can do 60KHz, why can't you do 1KHz or 10KHz, as an intermediate step? This might be easier to troubleshoot, with reduced high-frequency effects. It was only 100Hz or static-DC control that was considered unsuitable in your application.

In totem-pole high-frequency power circuits with signifigant freewheeling current, the internal fet body diode can be very slow to recover and contribute considerable stored charge to shoot-through currents, regardless of dead-time precautions.


Reply to
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.