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.