[Solved] PSoC 5LP HRPWM

[blueskull]

I'm recently working on a simple boost converter controller based on any MCU I can find. As a long time PSoC developer, my first thought was PSoC 5LP running at 80MHz, which gives 12.5ns PWM resolution.
I know I can use C2000 or dsPIC33GS series, but I would like to hack the converter as quick as possible, and it just happens that I have a PSoC5888 board lying around (the $10 gum stick kit), plus the ability to use 5V logic makes interfacing easier.
My question is, is there a way to gain even better PWM resolution by using UDB as delay line? I only need to interpolate PWM resolution by 4, so ~3ns predictable delay is perfect. Thanks in advance.

----------Solved----------

Solution: using logic gates to create delay line and disable logic optimization in build settings.
Tap resolution is ~2.3ns. Not dynamically calibrated, but for such a coarse tap resolution (compared with down to 55ps for some C2000), I highly doubt if dynamic calibration is necessary.



Code attached for those who wants to build SMPS with PSoC5, and I believe if you have tools to measure ns level delay, you can also port the code to PSoC3 or PSoC4.

Since tap resolution is ~2.3ns, I set PWM clock ti 72MHz, so that 1/72MHz=13.9ns is close to an integer multiple of 2.3ns, in this case, the multiplier is 6. Each PWM LSB is divided into 6 sub slots with delay line to allow 6x resolution.

Test result:
n=6: t_on=14.9ns
n=7: t_on=17.5ns, delta=2.6ns
n=8: t_on=19.8ns, delta=2.3ns
n=9: t_on=22.2ns, delta=2.4ns
n=10: t_on=24.8ns, delta=2.6ns
n=11: t_on=27.1ns, delta=2.3ns
n=12: t_on=29.1ns, delta=2.0ns

Here when n=12 (or any n where n%6=0), delta t is a bit lower due to tap position revolves every 6 of n, and hence there will be some random error caused mismatching of oscillator period and delay line period, and for me, 0.6ns timing error is good enough.

----------Update----------

With some fine tuning, I settled at fosc=68MHz, and delta t per step is as follow (measured with high res mode of my scope):

2.36ns
2.48ns
2.29ns
2.53ns
2.37ns
2.53ns

It seems fairly decent to me, at least for SMPS applications.

This average tap size of 1/(68MHz*6)=2.45ns allows 10bit PWM resolution even at 400kHz, and 9bit resolution at 800kHz. What's more, it is free if you already have PSoC in your system.
Considering the PSoC5 LP gum stick board is only $10 at 1pcs (the 2 chips on board along are $20+ at 5kpcs), I just ordered a few more of them for my other projects.
I can finally say goodbye to F28377S and dsPIC33EP32GS202. They are just too hard to develop (limited resource of demo cases, and less easy to use library support) compared with PSoC family, and I'm not a professional embedded engineer.

[timb]

Yes, that might be doable. Are you familiar with generating timing reports in PSoC Creator?

[timb]

Yes, that might be doable. Are you familiar with generating timing reports in PSoC Creator?

Unfortunately, no. I hope I don't have to write SDC files like doing FPGA timing constraints.
Can you share some if your insights on how to do this?

No no, it's a lot simpler than dealing with FPGA timing constraints and such. Basically PSoC Creator can generate timing reports showing the skew between various clocks, clocking delays introduced by UDB and such.

Basically, my thought is you can use the data from these reports to create and tune a delay line component.

Let me play around with PSoC Creator a bit tonight and I'll post some examples and information for you.

Can you expand a bit more on what you're ultimately trying to accomplish? (PWM output frequency and precision, etc.)

Also, you need to check the end of the data sheets for any components you want to use for their maximum clock frequency. You mentioned running the part at 80MHz, keep in mind most components won't run anywhere near that (30-60MHz seems to be the max for most UDB based components).

By the way, I've seen the PSoC 5LP used in motor control and SMPS applications before (in applications a C2000 would traditionally be used), so I think your goal is 100% achievable.