I agree with T3sl4co1l; at 28V, I suggest you just use the MOSFET. Do a proper workup to balance the conduction and switching losses; don't just jam in a huge MOSFET with low RdsON. For a reasonable size NMOS the Qrr will be quite low anyway. Also the leakage inductance will block the transfer of current from the MOSFET channel (during synchronous rectification) to the Schottky.
Incidentally, you can get devices to solve that -- "FETky" or the like, integrated schottky body diode. Still more Coss+Cjo than a FET alone, so do check if the switching loss balance is okay.
That's playing hardball. An alternative approach would be to leave some small dead time in there (like 50ns or less), increase the HS gate resistor a tiny bit if current spikes are too high, and reduce the loop inductance. Don't mix these ideas ![Broken! :-BROKE](https://www.eevblog.com/forum/Smileys/default/smiliey_scope_broke.gif.pagespeed.ce.z9RuKVWKjY.gif)
Nothing wrong with shoot-through -- two transistors on, doesn't mean massive loss. It just goes from current ramping in the output inductor, to current ramping in the switching loop. Increasing that inductance, reduces switching loss due to shoot-through.
As you adjust gate resistors (bottom turn-off and top turn-on rates -- adjust rising/falling independently using an R || D + R network), you will find there is a minima, where recovery is eliminated but before shoot-through takes over.
It's a fine line: the timing precision is on par with the switching time constant t_sw = pi*sqrt(Lstray * Coss) / 2. For 10nH and 1nF that's a mere 5ns. So an error of 10 or 20ns will be out of whack, to one side or the other.
Increasing loop inductance does increase switching loss (just as increasing Coss increases loss, for the same reason, but depending on peak switch current instead of peak switch voltage), so you must find a suitable compromise, as well as a precise enough controller, to operate in this manner.
Which segues into the next point on that subject:
Yes, there are plenty of warning signs. I think the kickers for me were 1) quite high resistance in gate driver outputs 2) 80ns dead time (bloody ages @ 2.4MHz!) and 3) no slope compensation. They even have the gall to show some BS chart with stable and unstable regions like it's a magical property of the chip!!! ![Rant :rant:](https://www.eevblog.com/forum/Smileys/default/rant.gif.pagespeed.ce.koOB_HE-VX.gif)
The dead time is very sloppy, what was it, min 50, max 100ns? It's not clear what that depends on. Probably manufacture and temperature, maybe supply voltage as well. Broad side of a barn, as far as switching goes, especially at MHz.
The most creepy things I saw were:
1. Voltage mode controller? In 2018? You've got to be fucking kidding me. (Which means slope compensation is N/A -- it's wholly worse than that!
![Scared :scared:](https://www.eevblog.com/forum/Smileys/default/scared.gif.pagespeed.ce.oZptHNcbsD.gif)
) Also, voltage mode means dependency on output cap ESR.
2. What the
hell is this nonsense about bootstrap ripple? Sampling times? Even stuff about DACs?? Is this thing a fucking microcontroller inside?! What the hell do they need ten thousand transistors for? It's a switching controller; it's not even a current mode switching controller!
The whole thing smacks of a graduate in digital logic, doing a pet project, with an amateurish understanding of control theory, and solving everything with discrete time, sampled, clocked, state machine methods, when all of that could be simplified to a couple hundred transistors (which I think is about what TI uses in their Eco-Boost line, which itself is slightly quirky in this regard -- example, the pulse skipping mode is literally skipping pulses, not just slowing down the repeat frequency gracefully).
The underlying problem -- the "so what, what's wrong with that?" answer -- is that there's way too much hidden internal state for such a simple problem. The quirks seen in the datasheet only begin to scratch the surface of possible fatal errors this thing could encounter, particularly under arbitrary conditions (EMI and transients, noisy inputs and outputs?).
In fact, I would suggest the use of an integrated synchronous buck if you're not super sensitive to BOM cost. They deliver great performance cause the hard stuff is done in tiny silicon.
Not to say things are bliss there, either -- they still have the identical recovery problem, except you don't have the ability to snub it because the logic is drawing VCC from the high side +V pin.
![Face Palm :palm:](https://www.eevblog.com/forum/Smileys/default/xfacepalm.gif.pagespeed.ic.EBDwh1hCfo.png)
One reported case was LM3102 generating drift-step-recovery transients (risetime < 1ns), corrupting all ADCs on a DAQ board.
I usually stick with TI, TPS54xxx something or other seems to pop up most often. I forget if any run quite that fast, but there should be options. ON Semi seems to have a lot of cut-price parts, with quirks (though usually not as quirky as this one). Don't overlook Rohm/Renesas, Diodes Inc (similar to ON Semi, they have a lot of cheap clones, I think?), and many Taiwanese and Chinese companies that are getting more and more US market penetration and have chips that work surprisingly well.
(If you were wondering, no, unfortunately I don't have any recommendations for a replacement in this application.)
Tim