Unstable operation of the PWM (FRDM K64F, mBed PWM library)

Mbed OS Bugs
1

When we set PWM ratio once we can get PWM to operate relatively stable way anyway when we update the pulsewidth with the same value we get unstable output. Below is the example:

PwmOut pwm_1(PWM_1);
PwmOut pwm_2(PWM_2);
PwmOut pwm_3(PWM_3);

we configure PWM once:
pwm_1.period(PWM_PERIOD);
pwm_1.pulsewidth(0.002f);
pwm_2.period(PWM_PERIOD);
pwm_2.pulsewidth(0.003f);
pwm_3.period(PWM_PERIOD);
pwm_3.pulsewidth(0.004f);

pwm_1.pulsewidth(0.3 * PWM_PERIOD);
pwm_2.pulsewidth(0.5 * PWM_PERIOD);
pwm_3.pulsewidth(0.8 * PWM_PERIOD);

If the PWM is not touched it generates relatively stable pulse train yet some jitter is still seen (see image below)

image
image811×508 17.8 KB

Real problem starts when in asynchronic thread in it’s main loop I add pulse width manipulation - with very same values being written every loop of the thread.

    pwm_1.pulsewidth(0.3 * PWM_PERIOD);
    pwm_2.pulsewidth(0.5 * PWM_PERIOD);
    pwm_3.pulsewidth(0.8 * PWM_PERIOD);

Please note I use the same values I used initially so theoretically nothing should be changed.
As the result I have very unstable PWM period:

image
image816×509 18.4 KB

As you notice setting pulse width changes (for single period) the pulse period - effectively changing the PWM Ratio.

For bigger update rate I’ve got even worse image:

image
image1739×930 32.1 KB

Here pulses start to connect!

Any comments?

2

Hi Waldemar,

Why you need to update PWM pulse width periodically? It will set the PWM HW again and again and might cause some problems, one of them might like what you’ve observed.

Regards,
Desmond

3

I think we all agree that PWM is not about fixed division factor but is used as the pact of the control loops where some inputs produce changed PWM which (as for the example) impact the hardware etc. As so the PWM hardware once set should remind stable when H/L ratio or pulse width is changed. Otherwise we loose purpose of the PWM.

4

First of all, I’m not a mbed expert, so my comment is just a developer’s point of view.

Nothing bad in changing PWM pulse width periodically, however what the reason for setting the same value? It can be avoided by an additional check (compare previous value to the current one).
Theoretically, this check could sit inside the pulsewidth method, though I’m not sure that it definitely should.

5

The issue I shown is for updating the same value or not. Just the update of the ratio or the PWM make PWM be reprogrammed from the scratch what causes the issue.
I agree that in real code such update with same value could be eliminated - anyway when ‘hunting’ for the cause of strange HW behavior I simplified the control loop eliminating all what might is not much controllable - leaving update with more controlled values (so constant ones as presented in the example). Please also understand that sample code purpose was to eliminate discussions on ‘you probably wrongly compute values you use in the control of the PWM so better buy some XYZ company SW/HW which use real operating system and better CPU etc.’

If you are interested in this how I use it - here is short description - data is collected from a total of 14 measurement channels in one thread, based on the input from the user and network in other thread we compute values for outputs (3 channels) and the values computed are passed to HW. Other thread do self checking etc. providing ability to check for typical issues/failures. There is also part doing using interface. Last part is watchdog and validity checking.

6

Now I see your point, it makes sense.