microprocessor controlled SMPS

[artem_bond]

Hello all.

I have a principal question about SMPS with microprocessor. SMPS
without microprocessor (UC3842) is simply. But I'm thinking about
putting feedback to the CPU, more protections from stupids and other
things. But, using microprocessor could be dangerous because it's
could be hang-up by EMI or errors in firmware. I'm have a big
experience about ground layout, supervisors, wDod timers and other
things. By any way, some times it's was not enough especially inside
SMPS.
So. I need a something like ?smart? drivers. I thinking about
protection:
1.Current transformer. (very fast, but could not prevent transformer
saturation)
2.Hall-effect sensor after rectifiers, before snubbers. (Slow, but it
could protect IGBT even if they opens together)
It's ok. I seen drivers who have ?over current? input with trigger.
But I have no idea about how to connect push-pull driver to PWM, and
how to make protection from IGBT through current, (I will limit
death-time outside microprocessor with something like RC circuit).
Ideally protection by measuring frequency (20kHz +- 1kHz) would be
very good.

Any ideas, appnotes? I'll use Atmel AVR microprocessor. And I will not
use FPGA.

 

[Al Borowski]

Any ideas, appnotes? I'll use Atmel AVR microprocessor. And I will not
use FPGA.

I'm doing the exact same project - but with a microchip PIC.

I will have the following stages protection:

First, wire it so that if the output voltage is >105% of the deesired
output, then an internal compqritor will trip and trigger the hardware
PWM auto shutdown. That should protect against stupid firmware errors.

If that fails, have a second comparitor wired so that if the voltage
becomes higher then say 15% of the desired voltage, the comparitor
output will fire an SCR. This will short the output and blow a fuse
rather then start a fire.

Of course, the PIC will have a watchdog as well.

cheers,

Al

 

[Ian]

I've used a PIC to run a flyback SM converter, using a logic-level MOSFET driven directly
from the PWM output. Feedback is via potential divider straight to the comparator input.
Simple bang-bang software control loop to maintain approximately the required output voltage,
triggered off the PWM timer interrupt to sample the output voltage at an appropriate point in
each cycle (away from the flyback spike) and up/down the PWM duty accordingly.

