Post Go back to editing

LT8490 LT8705 catastrophic switch node ringing, FET gate ringing

Product Number: lt8490

Hello, I am actively working on this and will continue to post information.

I get some hardcore ringing that wiggles through my whole board on the rising edge of SW1 and falling edge of SW2. Sounds like typical switch node ringing right? Well.. But not always, sometimes it looks fabulous. And snubbers have had no effect on the ringing.

System:
I put the LT8490 in power supply mode which makes it simply an LT8705 for testing purposes.
M1 = supply FET, high side
M2 = Buck FET, low side
M3 = Boost FET, low side
M4 = Output FET, high side

Vout = 41.5V (floating 36V lead acid battery)
Vin = 32V power supply. current limited to 20 amps or less. *the system is designed for 30amps in and out, 44V battery charging.

I set the poweruspply so it is always in boost mode. The ripple mirrors on both m2 and m3, so if we solve m3 I can fix m2.


Discussion:
The beginning of this problem was the fact that during solar charging, and given certain transition conditions like a cloud went over the sun, the m2 buck low side FETs would suddenly heat up, and not always. The heat would surely lead to part destruction in seconds so I break power. Below is an image I would not show an employer. This explosion of signals happens with every pulse during its failure. *sometimes it snaps out of the failure...

Yellow = M1 FET gate V
Pink = M2 FET gate
Blue = M3 FET gate
green = M4 FET gate

========================================================

Here is my latest finding. If you want me to measure anything, let me know.
Yellow = SW2 V
purple = nothing
blue = M3 gate V
green = M4 gate V


Notice in the above several things.

  • unstable ringing. deep negative throw, high spike, and the waveform causes the FET to turn on and off a few times.
  • notice how the m4 gate voltage, green, is above the SW2 node, yellow, on the right? Thats good, as the gate is supposed to be 6V above it to trigger the high side m4 nMos gate. However notice before the ringing how the SW2 node and M4 Gate voltage match. This means the M4 gate was not on and the inductor was open circuit because the boost FET was also off.

This cycle repeats itself.

The below image is continuing the same cycle which looks like when the m4 gate voltage is proper. The m3 boost FET gate, blue, triggers after the M4 gate has turned off. The ringing you see there is quite acceptable to me. I wish it did this all the time C: wow this guy can do good layout.

Here is an overview of the boost cycling. The buck M2 FET gate is always off, however that ringing that we see also happens on m2 gate when m3 rings. They match magnitude, frequency, 99% match. Though the ringing is not biased on M2 because the gate is not active, the ringing on m2 is enough to make the m2 trigger a few times. Obviously this can lead to the melt down we saw earlier like a run away diesel.
In the image below, That slight ringing on the left is pretty rare, I was able to capture it here in one picture. Almost always it is spotless during m4 fall time when the m4 gate voltage was proper. You can see when there is the heavy ringing and lack of m4 gate voltage in the middle. I dont know what that is. I can't believe its the charge controller having an error. Why the heck is the gate on m4 not getting trigger voltage of SW2 + 6v? I don't know. Thoughts?




Just a measurement showing it rings and sometimes not. When it rings, it is because M4 gate voltage = SW2 (not shown here), instead of Sw2 + 6V.


.Further background. This charger does work, it did a nice 25amps, 40V solar input,  22A charging a 36V batt at 44.4V. *rough numbers don't check efficiency on that. Its usually 98% efficient surprisingly. The fets get toasty as expected, and require active cooling. But when conditions alter, like the solar power declines, or a load on the battery lowers battery voltage, something that causes the LT8490 to adapt to the new voltages, it has a chance of catastrophic failure as shown in the first picture of explosive signals. Clearly an instability.

If you want layout pictures I can show.

Strong ringing only occurs on the falling edge of SW2, and rising edge of SW1. However, not always does the falling edge of SW2 and rising edge of SW1 cause bad ringing, sometimes its super tight. Snubbers have had no effect whatsoever, I tried several article's equations too to size my snubber, and i played with snubber sizes experimentally. Nothing, nope.

