We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin <jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
Joe Gwinn <joegwinn@comcast.net> wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
There are any number of ways to reject FPGA zombie behavior. The >retriggerable one-shot is pretty simple.
Another fairly simple one would be making the processor wait to receive a >specific message from the FPGA, e.g. Tranquility Base here. The Eagle has >landed.
Cheers
Phil Hobbs
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin ><jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power >>turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the >>module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
On Sun, 24 Mar 2024 20:58:22 -0000 (UTC), Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
Joe Gwinn <joegwinn@comcast.net> wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
There are any number of ways to reject FPGA zombie behavior. The
retriggerable one-shot is pretty simple.
Another fairly simple one would be making the processor wait to receive a
specific message from the FPGA, e.g. “Tranquility Base here. The Eagle has >> landed.”
Cheers
Phil Hobbs
The Efinix FPGAs are primitive, which is usually good, but their i/o's
can do tricky things.
I want a tiny SPI-interfaced chip that outputs a 1 when the proper
32-bit code is entered. Or 256.
On 25/03/2024 9:09 am, John Larkin wrote:
On Sun, 24 Mar 2024 20:58:22 -0000 (UTC), Phil HobbsYou could at least requre a few logic outputs from the FPGA to have
<pcdhSpamMeSenseless@electrooptical.net> wrote:
Joe Gwinn <joegwinn@comcast.net> wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power >>>>> turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the >>>>> module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
There are any number of ways to reject FPGA zombie behavior. The
retriggerable one-shot is pretty simple.
Another fairly simple one would be making the processor wait to receive a >>> specific message from the FPGA, e.g. Tranquility Base here. The Eagle has >>> landed.
Cheers
Phil Hobbs
The Efinix FPGAs are primitive, which is usually good, but their i/o's
can do tricky things.
I want a tiny SPI-interfaced chip that outputs a 1 when the proper
32-bit code is entered. Or 256.
different specific states (you could even have it drive relays with the
NO or NC contacts in series!), or feed the logic output from the FPGA
into a LC filter so that it has to toggle at a specific frequency to
turn on the MOSFET, or make the output of the FPGA drive a
Cockcroft-Walton multiplier that has to overcome the breakdown voltage
of a 5V zener to turn on the MOSFET so that you at least know it is
toggling. At the very least put a pulldown resistor so the mosfet's gate >can't float high!
On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
The retriggerable one-shot is 1 microsecond, and the FPGA (once it's
alive and well) will clock it at 2 MHz. No clock, no hard +48.
We'll have seconds available to charge the filter caps, before we make
the I'M_OK signal to enable stuff. It a Linux system!
On 24-03-2024 23:16, John Larkin wrote:
On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power
turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the
module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
The retriggerable one-shot is 1 microsecond, and the FPGA (once it's
alive and well) will clock it at 2 MHz. No clock, no hard +48.
We'll have seconds available to charge the filter caps, before we make
the I'M_OK signal to enable stuff. It a Linux system!
The FPGA will have a defined state during startup, and your gatedrivers
have UVLO, so during boot the FPGAs are defined as high-z, and you use a >pull-down resistor to pull the outputs low during boot. Normally you
would use a delay for the VDD for the gatedrivers, so both ramping VCC
and controlled VDD start makes sure there are no conflict.
I am currently working on a 3MW converter. We are controlling it
directly from a FPGA, like described above.
When I worked at Vestas doing 6MW wind turbine, we did it the same way.
Cheers
Klaus
On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard Kragelund <klauskvik@hotmail.com> wrote:
On 24-03-2024 23:16, John Larkin wrote:
On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and
big mosfet full-bridges driving transformers. The gate drivers get
their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power >>>>> turn-on, but the FPGA is configured some minutes later, after Linux
boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the >>>>> module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only
happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of
time from the FPGA before the one-shot will trigger?
Joe Gwinn
The retriggerable one-shot is 1 microsecond, and the FPGA (once it's
alive and well) will clock it at 2 MHz. No clock, no hard +48.
We'll have seconds available to charge the filter caps, before we make
the I'M_OK signal to enable stuff. It a Linux system!
The FPGA will have a defined state during startup, and your gatedrivers
have UVLO, so during boot the FPGAs are defined as high-z, and you use a
pull-down resistor to pull the outputs low during boot. Normally you
would use a delay for the VDD for the gatedrivers, so both ramping VCC
and controlled VDD start makes sure there are no conflict.
I am currently working on a 3MW converter. We are controlling it
directly from a FPGA, like described above.
When I worked at Vestas doing 6MW wind turbine, we did it the same way.
Cheers
Klaus
We have blown up fets and drivers on this product, which is
embarassing, so we're doing everything reasonable to stop that.
We have been using LTC4444 gate drivers, which are one possible
villain. We're switching to the UCC27712 next rev. But it sure sounds
prudent to apply +48 to the bridges last thing in the startup
sequence, as opposed to a kilowatt of +48 first thing at powerup...
before even the logic supplies are up. About 15 important things
happen between powerup an steady-state operation, and there could be
lots of gotchas lurking.
I've thought about really high-power electronics, like the ends of a
megavolt DC transmission line. That's scary. Failures must be
spectaular. And expensive.
I prefer products that won't break your foot if you drop one.
On 29-03-2024 15:33, John Larkin wrote:
On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard KragelundThis app note from Lattice describes the state of the pins during startup:
<klauskvik@hotmail.com> wrote:
On 24-03-2024 23:16, John Larkin wrote:
On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and >>>>>> big mosfet full-bridges driving transformers. The gate drivers get >>>>>> their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power >>>>>> turn-on, but the FPGA is configured some minutes later, after Linux >>>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile.
Possibly never.
After designing many complex fixes, a simple fix is to precharge the >>>>>> module's +48 rail gently, and slam it on hard after everything is
verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only >>>>>> happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of >>>>> time from the FPGA before the one-shot will trigger?
Joe Gwinn
The retriggerable one-shot is 1 microsecond, and the FPGA (once it's
alive and well) will clock it at 2 MHz. No clock, no hard +48.
We'll have seconds available to charge the filter caps, before we make >>>> the I'M_OK signal to enable stuff. It a Linux system!
The FPGA will have a defined state during startup, and your gatedrivers
have UVLO, so during boot the FPGAs are defined as high-z, and you use a >>> pull-down resistor to pull the outputs low during boot. Normally you
would use a delay for the VDD for the gatedrivers, so both ramping VCC
and controlled VDD start makes sure there are no conflict.
I am currently working on a 3MW converter. We are controlling it
directly from a FPGA, like described above.
When I worked at Vestas doing 6MW wind turbine, we did it the same way.
Cheers
Klaus
We have blown up fets and drivers on this product, which is
embarassing, so we're doing everything reasonable to stop that.
We have been using LTC4444 gate drivers, which are one possible
villain. We're switching to the UCC27712 next rev. But it sure sounds
prudent to apply +48 to the bridges last thing in the startup
sequence, as opposed to a kilowatt of +48 first thing at powerup...
before even the logic supplies are up. About 15 important things
happen between powerup an steady-state operation, and there could be
lots of gotchas lurking.
I've thought about really high-power electronics, like the ends of a
megavolt DC transmission line. That's scary. Failures must be
spectaular. And expensive.
I prefer products that won't break your foot if you drop one.
https://www.latticesemi.com/~/media/8DFD1009E98E42C9B53C4BADE6D8B3E5.ashx
It exits UVLO at 2.5V, so you just need to have the UVLO of the
gatedriver to be higher than that.
But, yes, your idea to apply the 48V last is a good idea. In a turbine
that is really not an option.
The scary stuff about 1000V/2000A is that an error occurs, busbar can
spray molten copper in all directions, and your literally toast. Safety
is really important on high power stuff.
UCC27712 is a good choice, the Texas/Unitrode guys knows how to make
good gatedrivers :-)
On Fri, 29 Mar 2024 21:31:21 +0100, Klaus Vestergaard Kragelund <klauskvik@hotmail.com> wrote:That sounds really worrying.
On 29-03-2024 15:33, John Larkin wrote:
On Fri, 29 Mar 2024 11:54:02 +0100, Klaus Vestergaard KragelundThis app note from Lattice describes the state of the pins during startup: >>
<klauskvik@hotmail.com> wrote:
On 24-03-2024 23:16, John Larkin wrote:
On Sun, 24 Mar 2024 16:10:25 -0400, Joe Gwinn <joegwinn@comcast.net> >>>>> wrote:
On Sun, 24 Mar 2024 12:14:57 -0700, John Larkin
<jjlarkin@highlandtechnology.com> wrote:
We have a board that tends to blow up.
It has a couple of isolated dc/dc converters, gate driver chips and >>>>>>> big mosfet full-bridges driving transformers. The gate drivers get >>>>>>> their inputs from an FPGA.
The probelm is that the +48 volts to the h-bridges comes up at power >>>>>>> turn-on, but the FPGA is configured some minutes later, after Linux >>>>>>> boots up. And I don't entirely trust the FPGA outputs meanwhile. >>>>>>> Possibly never.
After designing many complex fixes, a simple fix is to precharge the >>>>>>> module's +48 rail gently, and slam it on hard after everything is >>>>>>> verified stable.
<https://www.dropbox.com/scl/fi/i7mgvnad9h1itxf8p0t76/P941_942_Precharge_1.jpg?rlkey=tv3rh3kzlw40th20oes6hlhr2&raw=1>
The one-shot gets its I'M OK trigger from the FPGA, which can only >>>>>>> happen if the FPGA is working, I hope.
Can you require significant net charge transfer on a short period of >>>>>> time from the FPGA before the one-shot will trigger?
Joe Gwinn
The retriggerable one-shot is 1 microsecond, and the FPGA (once it's >>>>> alive and well) will clock it at 2 MHz. No clock, no hard +48.
We'll have seconds available to charge the filter caps, before we make >>>>> the I'M_OK signal to enable stuff. It a Linux system!
The FPGA will have a defined state during startup, and your gatedrivers >>>> have UVLO, so during boot the FPGAs are defined as high-z, and you use a >>>> pull-down resistor to pull the outputs low during boot. Normally you
would use a delay for the VDD for the gatedrivers, so both ramping VCC >>>> and controlled VDD start makes sure there are no conflict.
I am currently working on a 3MW converter. We are controlling it
directly from a FPGA, like described above.
When I worked at Vestas doing 6MW wind turbine, we did it the same way. >>>>
Cheers
Klaus
We have blown up fets and drivers on this product, which is
embarassing, so we're doing everything reasonable to stop that.
We have been using LTC4444 gate drivers, which are one possible
villain. We're switching to the UCC27712 next rev. But it sure sounds
prudent to apply +48 to the bridges last thing in the startup
sequence, as opposed to a kilowatt of +48 first thing at powerup...
before even the logic supplies are up. About 15 important things
happen between powerup an steady-state operation, and there could be
lots of gotchas lurking.
I've thought about really high-power electronics, like the ends of a
megavolt DC transmission line. That's scary. Failures must be
spectaular. And expensive.
I prefer products that won't break your foot if you drop one.
https://www.latticesemi.com/~/media/8DFD1009E98E42C9B53C4BADE6D8B3E5.ashx
It exits UVLO at 2.5V, so you just need to have the UVLO of the
gatedriver to be higher than that.
But, yes, your idea to apply the 48V last is a good idea. In a turbine
that is really not an option.
The scary stuff about 1000V/2000A is that an error occurs, busbar can
spray molten copper in all directions, and your literally toast. Safety
is really important on high power stuff.
UCC27712 is a good choice, the Texas/Unitrode guys knows how to make
good gatedrivers :-)
My FPGA folks say that we can't entirely trust the Efinix chip states.
With +48 up first, the FPGA is driving the fets before and during
config. Yikes.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 86:05:02 |
| Calls: | 6,717 |
| Calls today: | 1 |
| Files: | 12,248 |
| Messages: | 5,358,388 |
| Posted today: | 1 |
