analogWrite is reset to the minimum or maximum value

[X-Stas-EEE]

Platform

• Hardware: ESP-12E
• Core Version: win-2.5.0-dev
• Development Env: Arduino IDE
• Operating System: Windows

Settings in IDE

• Module: Nodemcu 1.0
• Flash Mode: ?
• Flash Size: 4MB
• lwip Variant: v2 Lower Memory
• Reset Method: nodemcu?
• Flash Frequency: 40Mhz?
• CPU Frequency: 80Mhz
• Upload Using: SERIAL
• Upload Speed: 256000

Problem Description

AnalogWrite is reset to zero or maximum value. The plugged led gets stuck on the maximum PWM level or turns off. At the same time the buzzer continues to play sounds. Thus, it becomes clear that the module does not hang. To replicate the problem run the attached code and wait for a while. It may take a few hours. The problem is mentioned in #4640

Sketch

#define LED_PIN D1 // GPIO5
#define BUZ_PIN D2 // GPIO4
int bright;
bool increase;
int note;
unsigned long cur_millis = millis();
unsigned long prev_millis = cur_millis;

void setup() {
  Serial.begin(115200);
  Serial.print("\n\nSDK Version=");
  Serial.println(ESP.getCoreVersion());
  pinMode(LED_PIN, OUTPUT);
  pinMode(BUZ_PIN, OUTPUT);
  bright = 0;
  increase = true;
}

void loop() {
  cur_millis = millis();
  if (abs(cur_millis - prev_millis) > 100) {
    analogWrite(LED_PIN, bright);
    if (increase) {
      bright++;
    } else {
      bright--;
    }
    if (bright >= 105) {
      increase = false;
    } else if (bright <= 10) {
      increase = true;
    }
    prev_millis = cur_millis;
    tone(BUZ_PIN, (double)bright+200, 85);
  } 
}

Debug Messages

SDK:2.2.1(cfd48f3)/Core:win-2.5.0-dev/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-10-g0c0d8c2)/BearSSL:94e9704


SDK Version=00000000
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 4
cnt 

connected with HUT, channel 1
dhcp client start...
ip:192.168.1.7,mask:255.255.255.0,gw:192.168.1.1
pm open,type:2 0

[earlephilhower]

@X-Stas-EEE I'll try and repro and look at this tonight. If you have the chance, could you add a
WiFi.mode(WIFI_OFF);
to the beginning of the setup() loop to verify that it's not related in any way to the WiFi stack (which does use interrupts and other long-running processes in the background)? If it fails with WiFi on (like your run) but passes with it off, that's a good pointer.

[X-Stas-EEE]

@earlephilhower OK, I'll run the test again with this line. Hope the bug will be caught this night. Otherwise, I'll leave the ESP running for a couple of days. I will not be able to observe the execution of the test this weekend.

[X-Stas-EEE]

@earlephilhower The bug is still there, even with the Wi-Fi switched off. The modified sketch:

#include <ESP8266WiFi.h>

#define LED_PIN D1 // GPIO5
#define BUZ_PIN D2 // GPIO4
int bright;
bool increase;
int note;
unsigned long cur_millis = millis();
unsigned long prev_millis = cur_millis;

void setup() {
  WiFi.mode(WIFI_OFF);
  Serial.begin(115200);
  Serial.print("\n\nSDK Version=");
  Serial.println(ESP.getCoreVersion());
  pinMode(LED_PIN, OUTPUT);
  pinMode(BUZ_PIN, OUTPUT);
  bright = 0;
  increase = true;
}

void loop() {
  cur_millis = millis();
  if (abs(cur_millis - prev_millis) > 100) {
    analogWrite(LED_PIN, bright);
    if (increase) {
      bright++;
    } else {
      bright--;
    }
    if (bright >= 105) {
      increase = false;
    } else if (bright <= 10) {
      increase = true;
    }
    prev_millis = cur_millis;
    tone(BUZ_PIN, (double)bright+200, 85);
  } 
}

[earlephilhower]

Thanks! I think this is related to

Arduino/cores/esp8266/core_esp8266_waveform.c

Line 254 in 3906ee4

if (now >= wave->nextServiceCycle) {

I should be subtracting the two values and checking for <0. As-is, I think I can make it fail by making nextservicecycle = 2^32-1 cycles and the ESP cycle counter overflowing before I get to handfle it. In that case, this edge will not be caught because now=1, which is past the service time but < nextservicecycle.

I will try and repro the failure on my system tonight, then do the fix and see if it lasts a full day.

[earlephilhower]

Was able to catch it after only ~25 minutes of runtime. It has a chance of self-correcting every 2^32/80M = ~53 seconds due to counter wraparound. Just did the fix (1-liner) and restarted and started my logic analyzer. With any luck the USB analyzer will run overnight and not crash (crappy analyzer, unrelated to the code or ESP8266!) and I can dump and post-process to verify no PWM freezes.

[earlephilhower]

The logic analyzer only captured ~2.5hrs before stopping, but analysis of that time shows it was clean, and the LED was still fading in and out this morning, so I think we've got a fix!

Please give PR #4945 a try, @X-Stas-EEE.

[X-Stas-EEE]

@earlephilhower
I've just run the test. Will wait for several hours.
The first observation: it seems that the maximum brightness level became lower.

[earlephilhower]

Cool, looking fwd. to the update!

FWIW the brightness levels should be absolutely unaffected, the change was related to it missing an edge when the edge happened near a timer wraparound (~every minute IIRC) which would end up causing a full-on or full-off until (at least) the next time the wraparound occurred. Pretty obvious problem in the code, but only hit in cases when the interrupt was a little late (due to other things, like add'l waveforms).

[X-Stas-EEE]

Everithing looks good so far. I've deleted my previous comment because it contained erroneous information.

[X-Stas-EEE]

@earlephilhower I confirm that the bug has been fixed! Thanks a lot for your work!