ISL8117 buck converter blowing up

[MrBit]

Hi all.

I've got an issue I have been dealing with for some time time and still can't find the root cause.

My application uses a MCU DAC to control the buck converter +V_AMP output voltage (range covered is about 10V to 35V) in order to feed a dynamic load.

Load changes do not cause issues.
Enabling the output (at any given output voltage and load status) by using EN control input does not cause issues.
Disabling the output (at any given output voltage and load status) by using EN control input does not cause issues.
Raising the buck converter output voltage (while enabled) does not cause issues.
Lowering the buck converter output voltage 10V or more (while enabled) blows U9 and R25 up.

Applying a voltage ramp down in firmware to progressively lower the output voltage mitigates the problem, but a potential firmware malfunction still compromises the integrity of the hardware.
Also, this makes the circuit too slow, which represents an issue.

Simulations do not show anything.
After buck converter and resistor have been damaged, pins PHASE, BOOT, VCC5V and VIN show low resistance to ground.

Please see attached schematic for reference.
Any comments/ideas would be appreciated.

Thanks

 

[24vtingle]

Your fsw is 490kHz.
What is your power output?
You have paralleled the FETs with no resistance "isolating" the gates from each other.
Paralleling FETs in this way can cause serious problems...hence why you get dual buck controllers.

ISL8117

https://www.renesas.com/en/document/dst/isl8117-datasheet

BSC067N06

https://www.infineon.com/dgdl/Infineon-BSC067N06LS3-DS-v02_04-en.pdf?fileId=db3a30431ddc9372011ebb01e1b37fb6

Its a sync buck....try at first just using only the internal diodes of the low side fets and see how that works.....(ie, disconnect the low side gates from isl8117, and ground them). That is, stop it being a sync buck.

Also, try it with only one of the two top side fets fitted.

Your vout divider is 2k/62k, so without any external bias applied, you would get 18v6 output.
Ayk, with your 2k connection, being grounded, you would get vout = 37.2v
Ayk, with your 2k connection having 1.8V into it, your vout would then be 0.6V

I suspect when you very quickly reduce your vout, then the chip cant catch up and you end up with severe reverse currents in the low side sync fets and things blow up....so try it without the low side sync fets....ie just their diodes....or preferably just one of them.

 

[KlausST]

Hi,