I don't rly want to put gate resistors on there... its already a high current system I don't want more switching losses. Because the Switch node ringing is not consistent, I am hoping its not 'actually;' switch node ringing. Is somebody's fall time too long, are my Switch node diodes like.. not conducting ideally?




Parents
  • The case is closed on what the issue is: the below image from Vishay is 100% match to my problem. I measure signals like that. So now, how to I handle shoot through caused by high dV/dt from the switch nodes? I am studying it. I have a techincal question about layout coming up:



    ============

    Here is the buck Switch node called SW1



    This is viewing the bottom of the board. The top has the inductor placed and covering completely these two squares which are SW1 and SW2. Solar comes in on the left, and battery out to the right.
    My question is noise generation: these highlighted planes SW1 and SW2 are also on the top layer and they are thermally/electrically mated with vias. So theres a sandwich made: heres a sketch



    So the high dV/dt is charging two layers and relatively large surface areas. Is this a problem? Should I remove the bot layer, have the inductor on the bottom of the board and shrink the top copper to just enough to fit my heat sink on it for heat transfer purposes? I am thinking to put the inductor below where I will have no copper pour, and only a smaller pour on the top part of the board. etc etc arrangements, Or is this not relevant?

    I guess to condense it: will shrinking the switch node plane area reduce the dV/dt transmission?

  • The switch node has high dv/dt. The larger the copper area the larger the parasitic capacitance. This copper should not be any larger than necessary. The DC2069A demoboard and the DC2285A are good examples of how to do the layout.

  • also my mosefet resistors are 0 ohm place holders. The FETs are 3pF a piece at the gate with 2ohm resistance. Figured I didnt need to add anymore load.

  • I noticed something cute about the DC2596A. These are all dual fets like me; each gate is fed with a separate line with a gate resister near the IC, not near the FET? And the lines fork early near the IC, not near the mosfet.


    The demo board has all the FET gates super paralleling each other and super close. I can get maybe having the same gate traces parallel cuz they are matching signals but the gate resistor is near the IC and not the FET and it splits into two lines form the IC. Which method above is the better one? I am assuming the demo board it just feels counterintuitive. My gate resistors are right at the gates.  Or perhaps in this demo board it was permissible to have the gate resistors away, non essential

    Nonetheless without a gate resistor, should I fork out from the IC or fork just before the FETs?.

  • I have no issue  being a copy cat... while I'm taking for ever to catch up in understanding, do you recommend mirroring this board's concepts? Will hold nobody responsible for any continued bugs of course. I think I will do that while remembering the things you said too.

  • Check out this  fine nuance on that demo board.



    I  know its hard to see. So these are the two traces that measure the differential voltage from the inductor current sense resistor. Dark blue is the bot ground layer and cyan is some middle layer. Notice how the GND (right) trace is not connected to the bottom ground layer at the top where the resistor is while the bottom of that same trace does connect to bottom gnd layer. ?!

    On my board, I kept that trace isolated to prevent other signals from wiggling through it. Am I wrong in my philosophy? Would this help my signal returns?

    They basically went like this. The signal can return through the bigger ground plane or the trace. I am so curious.


    To copy paste their methods I would take my ground via that is 'not' touching my ground plane near the controller, connect to that plane. But then why does that trace exist, wouldnt it go up the bigger lower resistance path I made on the bottom layer? Which can pick up noise from other signal traffic?

  • i looked up common impedance coupling, then came across a phenomenon called ground bounce.



    Well, that awfully looks like me? I witness strong correlation of my my ringings with the SW1 rising and SW2 falling. I am curious if ground bounce is relevant and I'm not actually experiencing a direct cross talk issue. Because after looking at the demo boards, I feel (in my inexperience)... like those boards should have worse cross talk if cross talk was my issue. So I am exploring other possibilities.

    This little ground trace might be something to break up 'common' ground paths, offering varying impedance returns. I know signals follow path of least inductance first, not least resistance. That's how I designed my current paths that handle 30A, so they inductively cancel out by the power ground returning underneath the power into the system as much as possible. I have nearly zero inductive noise and nearly zero switch node overshoot.

    The crosstalk could be a beefy miller capacitive coupling effect on my FETs, common mode impedance noise, ground bounce...

    I am feeling that it might come down to insufficient return of some signal to my controller.

  • well.. i will do the experiments to see if its ground bounce but I don't think it is because ground bounce amplifies at higher loads. And my M2 shoot through is not related to load. It will do it at 1A out or 30A out. It is strictly when Vin is close to Vout where buck boost happens with all 4 FETs; which is when SW1 and SW2 are rising and falling synchronously, rather than 1 held high and the other switching. And my gate cross talk follows SW1 rise and SW2 fall exactly.

    Not having sufficient return, or having common mode impedance interests me... maybe I'll take a wire and add a ground path from somewhere smart to the controller and see if that influences anything. I have, what i think are, healthy returns but we'll see.

    I learned that discharge of the mosfet miller capacitance is from source to gate, which the gate has a long way back to the mosfet source terminal. That current has to travel through the controller IC, though ground, and over my Rsense into the source of the fets and back to the gate through the miller cap. This loop is quite large on my board and cannot be reduced just by nature of the bulkiness of things. A solution is a pnp BJT and diode seen below. When the controller is off the pnp activates and shorts the gate to the source. Or in other words, it is a local source to gate loop.


    This is used to allow quick turn off. I don't have turn off issues, however this would maybe help suck away my cross talk ripples. Any energy that hits the gate is prevented from charging up the gate capacitor unless the controller sends gate energy which then the pnp turns off and is deliberate.


  • A nice figure from texas instruments: I wondered what the return loop was for the high side fets, it goes through the SW traces to the IC and up the bootstrap caps.

  • Is the noise you are seeing real? Be sure you are using a scope probe with a very short spring type GND. Do not use any other scope GNDs. Even then you can pick up noise on the scope lead.

    Look at the layouts of the demoboards I referenced previously. These are examples of layouts that work well. Use these layouts to prioritize the importance of GND returns, GND guarding, etc.

    If you are seeing shoot-thru then either the switch node is getting disturbed causing unwanted information back to the IC or the gate traces are picking up unwanted noise. Again look at the demoboard layouts. These do not have that issue. The GND return for gate traces should be as close as possible to the gate trace. The GND plane should be next to these traces and GND guarding should be very close to these traces. Adding wires to try to troubleshoot these types of issues rarely work because even the wire insulation will cause the wire to be too far from the PCB. The loop AREA is what is important not the trace length.

  • Definitely the noise reading is difficult. But I think what you were mentioning here is conclusive:

    A lot of the surface chatter on the internet is about reducing trace length, but the more technical documents and yourself say loop 'area'. My loop areas are terrible as I was spacing the gate traces to avoid cross talk. But the demo board has these traces fairly close to each other in such a way as to minimize loop area and they do not have my issue.

    I will mirror the demo board. I appreciate your help and insight, and giving emphases for what I should focus on and reference.

    Thank you so much!

    I should be done with this thread now.

  • I am confirming that the problem is solved. I can do full 30A in and out with no stability issues during buck, boost, or buckBoost when Vin is close to Vout.

    What I did
    minimize the 'gate loop area'
    Made the planes under my inductor all switchnode.

    Despite the gate traces being significantly closer to each other, cross talk was reduced because the gate loop area has been reduced to as low as possible. Very interesting.

    Thank you for the help!

Reply
  • I am confirming that the problem is solved. I can do full 30A in and out with no stability issues during buck, boost, or buckBoost when Vin is close to Vout.

    What I did
    minimize the 'gate loop area'
    Made the planes under my inductor all switchnode.

    Despite the gate traces being significantly closer to each other, cross talk was reduced because the gate loop area has been reduced to as low as possible. Very interesting.

    Thank you for the help!

Children
No Data