Micros for digital SMPS control - TI, NXP (Freescale) opinions

[vectorotter]

Hi there,

I'm designing a power supply from scratch as a learning exercise.  It'll be line connected, transformer isolated and with some form of active power factor correction to 48V DC CC CV @ ~ 100W or so.  The exact topology and control scheme isn't fixed down yet - still reading, running simulations and understanding what's possible.  The load should be roughly constant over time except under failure conditions.  The control is going to be all digital.

I see TI have the C2000 series micros and from another post I found on the forum Freescale have micros designed with exactly this application in mind.

From what I can tell the toolchains are bundled in Code Composer Studio in the case of TI and the Code Warrior for the Freescale parts.  Re: the TI part, I dislike eclipse :-) although if I need to drive the compile from outside there I'm sure that can be made to work.  Any comments/comparisons?

More importantly I'm interested in anyone having experience with the 'Solution Adapter' and if there is some NXP/Freescale equivalent for configuring, generating code and seeing examples of how the peripherals get wired up.  The compensation and then the simulation of overall response seems like it could be a help provided my eventual topology matches some existing application sufficiently well.

Anyone have any real-world experience of either or preferably both who can comment on the tools, the parts and so on?  Seems like some of the TI eval boards are not available at Digikey - not sure if that is typical.

Thanks for any help in advance.

Err... I think the magic smoke will make an appearance at some point on this one.   


 

[opampsmoker]

100W and offline, isolated.
For that a HiperPFS  PFC stage followed by a Innoswith flyback would be very good...no code needed, but i appreciate you want to practice.

For a code controlled SMPS to be worthwhile, it needs to have a spec that calls for code.
Eg i took apart a 3kW offline battery charger once.

It had two Parallel PFC stages followed by a half bridge LLC...all three were controlled by a single micro. The micro was worthwhile here because...
The micro changeover switched the PFC stages every 10ms, so that they shared the thermal load between them.
The micro also continually monitored and controlled/changed the vout of the PFC stages so that the "open loop" LLC stage had the right input voltage to optimally charge the battery.
The micro also changed the f(sw) of the LLC stage from 100khz to 200khz when in light load (at the end of charging), or when necessary, eg if battery voltage was very low at start of charging.
The micro also did adaptive dead time control of the LLC stage FET drive.
This was a great example of a micro being needed. A 100W offline isolated SMPS does not need code, but i am sure you know this.

[vectorotter]

Thanks for the input but it doesn't address any of the questions or provide opinion that I sought.

[uer166]

I've been using STM32G474 micro with some success for toy power electronics projects. All have direct current control using MCU peripherals (comparators, HRTIM, DACs, etc..), and a software outer control loop. The Cube thing makes it easy to set-up some of the peripherals, with hand-written C for actual control loops. The number of ADCs and analog resources makes it easy to automate a lot of the control/safety stuff.

There is a "solution" generator at https://www.biricha.com/st-wds.html, although haven't tried yet since it only does simple topologies.

[vectorotter]

Thanks.  I'm familiar with the STM32 offerings in general and all else being equal I would go for an STM32 part, being familiar with the toolchain, Cube thing and so on.

My suspicion, without having gone in to detail is that, as with all these 'Wizard' type utilities, once you start moving off the reservation then one ends up either having to spend a lot of time coercing the thing to fit what one wants or dropping it altogether and starting from scratch.

The TI parts boast a high-resolution PWM that can be tripped directly from the ADC without CPU intervention presumably for implementing the safety cut-out.  I guess I'm after confirmation or denial that I can get to the same/similar point without those special features, and yes, I guess having a 'toy' spec means getting away with it more easily.

Nice to know about the "solution" generator anyway. Thanks.

[uer166]

The TI parts boast a high-resolution PWM that can be tripped directly from the ADC without CPU intervention presumably for implementing the safety cut-out.

So does almost every STM32 ADC, it's called "analog watchdog". You wouldn't do this using the ADC though, it's easier to route it to a comparator+DAC for a true hardware safety cutout.

HRTIM runs at an euquivalent of 4.7GHz for ~200ps resolution for normal PWM mode.

I think it really doesn't matter what you chose, obviously all these chips are capable for all kinds of power control..

[Siwastaja]

I like STM32F334. HRTIM is quite easy to use, IMHO, it's a clean-cut design with all the flexibility in mind from day one so configuring it makes sense.

