• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 65 subscribers
  • Views 3800 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Destructive glitch on LM5113

Mike Twieg
Intellectual 960 points
Other Parts Discussed in Thread: LM5113, LMG5200

Hi all, I've observed this issue for a couple years now and hoped it would resolve itself, but it hasn't so I'm finally starting a discussion.

I've set up a synchronous buck converter using the LM5113 and a couple eGaN FETs with dead time circuits similar to those in EPC's development boards. This works well, except under specific conditions. If I slowly sweep my pulse width from around 50ns down to zero, I get a glitch on the HI output which causes severe cross conduction, and usually destruction of the device, if that pulse width is applied repeatedly. I've taken a few scope traces to demonstrate this. In all of them, CH1 (yellow) is the HI input, CH2 (green) is the LI input, CH3 (purple) is the HOL output, and CH4 (pink) is the LOL output. For this test, the DC bus for the buck converter is shorted to GND, as is the switch node (the HS pin), so as to prevent damage during the test.

Here are my waveforms for a nice ~50ns input pulse. Outputs look good.

Here I my input pulse width is shortened to the point where the outputs barely keep up. Still no overlap to worry about.

Now I shorten the input pulse even more an the glitch shows up. The lower gate drive stays high the entire time, while the upper gate drive gives a very long pulse. This is where the damage happens.

Here's another look at a glitch waveform, zoomed in a bit more.

If I turn down the pulse width a little more, the glitch disappears entirely. Its duration always seems to be in the range of 30-150ns.

I've had this problem appear with both the WSON and DSBGA packages, and with different applied dead times, and I can always get it to manifest when I look for it. I can't find any alternative explanation than a silicon bug, but it would be great to have a fix for this. As it is, I have to implement a minimum pulse with in my PWM controller in order to avoid disaster. Most PWM chips don't have such a feature (at least not down to 10ns), so this is a real challenge for me.

Regards,

-Mike

  • 0
    TI__Prodigy 645 points

    Hi Mike,

    I've been trying to reproduce this behavior on an evaluation board in the lab here. So far, I've been unable to replicate the problem. I've tried both with and without the FETs connected. Without the FETs, you can see the minimum pulse width better, so that I what I show below. The scope shot below shows the minimum pulse width on the output before the output pulse goes away completely. I get down to 3.3ns pulse width without any problems. The lower trace is the HI input and the upper trace is the HO output.

    Is the layout of the VCC-GND and HB-HS capacitor loops much higher inductance than necessary? Does the problem still occur if you hold the LI signal off and only run the HI signal? I would like to get to the bottom of this and figure out what is causing the problem.

    Regards,

    Nathan

  • 0 in reply to Nathan Schemm
    Intellectual 960 points

    Hi Nathan, thanks for the reply.

    I repeated the test with LI biased high and low, and still saw the glitch. LI doesn't seem to have an effect.

    I neglected to mention that when shortening the HI pulse, the HO pulse will actually disappear completely first. Then as the pulse width is lowered more, the glitch shows up. So you have to actually go below the useful input pulse width range to see it.

    The range of pulse widths for which it occurs seems to be very narrow. Here are three scope captures of HI (channel 1) and HO (channel 2). First I have a pulse width of 5.3ns, which causes the glitch. Then I decrease the PW to 4.8ns and it disappears. Then I increase it to 5.7ns and the glitch disappears again.

    The glitch might also be a function of the specific pulse shape (rise/fall times, amplitude, etc). It's possible that putting logic gate buffers between my RCD dead time generating circuitry and the LM5113, like in the LMG5200 documentation, may solve the issue. Here's a schematic of the circuit I've been testing:

    Regards,

    -Mike

  • 0 in reply to Mike Twieg
    TI__Prodigy 645 points
    Hi Mike,

    Thanks for the extra information. When I looked at pulse widths less than what usually goes through the part, I did find the problem on some parts. I've confirmed that this is indeed a bug in the silicon. We will continue to investigate and look for a solution.

    The 10 ns pulse width specified on the datasheet is the minimum which is recommended during operation. A very simple minimum pulse width enforcement circuit can be made by putting an RC filter on the input pin to limit the rise and fall slope of the input signal. This combined with the input hysteresis of the part creates a minimum pulse width which may work for your application.

    Once again, thanks for bringing this to our attention; we will look into it further.

    Regards,
    Nathan
  • 0 in reply to Nathan Schemm
    Intellectual 960 points
    Hi Nathan, thanks for the confirmation. I've verified that adding a RC filter in front of my schmitt trigger gates does seem to resolve the issue, though it also alters the dead times generated by the following stages, so those will need adjustment.

    Do you know if the LMG5200 will also exhibit this issue? I assume its gate driver is a LM5113 or something very similar.

    Thanks,
    -Mike
  • 0 in reply to Mike Twieg
    TI__Prodigy 645 points

    Hi Mike,

    Yes, the LMG5200 will also exhibit this issue as well. Now that we are aware of it, we will use this information to improve future devices, including future releases of the LMG5200 family.

    Thanks,

    Nathan

  • 0 in reply to Nathan Schemm
    Intellectual 960 points
    Thanks Nathan, it's encouraging to see engineers readily acknowledging product flaws and give real solutions, that's quite rare nowadays. I hope to see a new eGaN driver soon!

    -Mike
  • 0 in reply to Mike Twieg
    Intellectual 700 points
    Based on this thread is my understanding correct that as long as my pulse widths are greater then 10nS I will not exhibit this problem?
  • 0 in reply to Lenny
    TI__Prodigy 645 points

    Yes, this is correct. This only occurs at pulse widths less than about 2ns or so.