PWM flickering with small analogWrite values [$15]

[ge0rg]

Hi, running the ESP8266 to control an RGB LED set via PWM on pins 12, 13, 15 using analogWrite().

When setting very low PWM values (<5), there is occasional flickering of the LEDs (the light turns to full brightness for a noticeable moment). Sometimes this is reinforced by network traffic, sometimes it happens without any apparent activity. The flickering is unrelated to the time when analogWrite() is called.

It helps a little to reduce the PWM frequency from 1KHz to 200Hz, but the flickering still happens from time to time.

I am aware that the PWM is based on a timer IRQ, not a hardware implementation, and I presume this issue is triggered by some other part of the code (wifi? tcp?) disabling interrupts for a short moment, leading to the timer interrupt being missed.

Unfortunately, the code in core_esp8266_wiring_pwm.c is not well documented and it's hard to understand for an outsider what exactly is happening there.

Would it be possible to mitigate the issue in the timer code? Maybe change it from edge- to level triggered or have the ISR called more often?

There is a $15 open bounty on this issue. Add to the bounty at Bountysource.

[igrr]

Timer interrupt is edge triggered — this is part of the chip design and it is not possible to change it in software. I suppose using NMI for PWM would fix this problem because NMI is higher priority than WiFi interrupts.

[ge0rg]

Would it be possible to try that out with moderate overhead? s/timer1/???/ in the pwm source?

[igrr]

You may try replacing ETS_FRC_TIMER1_INTR_ATTACH(timer1_isr_handler, NULL)
with ETS_FRC_TIMER1_NMI_INTR_ATTACH(timer1_isr_handler)
in core_esp8266_timer.c, line 45. Not sure if it will work though.

edit: Most likely there will be issues because ETS_FRC1_INTR_DISABLE will no longer work.

[ge0rg]

Replacing the regular interrupt with NMI leads to a watchdog reset ~10 seconds after startup:

ets Jan  8 2013,rst cause:4, boot mode:(1,6)
wdt reset

I even tried feeding the (soft) dog with system_soft_wdt_feed from the ISR, to no avail. It seems there is no function to feed the hardware watchdog, though.

Setting the timer to TIM_LOOP doesn't seem to improve the situation either - I hoped that a repeat of the ISR if it was missed will actually lead to some useful results.

I think I'll try the pwm_* functions from the official SDK next; let's hope they have some magic sauce to provide better stability.

[igrr]

As I mentioned, current implementation will have issues with NMI because it relies on a "critical section" implemented using ETS_FRC1_INTR_DISABLE. So the right thing to do would be fix this by disabling the timer or detaching NMI interrupt for the duration of the critical section.

[ge0rg]

I'm not sure this has to do with the PWM critical section at all. Merely adding a ETS_FRC_TIMER1_NMI_INTR_ATTACH(noop_function); to the code leads to a wdt reset. It rather seems to me that the espressif code is using an Nmi handler internally for watchdog purposes, and as long as we don't know which function was added as the Nmi handler, we can't just override it (without calling into it from our own handler).

I'd like to help out with that, but my knowledge of the platform and the different SDKs is rather limited. I'd be glad to get one or two pointers in the right direction.

P.S: When using the IoT_Demo from 1.3, the PWM is much more smooth and reliable, and it's got a usable value range of ~ 0..22222.

[mangelajo]

Hmm, I tried this early this weekend, and I found the flickering.

Analyzing the code I saw that we block the interrupt of the timer while we're copying the old values to the new ones (so the timer won't get half-copied info).

Also, I found that flickering is more likely to happen while you're doing heavy operations over the flash.

I think that a good strategy, and probably no NMI needed:

1. Move all the ISR/PWM the code to ICACHE RAM, so there's no issues with caching, and blocked flash.

2. Instead of disabling the interrupt for mutex, I'd do a mutex via a flag.
   a) The setter code, waits for the flag to be clear, before trying to set any new values,
   b) Set's the new value in a set of structures (mailbox-like),
   c) Set's the flag
   d) ISR updates PWM with any value it already had (to avoid any jitter)
   e) ISR finds the flag, and copies the new values to a final structure it will use.
   f) ISR clears the flag.

Does it sound reasonable?

[igrr]

I'm fixing the first part (moving handlers to RAM), commit coming in a few minutes.
Your approach with a flag does sound reasonable, actually it's the right way to go even if we are going to use NMI. I think NMI is necessary because otherwise we have flickering when there is heavy WiFi traffic.