DAC can provide comparison reference for the internal comparator, which can then be routed to command the HRTIM.

Don't use any stupid "toolchain". None is needed. gcc-arm-none-eabi is available as a simple install. Write your own code, it's almost always just easier that way.

[sandalcandal]

Was busy doing my on research on nearly the same question and missed your thread :s

I'm looking at much higher power systems but I've posted my own research and thoughts so far there: https://www.eevblog.com/forum/projects/picking-a-dsp-mcu-experiences/

Discussion here reminds me I should probably take a look at NXP and also have a check over of the peripheral configuration tools.

[vectorotter]

I like STM32F334. HRTIM is quite easy to use, IMHO, it's a clean-cut design with all the flexibility in mind from day one so configuring it makes sense.

DAC can provide comparison reference for the internal comparator, which can then be routed to command the HRTIM.

Thanks.

Don't use any stupid "toolchain". None is needed. gcc-arm-none-eabi is available as a simple install. Write your own code, it's almost always just easier that way.

Hence why I did not like the idea of using either the TI or NXP part - I'm a gcc devotee.  I didn't want to load the question with bias at that point ;-)

[Siwastaja]

BTW, I'm fine with using ADC for safety shutdowns. Often you don't have the choice, analog comparator and DAC channels run out so the STM32-style ADC "analog watchdog"s come in handy. For example, if you watch for inductor current with analog comparator, you may want to use ADC "analog watchdog" to look at input under and overvoltage and output overvoltage.

When you do that, make sure to enable all possible error interrupts (like OVERRUN, which happens if DMA fails) in addition to the analog watchdog interrupts themselves; configure highest interrupt priority (0 in ARM), don't use the same priority for anything else. If available, configure clock safety system (switching to the internal RC oscillator and triggering an interrupt if the main oscillator stops). Never __disable_irq() but instead wrap access to BASEPRI (in ARM) with your own IRQ dis/en macros so you never disable the highest priority ISR, not even for a short time. Make the highest priority interrupt unrecoverable, just shut everything down and indicate error. This way, I don't think using ISRs and code is any less reliable than using the peripheral HW features. You just have quite a few things to remember so the risk of forgetting something is obviously bigger.

Remember to test each and every protection feature.

[nctnico]

@Siwastaja: I'd still be cautious with software only protection. I have come across (extreme) situations where the microcontroller stops completely (not even a watchdog reset) or executes random code. Therefore I always have hardware cycle-by-cycle current limiting in my software based SMPS designs as a backup.

[vectorotter]

Thanks for the detailed info.  I will mull all of that over. 

Remember to test each and every protection feature.

Yes, in a similar sense to test-driven development in the software world.  Create the protection feature (test case) individually and have it fail perhaps even before writing anything to do meaningful control.

[TimNJ]

I just noticed today that NXP has a new version of its LLC resonant controller: TEA2016T. It has a I2C interface which allows you to tap into a ton of internal parameters. Seems very interesting.

This is one of the first controllers, targeting mass market, that I've seen with this level of programmable functionality

I know this is not really the same as using a generic/blank MCU, but on the other hand, doing it from scratch just seems like a huge headache unless you are trying to do something particularly special.

I wonder if these I2C programmable controllers will become the norm soon.

[Siwastaja]

@Siwastaja: I'd still be cautious with software only protection. I have come across (extreme) situations where the microcontroller stops completely (not even a watchdog reset) or executes random code. Therefore I always have hardware cycle-by-cycle current limiting in my software based SMPS designs as a backup.

Many peripheral HW features are also in risk of stopping. Often they require clock signal, at very least, which can stop either due to a software fault (runaway program counter accesses clock tree configuration), or through oscillator failure.

Some do have asynchronous protection features, check it up. There is still the risk that software fails to initialize it properly, although it seems quite small to me.

For really critical cases, you may want to add an external, like analog, protection. For overvoltage, independent analog crowbar + properly specified fuse, for example.

Current limiting often isn't a problem; it's easily made safe with a properly sized fuse (which is inexpensive and simple). Sure enough, software fault then causes hardware damage blowing up the semiconductors and the fuse, but then again, this becomes just an availability/maintenance problem. The good thing with software is, it does not age (in this context), and variation between units is minimized. With ST, of course, they may suddenly completely change the MCU behavior without changing part number so all bets are off regarding what you receive from your distributor. A recent example being STM32H743/H750 changing the ADC sampling clock frequency by factor of two, which could have the potential to keep application running normally but affect rarely needed protection functions, so that some PCBs in the batch work and some are dangerous. The only thing we can do is hope this never happens again. Or run full test of all features on each PCB. Which is obviously what we should be doing on anything safety-critical.

