[Discussion] Ever had to design a power supply with an MCU as controller?

[BadeBhaiya]

Kinda curious if anyone here ever had to design any kind of power supply without using an IC that's intended for the purpose (aka no TPS**** or MC34063 or whatever) but a programmed MCU as the controller and external FETs or whatever to do the power switching etc.

What kind of requirements forced you to do that? Were there no ASICs available for the specific purpose? Did you match the requirements? Any gotchas? Did you have fun?

[petemate]

Yeah, its pretty normal practice in more advanced power supplies. The reason to do so is to employ digital control of the power supply, instead of the usual analog control scheme. By moving the control system into the digital domain, you are no longer affected by component tolerances, you can keep track of the performance and compensate as components age, you can do on-the-go updates, etc. Basically all the usual reasons to move from hardware to software. There is obviously no point in doing this for a simple 5V 1A supply in your coffee machine, but for more advanced systems this can be very beneficial.

Check out the C2000 series from texas instruments. Its a series of microcontrollers optimized for real-time control tasks, e.g. motors and power supplies. Compared to normal MCUs, they have more advanced peripherals, e.g. high-resolution timers, PWM modules, capture-compare modules, etc.

Biricha has done some great tutorials about digital control of switchmode supplies on an STM32 MCU:

[barshatriplee]

My ex-colleagues made one with ATmega8 chip long ago. I was not in their team though. Here is a similar one with ATTiny2313: http://www.hoevendesign.com/#HomelabPowerSupply

[dobsonr741]

Biricha is highly recommended, enjoyed every minute of the video.

Does anyone now how's HRPWM is implemented in silicon?

STM32 calls for a 4.6GHz HRTIM clock - is this clock really present inside and a counting down at this rate to compare?

[T3sl4co1l]