my idea:
The output capacitors are charged ... in normal operation.
Then you lower the setpoint voltage
This causes the regulation to switch ON the LOW side MOSFETs.
The output capacitors get discharged this way. ... but the current rises .. uncontrolled high. (Ther
This overcurrent may kill the MOSFET

***
24vtingle already did your job ... and privided the necessary document links.
But you additionally should provide the PCB layout.

Klaus

added:
can we get a photo of the (damaged) IC?

 

[MrBit]

Hi Guys.
Thanks for the responses.

The reason why I have paralleled mosfets is that we just copied the design from ISL8117 EVAL module and adapted it to our needs.

https://www.renesas.com/en/document/mat/isl8117aeval1z-user-guide?r=1167136

When controller and resistor die (I've blown up a lot of them) the thing usually goes off and that's it. Sometimes you can see a bit of smoke coming out but nothing crazy. I wouldn't say there is any visual evidence of overheating (or any other visual sign of damage) in any of the two components after they pass away.

To get the thing back to work I just need to replace buck controller and resistor and it gets operational again. I haven't seen any of the mosfets damaged in the process.

The average power is about 15W.
+V_AMP rail feeds the center tap of a transformer with mosfets switching the primary windings to get a high amplitude square wave at the output of the transformer, which is low pass filtered to obtain a sinewave to drive the load.

As I mentioned earlier, the load does not seem to have any impact at all, as this thing blows up loaded and unloaded. The only condition to damage the hardware is lowering the output voltage enough within a short time period.

I am happy to show the PCB layout but it is a big 10 layer board densely populated, especially where the buck converter is placed.
If there is any specific aspect of the PCB layout that can be considered relevant to the issue, please let me know and I'll try to share the information in a way that can be digested.

I'll start experimenting with the mosfets as it has been suggested and will post any results obtained

 

[mtwieg]

Consider that if Vout is quickly reduced by sinking current into the buck output, Vin will rise (especially if the source for Vin cannot sink current). The amount of rise on Vin will depend on the change in Vout and the bulk capacitance on Vin and Vout. If the rise in Vin exceeds the ratings of the chip or some other component, that might cause damage.

However according to the ISL8117 datasheet it should be implementing diode emulation and pulse skipping, in which case I would not expect this to be an issue. Can you verify that this is the case (should be obvious if you probe the gates when operating at very light loads)?

 

[KlausST]

Hi,

why no photo, why no PCB layout?
You ask for help ... but completeley ignore what we need to helop you.

The reason why I have paralleled mosfets is that we just copied the design from ISL8117 EVAL module and adapted it to our needs.

Gives no information ... unless we know what your application´s "needs" are.

Sometimes you can see a bit of smoke coming out but nothing crazy. I wouldn't say there is any visual evidence of overheating

I always considered smoke as an evidenve of overheating..

The average power is about 15W.

What power?
Input power, dissipated power, output power, specified power ...

The only condition to damage the hardware is lowering the output voltage enough within a short time period.

This is your thinking .. but .. that needs to be proved.

As I understand the problem when
--> you change [AMP_PSU_VOLTAGE_ADJUST]signal to the positive.
Correct me if I´m wrong.

If I understand your text correctly, then "lowering the output voltage" on any other way does NOT cause the problem.
(changing load? DISABLE/ENABLE the IC, removing input power...)

but it is a big 10 layer board densely populated

For sure we ned to focus on the switching regulator part.
You already have been able to provide this section of the schematic... it is that much harder to do the same with the PCB?

10 Layer: I´ve designed 24+ layer boards .. so I´m not scared of 10 layers. On the other hand I would be very surprised if the "switching regulator section" really uses 10 layers.


Klaus

 

[mtwieg]

Oh, just saw this in the datasheet, sounds relevant:

5.3 Overvoltage Protection
The overvoltage set point is set at 121% of the nominal output voltage set by the feedback resistors. In the case of
an overvoltage event, the IC attempts to bring the output voltage back into regulation by keeping the upper
MOSFET turned off and the lower MOSFET turned on. If the overvoltage condition has been corrected and the
output voltage returns to 110% of the nominal output voltage, both upper and lower MOSFETs turn off until the
output voltage drops to the nominal voltage to start work in normal PWM switching.
For lower control loop bandwidth applications, such as very low output voltage or very low switching frequency
designs, the full load to no load transient response may be slow to cause an OVP false trigger. When OVP is
triggered, the long LGATE on-time creates a high negative inductor current leading to a higher than normal sink in
current to the ISEN pin. It is recommended to limit the ISEN pin sink in current to less than 16μA. Otherwise, a
false OCP hiccup operation may be triggered to cause the output to shut down.

When the setpoint decreases by a lot instantaneously, you are probably going to trip the OVP. And it sounds like this forces the lower gate on, ignoring diode emulation. If true that's a very bizarre way to implement OVP... worth looking into this. May want to probe the gate signals during a failure to see exactly what happens.

 

[KlausST]

Vout is quickly reduced by sinking current into the buck output, Vin will rise

good point.
I see about 760uF at the output ... but only 76uF at the input.

worst case:
If output is at 48V, input is at 48V and all the energy of the ouput capacitors is fed back to the input capacitors, then
.. the input voltage may rise to above 150V ... (losses ignored, additional circuitry ignored)

Klaus

--- Updated Jun 4, 2025 ---

When the setpoint decreases by a lot instantaneously, you are probably going to trip the OVP. And it sounds like this forces the lower gate on, ignoring diode emulation. If true that's a very bizarre way to implement OVP... worth looking into this. May want to probe the gate signals during a failure to see exactly what happens.

again well spotted!

The normal operaton is that the setpoint stays constant. And in this mode OV (or better say: overvoltage_condition) is rather unlikely.
On the other hand ... this would rather blow the MOSFET than the IC. OP states IC getd damaged, MOSFETs are OK.

The energy in the output capacitors is 0.5 x C x V x V --> worst case: 0.88J

Klaus

 

[mtwieg]

Perhaps a simple workaround would be to add a lowpass filter between the DAC and the resistor divider. That will keep the hardware happy while not requiring the firmware to do anything fancy.

One warning on that approach though: make sure you put an opamp buffer after the lowpass filter. Otherwise the closed loop transfer function of the DCDC controller will be affected in undesirable ways. Speaking from experience on this one.

A possible firmware-only workaround is to disable the whole DCDC controller before decreasing the Vout setpoint. Stay shut off until Vout drops naturally (at least until it's below the new setpoint), and then enable the DCDC again. That should avoid the OVP issue entirely. Though depending on your application, cycling Vout in this way might create other issues.

 

[std_match]

The datasheet in post #2 doesn't correspond to the schematic. The datasheet is for the ISL8117 and the device in the schematic is the ISL8117A which has a different datasheet, and a slightly changed pinout: https://www.renesas.com/en/document/dst/isl8117a-datasheet

 

[24vtingle]

well spotted, though i note the only difference is the "A" just has CLKOUT exchanged for COMP so external comp can be used...though that wouldnt be relevant here as OP is using "vout divider bias" method.
But good spot though as the "A" dsheet has some different schems in it which look like what OP does.

 

[dick_freebird]

Just a thought, but is the high side FET a "gate
protected" type?

If so then the protection diode will go forward if
the switch node goes above gate drive high level
and this could back-drive against the 8117 output
which may only be designed for peak AC current
and "normal" voltage swings. Could be brittle
under abnormal conditions. Does the driver
output break out past any of the abs max table
"constraints" just before the barbecue starts?

Perhaps characterize the maximum step down,
maximum dV/dt, look for the "cliff" you keep
stepping over in those dimensions and set the
controller (?) to respect that. Step to your
selected increments by way of finer, with "catch
up" (slew and settling) time dwell.

Might take a look at bulk capacitance / "flywheel"
stored energy. Is it the source or is it the trigger
for supply latchup (like driving driver output
above its HV well might get you)? Is it just excessive
and you could do as well with a tenth the C
and not burn anything trying slew faster than
"hull speed".

 

[Easy peasy]

this is a real classic - we have no data on the 48V source ! it appears when the Vout is lowered the 48V source goes high - either due to instability on the buck converter - or poor performance of the 48V source - or both - the high 48V kills the IC and hence R25 goes poof !

[ note, esp if the lower fet goes on for a time and then off - energy can flow into the Vin, or, conversely, or coincidentally, the power to the low Vout fluctuates ( i.e. goes high for a moment ) and then off - the 48V source must be going over 62.5V and poof ].

Check with a scope on the Vin set to capture for Vin > 58V say.

 

[24vtingle]

Yes indeed, and hopefully the OP has done tests with the buck not acting as a synch Buck now?
That should improve the situation, though even then some instability could potentially make the 48V go higher, depending on where this 48V is coming from? (eg is there an LC filter in the 48V, etc etc, which is ringing up when there is instability)

 

[MrBit]

Hi all.

Sorry for taking so long to respond. Last few days have been a bit hectic.

I started with was suggested about the mosfets and sync mode:

I removed one of the high side mosfest and one of the low side mosfets and then connected the remaining low side mosfet gate to ground.
The outcome of this did not make much sense to me. The maximum output voltage I was able to get from it was 4V, and the control by driving FB pin from the microcontroller was almost useless. The thing was nearly unresponsive. But at least it did not blow up.

Right after that I decided to reproduce the problem and blow a couple of boards so I could probe some signals in the process.
I'll put some screenshots of the probed signals, right below you can find a link to download the datasets (excel and PicoScope) so anyone interested can easily navigate the data:

Datasets
PicoScope software download


Below you can see a screenshot of the circuit performing a SMALL JUMP of the output voltage (2.5V ish), which won't damage the chip:

You can see point A corresponds to the moment the microcontroller drives for the chip to reduce the voltage, and point B corresponds to the moment where the target voltage is achieved.

Points A and B in more detail:

UGATE and PHASE signals are at the same voltage and overlap all the time, that's the reason why UGATE can't be appreciated in the pictures.


The next one shows the thing performing a MEDIUM JUMP of the output voltage (around 12V). This damages the chip and R25 with it:

A point, again, represents where the MCU drives the chip to reduce the output voltage.
More detailed pictures:

It seems the chip is indeed entering OVP mode and trying to lower PHASE voltage by turning the low side mosfet on.
It can be appreciated how PHASE and UGATE voltages start raising during that process (before reaching point B), not sure why this happens.
Once it reaches point B and starts dropping more pulses, they do not look great and mosfets dead time looks degraded.

Next one show the same thing, but on a second prototype and a BIG JUMP of the output voltage (30V). In this case, the voltage increase on PHASE and UGATE during the low side mosfet turn on due to OVP is significantly larger

Perhaps a simple workaround would be to add a lowpass filter between the DAC and the resistor divider. That will keep the hardware happy while not requiring the firmware to do anything fancy.

One warning on that approach though: make sure you put an opamp buffer after the lowpass filter. Otherwise the closed loop transfer function of the DCDC controller will be affected in undesirable ways. Speaking from experience on this one.

A possible firmware-only workaround is to disable the whole DCDC controller before decreasing the Vout setpoint. Stay shut off until Vout drops naturally (at least until it's below the new setpoint), and then enable the DCDC again. That should avoid the OVP issue entirely. Though depending on your application, cycling Vout in this way might create other issues.

In fact, I have a placeholder in the board with right what you described. A LPF (with a significantly large time constant) right after the signal that comes from the MCU followed by a buffer to decouple from the feedback loop. It works pretty good, taking the responsibility from the firmware. But still I managed to blow the buck converter by forcing an output voltage reduction while the output was being ramped up.

A snapshot of the 48V hardware rail:

--- Updated Jun 9, 2025 ---

Here we go

Q7 is controlled by a comparator circuit fed with the voltage drop on R69

+48V_IN comes directly from an enclosed 48V PSU:

https://www.digikey.co.uk/en/products/detail/mean-well-usa-inc/rps-200-48-c/7706043

 

[24vtingle]

I removed one of the high side mosfest and one of the low side mosfets and then connected the remaining low side mosfet gate to ground.

Did you also remember to disconnect the low side mosfet gate from the chip?

 

[MrBit]

Yes

 

[dick_freebird]

Since you have digital control of VOUT forget the LPF and just do from:to transition one LSB at a time, step time just a bit longer than end-end settling time.

 

[mtwieg]

Nice, got some waveforms to look at.

It doesn't look like Vin is rising enough to cause failure in the ISL8117... I was hoping to see some node spiking to at least 75V.

The next one shows the thing performing a MEDIUM JUMP of the output voltage (around 12V). This damages the chip and R25 with it:

View attachment 200040

A point, again, represents where the MCU drives the chip to reduce the output voltage.
More detailed pictures:

View attachment 200041

View attachment 200042

View attachment 200043

It seems the chip is indeed entering OVP mode and trying to lower PHASE voltage by turning the low side mosfet on.
It can be appreciated how PHASE and UGATE voltages start raising during that process (before reaching point B), not sure why this happens.

I'm guessing the rise in PHASE is because the synchronous FETs are starting to operate in saturation instead of their linear/triode mode. The ISL8117 only provides a 5V gate drive, but the BSC036NE7NS3GATMA1 seems to by more suitable for 10V drive. Its characteristic curves show it starting to saturate at around 30A with Vgs=5V. And it's likely that the actual current is going much higher than that once the OVP happens.

It's possible the FET saturation is killing the FETs, and then that is causing the ISL8117 to die as a result. But even if you used FETs more suited to 5V gate drive that probably wouldn't make things all right. The OVP behavior of this chip is really problematic, can't believe the chip designer thought this was a good idea....

In fact, I have a placeholder in the board with right what you described. A LPF (with a significantly large time constant) right after the signal that comes from the MCU followed by a buffer to decouple from the feedback loop. It works pretty good, taking the responsibility from the firmware. But still I managed to blow the buck converter by forcing an output voltage reduction while the output was being ramped up.

If the output is very lightly loaded, then you may have to make the filter very slow in order to avoid this problem. Or just disable the chip completely while reducing Vout to prevent the OVP issue from happening.

 

[Easy peasy]

I see the 48V makes it to 60V here:

the inductor, L3, on the input is doing you no favours here ( what size is it ? ) for a pulsed load.

you should sinusoidally vary Vout, via the f/b loop ( on top of DC out into say half load ) - increasing AC mag ( at say 1kHz ) until the thing blows up - while closely watching Vin to the chip. It is likely you will see the peak of the sine get to just over 60VDC then - bang. Due to the psu response and the LC input network.

There are only 2 causes of chip failure: - 1) Vin too high, 2) Fets blow up taking out the fet drivers and then the chip.

1) seems ( still ) the most likely.

--- Updated Jun 10, 2025 ---

Also 2 more things: - your mosfets are only 60V rated - bad idea, and, you need to set the OVP on the Meanwell psu to 56V say - this may help with your issues, as would 80V mosfets.