Keeping the software simple (and state space small) is a good way to avoid surprises; then each feature can be thoroughly tested and verified.

[JohnG]

No Microchip users?

I don't do controllers, so I cannot expound on the merits or lack thereof, but my company uses the dsPIC versions targeted at SPMS and motor drivers. I know that they are also used on some vendors "brick" type power supplies, particularly the ones with really high power density.

Cheers,
John


 

[nctnico]

@Siwastaja: I'd still be cautious with software only protection. I have come across (extreme) situations where the microcontroller stops completely (not even a watchdog reset) or executes random code. Therefore I always have hardware cycle-by-cycle current limiting in my software based SMPS designs as a backup.

Many peripheral HW features are also in risk of stopping. Often they require clock signal, at very least, which can stop either due to a software fault (runaway program counter accesses clock tree configuration), or through oscillator failure.

No. For a PWM controller it is extremely simple to implement. Feed the PWM signal to the clock of a flip-flop (which has an asynchronous reset) and an AND gate which combines the PWM signal and output of the flip-flop. Connect the overcurrent to the reset pin of the flip-flop. The flip-flop will be reset in case the overcurrent hits for the remainder of the period.

Current limiting often isn't a problem; it's easily made safe with a properly sized fuse (which is inexpensive and simple). Sure enough, software fault then causes hardware damage blowing up the semiconductors and the fuse, but then again,

A fuse is to prevent a circuit from catching fire; not to protect a circuit. To me relying on a fuse to catch software errors is not acceptable.

[sandalcandal]

No Microchip users?

I don't do controllers, so I cannot expound on the merits or lack thereof, but my company uses the dsPIC versions targeted at SPMS and motor drivers. I know that they are also used on some vendors "brick" type power supplies, particularly the ones with really high power density.

Cheers,
John

gae_31 mentioned some experience working with dsPIC here: https://www.eevblog.com/forum/projects/1kw-resonant-converter-analysis-design-build-and-validation/msg3392780/#msg3392780

For full digital control of pwm buck I have used dspic33 of microchip, which eventually worked fine for the project. I did struggle a lot with getting familiar with  all the conversions etc , probably because of my hardware background.
For future designs however, I want to use the TI chips, such as TMS320F28004x. They are bit more expensive, but on the other hand they have Floating point unit.
With fixed point arithmetic, when designing the control loop, it is much easier and less time consuming to use FPU than fixed point due to the issues of Fixed point such as rounding errors and the ease of changing the coefficients with making mistakes.

Also from taking a look at stuff on paper myself, looks like dsPIC has potentially better cost effectiveness but development and design to get things working well is a bit more involved since you have to deal with lack of FPU.

[nctnico]

You don't need an FPU to use floating point by definition. You only need an FPU in case software floating point is too slow. On a 32 bit ARM core software floating point isn't very slow though; I use it a regulary for realtime control loops.

[Siwastaja]

Gee, just don't make software errors .

The fuse is there to prevent a software error causing a fire; just making the product fail instead, so worst case, the customer complains, forcing investigation into what went wrong.

The fuse is really the last line of defence.

I like to avoid excess parts whenever possible; adding more parts to a problem requires yet more work to verify nothing can go wrong.

Of course, in order for this to work you need quite a lot of trust in the software. Simplicity is the key here.

Often, I think it's better if the product fails completely forcing fixing the actual bug, than if it runs a "bit weird" because the software fails and some analog subsystem silently works against it keeping it kinda-running. Such alternate system receives little real-world on-field testing. This is why I have never added an external "is PWM running, if not, override it" watchdog out of logic gates; but I do like having independent analog overvoltage protection especially for battery chargers, and I do like properly sized fuses.

[Siwastaja]

IMHO you don't need floating point (hardware or software) for SMPS control, or motor control for that matter. Use fixed point. 32 bits tends to be enough range even for multiplications, most of the time, and if unsure, using 64-bit operands isn't too expensive.

The idea is that if you write code in auto-pilot mode without thinking, floating point is less risky because there is both range and precision available. But SMPS math tends to end up so simple you can easily add range checks and verify max/min values.

[Doctorandus_P]