[igrr]

First part pushed, fixing #819.

[ge0rg]

Wow, this really is a significant improvement! I'm test running the new code now and it looks much more stable.

I'm still experiencing a slight flickering when the PWM values get changed (i.e. when running a color fader), and a more noticeable flickering when one of the PWM values is switching between 0 and non-0, which seems to trigger a longer code path.

I wonder if it would be acceptable to mark all of the routines behind analogWrite as ICACHE_RAM_ATTR to solve the first problem.

I hope the second problem will be addressed with the flag-based ISR rewrite.

[Diaoul]

I'm experiencing the same issue with GPIO0 and GPIO2. ESP8266 is listening for POST requests and changes the value accordingly so that means that when the change happens, there is some network load. My knowledge is very limited on the ESP8266 so I don't know if I can be of any help troubleshooting this, however I can test the patches.

[Diaoul]

I'd be glad to help though my knowledge is limited, can you point me where to start and what should be done?

[demlak]

same here.. sketch to reproduce:

const int pin = 13;
void setup() {
  pinMode(pin,OUTPUT);
  Serial.begin(115200);
}
void loop() {
  analogWrite(pin, 1);
  delay(10); //to not overload esp8266
}

btw.. same flickering on analog Values >= 1019 as on <=4

edit:
value 5 and 1018 also has flickering.. but very rarely, compared with the other values..

edit2:
value 6 and 1017 also flickering.. but very very rarely... like 2-3 times an hour or so..

[Diaoul]

Using master branch is a lot better than the releases however some flickering still occur on network trafic, it's blinking once then back to the correct PWM setting.

[ArnieO]

I am experiencing the same flickering on ESP-03s.
@igrr : I have several ESP-8266 LED faders that have been running for several months with LUA code. I have never seen any glitching there, so I am not so certain if this is really only a HW issue?
My workaround until further will be to make sure the code avoids the sensitive value intervals.

[igrr]

This isn't a hardware issue. @mangelajo described software changes that need to be done pretty accurately.

[Diaoul]

Can you give more guidance on how to fix that? I'll gladly help but I'm not sure where to start and what needs to be done.

[ArnieO]

I found a workaround that seems to work well for me:
The default PWM frequency is 1000 Hz. By reducing to 200 Hz I got rid of the flickering on my module. (I tested step by step until the flickering disappeared).
PWM frequency is set to 200 Hz by this code:
analogWriteFreq(200);

[demlak]

thx a lot for sharing this workaround...
seems to fix the given problem of random flickering..

BUT opens another problem: 200hz seems to be too low to give a smooth output.. no random flickering of different brightnes anymore.. but continue flickering because of too low frequency..

[ArnieO]

I know 200 Hz is a bit low but on the ESP-03 I use I find the output to be smooth except for the very lowest setting, when the light is anyway almost invisible. So for me, the workaround is fully acceptable and without any noticeable drawback.

[demlak]

i´ll take a look at a low-pass filter for me.. but this is not ideal..

EDIT:
nevermind.. i just tested.. analogwrite value of 1.. with 200hz..
there are still brightnes flicker sometimes...

so.. problem still exists.. also at 200hz

[9H1LO]

issue still exists, flicker to full o/p when there is network traffic, i notice it when using more than 3 pwm channels, seems ok at 200hz up to 3ch i need 4 channels (rgbw with mqtt) and pca9685 will be over kill although i found it to work great

[krissfr]

i have the problem too, i need to control 5 pwm output (3 leds, 2 fans) from mqtt messages, but each wifi transmission flicker all leds (and make the fan noisy during the transmission). i need to use a high pwm frequency for the fan, so workaround are not good for my usage.

I hope somone with a high esp8266/C++ developpement skill will find a solution

[micw]

Hello,

I had serious problems with flickering when I fade my LEDs. PWM seems not to flicker when the LEDs are dimmes to a certain value, only when analogWrite is called with changing values.

I completely solved it by disabling interrupts before calling analogWrite and re-enable afterwards. There's my minimal sketch:

void setup() {
  analogWriteFreq(1000);
  pinMode(D1, OUTPUT);
  pinMode(D2, OUTPUT);
  pinMode(D3, OUTPUT);
  Serial.begin(115200);
  Serial.println(PWMRANGE);
}

