PWM glitches on iMX6

[alexeyfirago]

Hello all,

We have a custom device based on iMX6D running Android. Device has a display with a backlight controlled by the PWM from iMX. PWM frequency is 100Hz. Everything works fine except one issue. When we decreasing brightness in Android (using the slider from UI or pwm-backlight sysfs entry) from 100% to 0% (downscale), we are observing some strange glitches - some of the low impulses (from high to low) are missing. So we have long high impulse instead of high-low-high. Duration of this long impulse is equals to the expected duration of high-low-high. When this glitch is happening brightness of the screen becomes higher (since obviously we have a longer duty cycle for some time). Attached picture shows the behavior:

Is this some HW misconfiguration?  Is there anything in driver/settings which can be adjusted to avoid this?

Thanks in advance!

[qiang_li-mpu_se]

Please try the attached patch, it will let PWM out start from low voltage and set to high at comparison, so the high to high issue will be low to low.

[TomE]

The patch flips the polarity of the PWM and inverts the input setting.

So the PWM glitches LOW instead of glitching HIGH.

But it still glitches!

Isn't this a silicon bug? Shouldn't there be an Errata Item with "setting the REPEAT bits" being listed as a Workaround?

I've just had this happen to me, and have reported it here with an oscilloscope trace showing the problem:

i.MX53 (possibly i.MX6) PWM Glitches on Duty Cycle Change

The Reference Manuals state:

51.7.5 PWM Sample Register (PWMx_PWMSAR)  (52.7.5 in i.MX6SDL manual)

The PWM will run at the last set duty-cycle setting if all the  (52.75 in i.MX6 values of
the FIFO has been utilized, until the FIFO is reloaded or the PWM is disabled. When a
new value is written, the duty cycle changes after the current period is over.

The above isn't happening. It only seems to be true if a new value is written while the FIFO isn't empty. When the FIFO is empty the PWM acts on the new value immediately.

I've got a fix that involves reading PWMSAR, writing that to PWMSAR (to load up the FIFO) and then write the NEW value into PWMSAR. That also synchronises the duty cycle to the end of the current period.

It is interesting that setting the REPEAT bits also seems to fix this.

Tom

[TomE]

I wrote:

> It is interesting that setting the REPEAT bits also seems to fix this.

it didn't fix it in my testing.

I've added a different patch that fixes this for me here:

https://community.freescale.com/message/522832#522832

Tom

[Jessie_Lee]

Hello Qiang Li,

Our customer reported similar dimming issue and they could fix this issue with your patch.

But they are concerning about the side-effect by this patch.

If we simply invert like patch, then it could be dimmed with high brightness.

==> it means we need to save previous duty_ns  and need comparing logic based on workaround code.

It could be dependent on previous value.

This patch would be workaround code. But, do we have formal fix for this issue?

BRs

jessie

[qiang_li-mpu_se]

"setting REPEAT bits of PWMx_PWMCR to repeat samples from the FIFO for 2 or 4 times"

This should be the correct fix for the issue.

[TomE]

Qiang Li wrote:

>"setting REPEAT bits of PWMx_PWMCR to repeat samples from the FIFO for 2 or 4 times"

> This should be the correct fix for the issue.

Could you please detail why this should fix this.

I have just written code to test this with REPEAT counts of 2, 4 and 8 and the problem is still present. It is less frequent, but the glitches are still there.

I would like to know if I've made a mistake in my testing.

I do know that if the tests are badly written then it can look like this problem has been fixed (because the test now seems to work), but the problem is still there in normal use. If the test updates the Duty Cycle faster than the cycle-rate multiplied by the repeat count, then this keeps the FIFO full, and that avoids the problem.

I have oscilloscope traces showing that in this post:

https://community.freescale.com/message/522425

Tom

[qiang_li-mpu_se]

Attached is the verified workable patch for this issue.

[TomE]

Qiang_FSL wrote:

> Attached is the verified workable patch for this issue.

I applied your patch and ran my test. It is still glitching when used with the LED Backlight driver.

What test did you perform to verify this patch? Was your test updating PWMSAR at a faster rate than the FIFO is now being consumed with the REPEAT active?

Which CPU are you using? I'm using i.MX53. Maybe there's a difference between the versions used from mx27, mx31, mx53 and mx6, and your patch may fix it in one of those but not in the one I'm using.

Tom

[alexeyfirago · Accepted solution]

Thanks for the suggestion. I assume in case of inverting the PWM signal glitch will just change accordingly - there will be much lower brightness for some time during the glitch.

The issue was actually workarounded by setting REPEAT bits of PWMx_PWMCR to repeat samples from the FIFO for 2 or 4 times.

[minhuoh]

Thank you for insightful comment. I'm also using imx6sabresd and i got same glitch problem when dimming to low brightness.

But i'm pretty beginner for pwm so could you share some patch file or guidance to workaround that issue?