If you like STM32, then have a look at "STSPIN".
Those are a line of uC specifically designed for 3-phase motors, and for that they have some very nice extra's:

* Built in SMPS for the uC power.
* Built in high side and low side Gate drivers for external fets.
* Built in opamps.

[vectorotter]

If you like STM32, then have a look at "STSPIN".
Those are a line of uC specifically designed for 3-phase motors, and for that they have some very nice extra's:

* Built in SMPS for the uC power.
* Built in high side and low side Gate drivers for external fets.
* Built in opamps.

I'll check them out.  Thanks.  I was just considering how to get some auxiliary power for the uC !

[Sniper1]

Do you have a public example? Or any good tutorials?
there arent any tutorials for this peripheral.
There is  HRTIM cookbook but man it is a HUGE document.
Or some guiltiness for a STM32 beginner?

[uer166]

there arent any tutorials for this peripheral.
There is  HRTIM cookbook but man it is a HUGE document.

The thing is HRTIM as a perhipheral itself is pretty simple. It has a lot of clear/set/whatever sources, but fundamentally it's just a timer with a large crossbar at the output where any events can set or reset an output and/or modify the timer counter value. Once you understand how it works the examples will make sense. That cookbook is not really about HRTIM, but rather a "look how you can use the peripheral to implement common SMPS topologies". I never had the need to look at that cookbook to implement various interleaved boost and inverter topologies with HRTIM.

I would recommend:

• Don't use high-resolution mode, it's pretty low value and a large source of confusion
• Try hooking up various external events (from comparators, GPIOs, other timers) to the output crossbar

[mtwieg]

Not sure how I missed this thread when it was first posted.

I have a lot of experience doing digital power control with C2000 parts, so I can speak a lot about those. They are definitely the most specialized and powerful for digital control applications, both in terms of their peripherals (PWMs, ADCs, DACs, analog comparators, and the ability to link them with hardware events) and in terms of processing power (good FPU, and the CLA is incredibly useful for offloading the CPU of realtime operations). The amount of configurability in the peripherals is enormous, to help facilitate various types of converter topologies and control schemes, including advanced ones like LLC and PSFB, with peak current mode control and slope compensation, all handled at the peripheral level, with very little CPU intervention required.

But the huge configurability of the C2000 parts also makes the learning curve somewhat steeper. For example, you can definitely configure things such that one of the analog comparators tripping will immediately disable the ePWM outputs and fire off an interrupt to the CPU. But the setup for this is far more tedious than one would expect, because there are so many different ways of linking these peripherals, and even if you're doing something simple you have to grapple with that extra feature set.

Of course they do have some framework for getting people up and running quickly, I think the stuff for digital SMPS is called DigitalPower SDK, and within that is PowerSUITE, which has tools for doing feedback compensation. I tried to make use of some of this for my own application, but IMO it's only really useful if you are working with one of TI's reference designs or demo boards which already has good code written for it. That way you start up with something that (should) just work, and you can use that to get a better understanding of how things work by making small changes.

If you're not starting with a reference design or demo board, then instead I would suggest exploring the peripheral set with their very basic example projects in C2000Ware, one for setting up the ePWMs, another for the ADC, another for the comparators, etc, and eventually build up to a working system.

Regarding Code Composer Studio, I think it's fine. But my expertise is mainly hardware, not firmware, so take that with a grain of salt. You definitely can take a makefile approach if you don't like the IDE. But you will have to make use of the C2000 compiler (which I'm told is heavily based on GCC). I stuck with version 12.3 of CCS since several years back to avoid having to re-validate the tool/compiler, so I can't speak to versions beyond that.

edit: oh a couple odd quirks of the C2000 devices: Do not plan on coding in C++. IIRC there is some support for C++03, but I think TI makes it very clear they recommend against using C++ at all. I think part of the reason is that C2000 is not byte-addressable (something that apparently drives some people nuts, but I have no issue with). Again, the C2000 architecture is highly optimized for real-time and low latency control, and this is one aspect of that.

While first starting out, I also considered other targets, including Kinetis (I assume that's the freescale/NXP offering you refer to). The Kinetis V parts also looked like a viable option, but ultimately I chose the C2000 parts, mainly due to the availability of the CLA and the superior analog peripherals. This wasn't for a one-off personal project, but a project at work I knew I'd be working on for years, so I wasn't looking for a "plug and play" solution or a "wizard" to design things for me. And I'm happy with that decision. But it's not for the faint-hearted.