int value=0;
int delta=1;

void loop() {
  value+=delta;
  if (value>1023) {
    value=1023;
    delta=-delta;
  } else if (value<0) {
    value=0;
    delta=-delta;
  }
  noInterrupts();
  analogWrite(D1,value);
  analogWrite(D2,value);
  analogWrite(D3,value);
  interrupts();
  delay(1);
}

Without noInterrupts/interrupts it flickers like hell. My guess is that it is a race condition when writing new pwm value while PWM interrupt is executed.

Regards,
Michael.

[micw]

Update: Flicker occurs again for some reason on my sketch when there's network traffic ;-(

[micw]

I have switched my sketch to use https://github.com/StefanBruens/ESP8266_new_pwm. I use a period of 5000 which gives me perfect 1kHz pwm. No flicker at all, works like charm.
Only drawback is that the API is not as clean as analogWrite().

IMO you really should replace the current implementation by this one.

[simonliu009]

@micw Does https://github.com/StefanBruens/ESP8266_new_pwm mean you switch to the ESP8266 SDK?

[micw]

@simonliu009 no, you can still use arduino ide with esp8266 extensions.

[JoaoLopesF]

Hi,

I made one sample to use the https://github.com/StefanBruens/ESP8266_new_pwm in Arduino.
See it in: https://github.com/JoaoLopesF/ESP8266-Arduino-PWM-SDK-Sample
Only this works fine to me.
Regards,
Joao

[devyte]

@igrr I see two possibilities here: migrate to the assembly pwm, or finish the original proposal with the flag.
What are your thoughts here?

[igrr]

ESP8266_new_pwn is GPLv2, so we can't use it here, unfortunately.
Fixing the race condition in the existing code should be a feasible option, i think.

[devyte]

@igrr I opened an issue there asking if the license can be changed to the same one in this repo. If so, we can continue that part of the discussion, and maybe contrast the two approaches. If not, so be it, we stick to the original plan.
Does that sound good?

[igrr]

Thanks, that sounds good.

…

On Fri, Oct 20, 2017 at 12:39 PM, Develo ***@***.***> wrote: @igrr <https://github.com/igrr> I opened an issue there asking if the license can be changed to the same one in this repo. If so, we can continue that part of the discussion, and maybe contrast the two approaches. If not, so be it, we stick to the original plan. Does that sound good? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#836 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJcejLbuzvOoUvYXM6OKQ4A6kMOWr4aks5suCQFgaJpZM4GFktw> .

[d-a-v]

+1s are now and currently needed at @devyte's issue in ESP8266_new_pwn

[devyte]

@earlephilhower does #4640 address this?

[earlephilhower]

@devyte A quick test shows no flickering for a few minutes at 1023/1024 value, but this is something I'd hope someone with a real DSO or logic analyzer could test (set a trigger on a pulse > than 20us and let it run overnight at 123/1024).

const int pin = LED_BUILTIN;
void setup() {
  pinMode(pin,OUTPUT);
  analogWriteFreq(1000);
  analogWriteRange(1024);
}
void loop() {
  analogWrite(pin, 1023);
  delay(10); //to not overload esp8266
}

Also see PWM was NMI (whereas Tone() and Servo() were not) in the original code. The current waveform generator is not NMI, so can have that ~10us or so jitter under heavy load. Doesn't cause visible changes, but this may be more than the old code was producing since it was guaranteed CPU priority/ It's a 2-line change to go to NMI, but unless we hear of some specific issue I'd rather not use NMI as I don't have enough info on how it would affect the WiFi and other parts of the chip.

[devyte]

@earlephilhower I don't think a DSO is needed to close this issue. The original description talks about visible flickering of an RGB led. I suggest just testing for visible flickering under heavy WiFi load, such as @d-a-v 's stress test, on a board that has an RGB led like the WittyCloud or similar. If no flickering, we're good.

[devyte]

Per discussion with @earlephilhower and his test results, this is not reproducible. Closing.

[crywolf87]

sorry, It's possible create a pwm with 5 hz frequency to esp8266?

[nos317]

I have the same question of @crywolf87
Anyone have a solution?

[JAndrassy]

sorry, It's possible create a pwm with 5 hz frequency to esp8266?

see the Arduino standard BlinkWithoutDelay example. it is 1 Hz. change the interval to 200 and you get 5 Hz