For protection a beefy 200V zener across the HV output to protect the output cap (target
voltage 180V) and a thermal fuse on the MOSFET in case the PWM output gets stuck on
(experience indicates that the MOSFET gets hot quickest in this state

Works great. I did have worries about zapping the PIC I/O lines with inductive spikes from the
transformer, but so far it's clocked up several 10's of hours running without a problem.

<http://projects.jusme.com/cgi-bin/projects/projects/files.pl?tab:files&id:nixieclock1>

(P104V2R1-MCU.pdf is the controller schematic)

 

[Jan Panteltje]

Hello all.
could be hang-up by EMI or errors in firmware.
I'm have a big experience about ground layout, supervisors, Interesting.

Any ideas, appnotes? Yes

I'll use Atmel AVR microprocessor. And I will not use FPGA.

So be it.
JP

 

[Frithiof Andreas Jensen]

Any ideas, appnotes? I'll use Atmel AVR microprocessor. And I will not
use FPGA.

Many embedded CPU's have hardware support for various kinds of topologies
and modulation schemes. This often includes hardware support for fast
turnoff on some failure condition. One simple way to measure a drive failure
or a short-circuit is to measure the voltage across the power switch - it
should be below a threshold when the drive is on!

Plain overload can be done by the fuses or in software modelling the heating
of the load or the switches.

And -

Use an RTOS!!!

Provide a command-line interface too so one can see what goes on - and use a
parser tool like flex/bison f.ex. so that the grammar can be checked easily
instead of cooking up something yourself.

 

[Jan Panteltje]

I've used a PIC to run a flyback SM converter, using a logic-level MOSFET driven directly
from the PWM output. Feedback is via potential divider straight to the comparator input.
Simple bang-bang software control loop to maintain approximately the required output voltage,
triggered off the PWM timer interrupt to sample the output voltage at an appropriate point in
each cycle (away from the flyback spike) and up/down the PWM duty accordingly.

For protection a beefy 200V zener across the HV output to protect the output cap (target
voltage 180V) and a thermal fuse on the MOSFET in case the PWM output gets stuck on
(experience indicates that the MOSFET gets hot quickest in this state

Works great. I did have worries about zapping the PIC I/O lines with inductive spikes from the
transformer, but so far it's clocked up several 10's of hours running without a problem.

<http://projects.jusme.com/cgi-bin/projects/projects/files.pl?tab:files&id:nixieclock1>

(P104V2R1-MCU.pdf is the controller schematic)

Nice, what I am missing is a small resistor in the source of the power MOSFET
that is connected to the base of a NPN that then pulls down a pin on the micro
controller, to shut down the drive (each period) if Idrain exceeds some value.
This will give you overload protection etc..
JP

 

[Tim Wescott]

Many embedded CPU's have hardware support for various kinds of topologies
and modulation schemes. This often includes hardware support for fast
turnoff on some failure condition. One simple way to measure a drive failure
or a short-circuit is to measure the voltage across the power switch - it
should be below a threshold when the drive is on!

Plain overload can be done by the fuses or in software modelling the heating
of the load or the switches.

And -

Use an RTOS!!!

Provide a command-line interface too so one can see what goes on - and use a
parser tool like flex/bison f.ex. so that the grammar can be checked easily
instead of cooking up something yourself.

I must be argumentative, because I usually insist on using an RTOS, but
it's really not necessary if the programmer is experienced and the
software is small. In that case you can do better with a task loop.
It'll be harder to modify the code, but it'll be easier to get simple
things working, and easier to verify if you need high reliability.

 

[Joerg]

I must be argumentative, because I usually insist on using an RTOS,
but it's really not necessary if the programmer is experienced and the
software is small. In that case you can do better with a task loop.
It'll be harder to modify the code, but it'll be easier to get simple
things working, and easier to verify if you need high reliability.

Agree, Tim. Even an RTOS wouldn't be fast enough to handle this stuff
and I would do that in assembler. Definitely not with C or any operating
system.

On the failure side I would provide two cut-offs if there are too many
concerns about a firmware hang-up: One if the voltage exceeds a limit
and could potentially destroy lots of expensive stuff that is connected.
The second cut-off would be if for some reason the inductor current
exceeds a limit. The latter needs to be fast. The shutoff means could be
a flip-flop that inhibits switching of the FETs. This flip-flop could
also be asserted "off" upon power up. It would have to be set by a port
pin, indicating that the uC and firmware is "alive and well", assuring
that the switcher won't run unless everything is humming as expected.

One concern I have with a uC is the PWM timer clock. Save the MSP430
most others can't clock that at full master and even then that won't be
more than about 10-20MHz. If a low granularity in PWM ratios is desired
that won't allow high switcher frequencies. So sometimes it may be
better to let the PWM be handled by a chip such as the tiny LM3478. It's
only a Dollar and that cost will come back via smaller magnetics. The uC
could then control that chip if needed.

Regards, Joerg

 

[Ken Smith]

Hello all.

I have a principal question about SMPS with microprocessor. SMPS
without microprocessor (UC3842) is simply. But I'm thinking about
putting feedback to the CPU, more protections from stupids and other
things. But, using microprocessor could be dangerous because it's
could be hang-up by EMI or errors in firmware.

Hmmmmm.

That you seem think units will ship with "errors in the firmware" is
a bit scary. If you were doing it with Rs and Cs and op-amps, you
wouldn't ship it with errors in the component values. The firmware for a
switcher is going to be simple enough that you can prove it is correct.

As to the real problem:

If you want this supply to always come on and only want some of the tuning
to be done by the micro, I suggest you look at the nonvolatile digital
pots made by Dallas Semi and others. The micro can tune the values as
needed and should the micro fail, in a way other than going crazy, the
values will stay as set and no great harm will be done.

If the supply must have the micro controlling it at all times, you can add
a watchdog one-shot to the external electronics. If the micro doesn't
keep pulsing its input, the oneshot shuts the thing down. I suggest an
analog RC based oneshot and not something digital. With digital stuff
there is too much temptation to let the fox gaurd the chickens. You don't
want the watchdog to in anyway depend on the oscillator that clocks the
micro.

I suggest you pick your supply topology so that failure of the micro
doesn't allow the output voltage to go very high. This argues against
using a flyback design.

 

[Ken Smith]

I will have the following stages protection:
[...]
If that fails, have a second comparitor wired so that if the voltage
becomes higher then say 15% of the desired voltage, the comparitor
output will fire an SCR. This will short the output and blow a fuse
rather then start a fire.

I would use a ZNR overvoltage protection device to fire the SCR something
like this:


------------
! !
--- V
^ ---
! / !
!-------- !
! ! GND
/ ---
100R \ --- 0.1
/ !
! !
GND

The problem with using a comparitor is that you tend to either end up with
the SCR firing when you don't want it to or taking too long to fire.
Using a device that helps to clamp the supply, reduces the overshoot.

 

[Winfield Hill]

Ken Smith wrote...

Al Borowski wrote:
[...]

If that fails, have a second comparitor wired so that if the voltage
becomes higher then say 15% of the desired voltage, the comparitor
output will fire an SCR. This will short the output and blow a fuse
rather then start a fire.

I would use a ZNR overvoltage protection device to fire the SCR
something like this:
[ snip standard circuit ]

The problem with using a comparitor is that you tend to either end
up with the SCR firing when you don't want it to or taking too long
to fire.

There are fast ICs meant to trigger SCR crowbars. like the MC3423,
http://www.onsemi.com/site/products/summary/0,4450,MC3423,00.html
and an app note, http://www.onsemi.com/pub/Collateral/AN004E-D.PDF

Using a device that helps to clamp the supply, reduces the overshoot.

Yes, but that's not done with an scr! We have a nice fast adjustable
1.8V 15A clamp circuit we'll be presenting in our next edition. It
has an SCR crowbar if the clamp current + time is exceeded, and an
ac-line shutoff relay to bring the power-supply to a reasonable stop.

Thanks,
- Win

(email: use hill_at_rowland-dot-org for now)

 

[mike]

Hello all.

I have a principal question about SMPS with microprocessor. SMPS
without microprocessor (UC3842) is simply. But I'm thinking about
putting feedback to the CPU, more protections from stupids and other
things. But, using microprocessor could be dangerous because it's
could be hang-up by EMI or errors in firmware. I'm have a big
experience about ground layout, supervisors, wDod timers and other
things. By any way, some times it's was not enough especially inside
SMPS.
So. I need a something like ?smart? drivers. I thinking about
protection:
1.Current transformer. (very fast, but could not prevent transformer
saturation)
2.Hall-effect sensor after rectifiers, before snubbers. (Slow, but it
could protect IGBT even if they opens together)
It's ok. I seen drivers who have ?over current? input with trigger.
But I have no idea about how to connect push-pull driver to PWM, and
how to make protection from IGBT through current, (I will limit
death-time outside microprocessor with something like RC circuit).
Ideally protection by measuring frequency (20kHz +- 1kHz) would be
very good.

Any ideas, appnotes? I'll use Atmel AVR microprocessor. And I will not
use FPGA.

I've started down this road more than once. I always come back to a
standard swtiching power supply with a micro to control the inputs.
Micro looks simple, but by the time you add on all the failsafes, fixes,
workarounds, external sensors and limits, it gets more complex than
just using the PS chip in the first place.

We did build a charge diverter/shunt regulator for a solar power system
using just
a micro. But didn't care much about precise voltage, current, transient
response etc. Most of the hardware ended up in, you guessed it, the
failsafe stuff in case the micro locked up or failed.
YMMV, mike

--
Return address is VALID.
Bunch of stuff For Sale and Wanted at the link below.
Toshiba & Compaq LiIon Batteries, Test Equipment
Yaesu FTV901R Transverter, 30pS pulser
Tektronix Concept Books, spot welding head...
http://www.geocities.com/SiliconValley/Monitor/4710/

 

[artem_bond]

Use an RTOS!!!

I must be argumentative, because I usually insist on using an RTOS, but
it's really not necessary if the programmer is experienced and the
software is small. In that case you can do better with a task loop.
It'll be harder to modify the code, but it'll be easier to get simple
things working, and easier to verify if you need high reliability.

Yes. I was used ucos-II in one is my project. But I will make
protection circuit outside microprocessor. I'll use a full-bridge at
IGBT. And I will protect this IGBT in first. This is HV SMPS, so I
expect that EMI could be very high. By this anything could happening
with CPU. Of course I can use a fiber optic for galvanic isolation,
but I think that "smart" driver and transformer could be enough. This
driver must provide fast swith-off (and stay in this while CPU reset
this driver) and generate 2-polar signal from one-polar PWM. About
death-time protection I'm already explain.

 

[Joerg]

Hi Winfield,

Yes, but that's not done with an scr! We have a nice fast adjustable
1.8V 15A clamp circuit we'll be presenting in our next edition. It
has an SCR crowbar if the clamp current + time is exceeded, and an
ac-line shutoff relay to bring the power-supply to a reasonable stop.

Well, by now you have everyone drooling. So when does the next edition come out?

Regards, Joerg

 

[artem_bond]

Hmmmmm.

That you seem think units will ship with "errors in the firmware" is
a bit scary. If you were doing it with Rs and Cs and op-amps, you
wouldn't ship it with errors in the component values. The firmware for a
switcher is going to be simple enough that you can prove it is correct.

Yes. But it's not only "simply" SMPS in this SMPS expected RS485 bus,
a lots displays, temperature controls in few points and others. If
course, I can use external interrupt for protection. It's fast and
simply. But, imagine 10kV discharge, 0.1mf capacitor near by CPU. It's
provide huge EMI and this EMI can come (en example) to crystal
resonator (most sensitive thing in CPU). CPU can do everything even
put 0xff value to PWM generator and hang-up after this. It's produce
through current and IGBT burn-out. By this I will make all protection
outside CPU.

As to the real problem:

If you want this supply to always come on and only want some of the tuning
to be done by the micro, I suggest you look at the nonvolatile digital
pots made by Dallas Semi and others. The micro can tune the values as
needed and should the micro fail, in a way other than going crazy, the
values will stay as set and no great harm will be done.

Yes, I thinking about it's. I'm working whith AD7376. It's worked
very well. But I thing that if a lots of invertors(?) (for regulate
frequency of rotation asynchronous motor) working well, making
reliable SMPS by this way is good idea. I just can't find any
appnotes. All only for three phase, and nothing for what I want.

I suggest you pick your supply topology so that failure of the micro
doesn't allow the output voltage to go very high. This argues against
using a flyback design.

My main problem is protect SMPS. I did't worry about load. But load
can do everything. It's a one of benefit of using CPU: I can react on
short-currents much better.

 

[Ken Smith]

Ken Smith wrote...

I would use a ZNR overvoltage protection device to fire the SCR
something like this:
[ snip standard circuit ]

The problem with using a comparitor is that you tend to either end
up with the SCR firing when you don't want it to or taking too long
to fire.

There are fast ICs meant to trigger SCR crowbars. like the MC3423,
http://www.onsemi.com/site/products/summary/0,4450,MC3423,00.html
and an app note, http://www.onsemi.com/pub/Collateral/AN004E-D.PDF

Unless I missed something in the datasheet, the MC3423 doesn't, its self,
clamp the supply voltage like the ZNR over-voltage device does.

0.5uS is plenty fast, but its source current looks a little low to fire a
largish SCR.

Yes, but that's not done with an scr!

I think I wasn't clear. The ZNR device I was speaking of is a type of
overvoltage clamp. It clamps the supply and thus reduces the overshoot
while we wait for the SCR to get its act together and start conducting.

 

[Ken Smith]

If
course, I can use external interrupt for protection.

Also take a look at what the micro's Reset pin does to the PWM. Does it
kill it? If so, that may be even faster.

[...]

My main problem is protect SMPS. I did't worry about load. But load
can do everything. It's a one of benefit of using CPU: I can react on
short-currents much better.

Does this "everything" include sourcing power back into the SMPS? If so,
the problem is much more complex.

"Current mode" controllers provide cycle by cycle current limit protection
for the SMPS. They require a bit of extra work to design the control loop
for however. Instead of directly doing the PWM in the CPU, you could make
the CPU set the current level and trigger the flip-flop on each cycle.
Basically this means that the external current limit circuit it also
controlling the operation in normal times.

 

[artem_bond]

Also take a look at what the micro's Reset pin does to the PWM. Does it
kill it? If so, that may be even faster.

Great idea. About kill I'm not shure, but swithing output to Z mode
i'm shure. Thanks. But I think about driver like this
http://www.irf.com/product-info/datasheets/data/ir2161.pdf whith
flip-flop trigger inside for connetion this to PWM Atmega.

[...]

My main problem is protect SMPS. I did't worry about load. But load
can do everything. It's a one of benefit of using CPU: I can react on
short-currents much better.

Does this "everything" include sourcing power back into the SMPS? If so,
the problem is much more complex.

This too. But I think TVS diodes can solve this problem.

"Current mode" controllers provide cycle by cycle current limit protection
for the SMPS. They require a bit of extra work to design the control loop
for however. Instead of directly doing the PWM in the CPU, you could make
the CPU set the current level and trigger the flip-flop on each cycle.
Basically this means that the external current limit circuit it also
controlling the operation in normal times.

Yes. But transformer have too big parasitic capacitor. I try to run
UC3846 in current mode but it's work terrible. And I thinking about
power supply whith swithing to resonance mode under big load.

 

[artem_bond]

and an app note, http://www.onsemi.com/pub/Collateral/AN004E-D.PDF

The thyristors usually too slow. Maybe TVS diod plus this circuit.

 

[artem_bond]

It's ok. I seen drivers who have ?over current? input with trigger.

I've started down this road more than once. I always come back to a
standard swtiching power supply with a micro to control the inputs.
Micro looks simple, but by the time you add on all the failsafes, fixes,
workarounds, external sensors and limits, it gets more complex than
just using the PS chip in the first place.

We did build a charge diverter/shunt regulator for a solar power system
using just
a micro. But didn't care much about precise voltage, current, transient
response etc. Most of the hardware ended up in, you guessed it, the
failsafe stuff in case the micro locked up or failed.
YMMV, mike

Yes. But I could see a lots of three phase motor drivers and I see
that they working. I need only a 1/3 of this motor driver. And I no
need DSP. I think, that if made all protections circuit outside micro,
theirs no different between using PS chip. Becouse all changes is move
saw generator and comparator from PS chip to micro. Others is no
changes.