I did a specialized (resonant: induction heating) control on MCU a couple years ago.  Still a bit sketchy in places, but seems to run alright.  The innermost loop was relatively noisy, I think a combination of poor ADC ranging, time quantization noise (as the sampling points shift phase by whole clock cycles -- variable frequency control scheme, so all the timing is referenced to a master "VCO"), and relatively low Q load (so, while it's relatively insensitive to small changes in frequency, it also responds quickly to them).  The overall (averaged over enough cycles) behavior was fine though; good power calibration in particular.

I don't have a problem doing a more conventional, say peak or average current mode control, either; I haven't, but just because I have no reason to do it.  Doing something like, oh, PFC maybe, would be more challenging I think.  Maybe comparable to the resonant control in scope (which isn't so difficult by itself, but the particular hardware I was using, and other software features implemented, made for a pretty solid amount of project).

Mind, I'm speaking from years of experience.  It's been many more years in which I've contemplated doing such a control, and either solved it better in analog anyway, or "chickened out" because software is such an unreliable way to construct a control system.  And that's not to say I'm a poor coder -- quite on the contrary, my knowledge of software in general, and of my own abilities, is precisely why I approach such projects with the utmost care, and generally prefer to avoid them.  When it only takes one slipped clock cycle to blow up your transistors, you don't take risks.

So, I absolutely do not recommend beginners take on such a problem.  Not as a requirement for a project.  If you do -- do so from a purely academic angle.  Understand what switching is actually doing (namely: controlling inductor current).  Understand how to design and tune a control loop.  Understand when and how to protect against fault conditions.  What fault conditions should you expect?  (Input and output over/under voltage, overcurrent, startup transients; component failures and other FMEA if you like; etc.)  How to solve them?  Implement a control in hardware first -- analog and digital circuitry, no MCU involved.  Read SMPS controller/regulator datasheets, understand their block diagrams; construct them yourself from discrete components (amps, comparators, logic, etc.).

The easiest option -- and still a classic -- is to keep the busy work in hardware, and e.g. run the setpoints from DAC channels from an MCU.  (By "classic", I mean they had no choice but to do it this way since CPUs and MCUs were introduced in the 70s or so, at pitiful speeds (imagine, 1 MIPS was "fast"!).  It remains an excellent architecture for safety purposes, however!)  That way, even if the CPU locks up, the worst that can happen is the setpoints freeze in place.  A watchdog (external, in hardware!) can detect this and disable the circuit without ever exceeding nominal conditions.

Read the MCU datasheet in detail, and make use of hardware features; SMPS-centric timers and configurable logic are widely available nowadays, greatly reducing the amount of work the CPU has to do.  Understand your toolchain in great detail; if you aren't inspecting the ASM output, you're probably not at a deep enough level of understanding that you will do a better job than "programming in solder".  (Which is, after all, a kind of "assembly" language. )  Needless to say, anything Arduino dependent is purely academic -- you might be able to demo a basic control loop using those libraries; but a complete, reliable, high performance system?  No way.

Tim

[dietert1]

One reason to use a MCU is avoid reverse engineering the circuit, or at least make it a bit more difficult.
Another reason is to create a product family where all products share the same hardware, yet with different firmware or a different set of parameters.
Look at those scope families with bandwidths of 70, 100 and 200 MHz. Hacking those is a favorite theme in this forum.

Regards, Dieter

[coromonadalix]

The difficult part in a mcu design is the feedback loop and the speed it can do it  ...   current or voltage wise   ....  cc cv modes etc ...

you can play with ADC  or DAC resolutions now at low costs and good or very efficiency 

[Siwastaja]

Many many times. Some microcontrollers are better suited to do that, i.e., power conversion oriented peripherals, than others. But almost every microcontroller, even a cheap AVR, come with ADC, PWM generators, and analog comparator which can generate interrupts with low enough interrupt latency to do pulse by pulse current limiting for modest f_sw.

STM32F334 I have used for a bidirectional synchronous buck battery cycler, recommended. The HRTIM peripheral is surprisingly easy to use IMHO. Internal DACs can be routed to feed reference levels to internal analog comparators, and have high enough BW you can do all sort of interesting stuff like waveform generation by adjusting analog current limit setpoint.

[dobsonr741]

Answering my own Q:

STM32 calls for a 4.6GHz HRTIM clock - is this clock really present inside and a counting down at this rate to compare?

No. the 184ps PWM resolution in STM32G is done by PLL manipulation by a DLL - also called Delay Locked Loop.

[dmendesf]

Does anyone now how's HRPWM is implemented in silicon?

STM32 calls for a 4.6GHz HRTIM clock - is this clock really present inside and a counting down at this rate to compare?

Usually this is implemented with a a tapped delay line, sort of a reverse time to digital converter.

I've seen (but can't find now) a few ICs that implemented a power controller digitally with an all-hardware approach. They had an ADC + digital filter + PWM output and you could change filter coefficients by SPI. I think they were used in GPU power controllers.

[SiliconWizard]

Yes, a buck switching controller with a FPGA (MachXO2)  - main features were: programmable output voltage and current limit, low noise and the ability to log the drawn current from the switching events. Typical switching freq was 2 MHz.

I needed to be in full control of the switching, and "stream" the switching events to an outside chip, so there was definitely nothing off-the-shelf to do this.

Didn't do it with a MCU though - there just wasn't anything that would have fit the requirements satisfactorily for this, and if I had found one, it would likely have required a very specific range of MCUs with specific peripherals, something that I'm in general not fond of, especially combined with the fact that I'm not too fond on relying on software for controlling such low-level and critical things as power supplies.
The FPGA implementation is "portable" for the most part and can be reused on pretty much any FPGA (or ASIC if that came up). I did reuse it on a iCE40 later on. Just my approach though.

[dobsonr741]

The Ti UCD3020 is at the $2..$3 range now. It's a bit old compared to UCD3138 but punches a lot, what an FPGA would not beat in cost IMO. Added benefit it comes with firmware. We come long way since LM78S40.

https://e2e.ti.com/blogs_/b/powerhouse/posts/designing-a-digital-controlled-power-supply