analogWrite causes reboot

[yukini3]

Basic Infos

Although this issue is discussed and closed on #2238, this is still happening on my ESP8266s.

Hardware

Hardware: ESP-12
Core Version: 2.4.0

Description

analogWrite causes system reboot. To repro this problem, run the attached code and WAIT for a while. It happens randomly. Sometimes 10 minutes, somtimes few hours etc.

Settings in IDE

Module: Generic ESP8266 Module
Flash Size: 4MB/1MB
CPU Frequency: 80Mhz
Flash Mode: qio
Flash Frequency: 40Mhz?
Upload Using: OTA / SERIAL
Reset Method: ck / nodemcu

Sketch

#include <ESP8266WiFi.h>

#define PIN_LED 16

int fadeIncrement = 1;
int fadeValue = 0;
int showWiFi = 0;

void setup() {
  // put your setup code here, to run once:

  Serial.begin(115200);
  Serial.print("\n\nSDK Version=");
  Serial.println(ESP.getCoreVersion());
  
  pinMode(PIN_LED, OUTPUT);
  analogWriteRange(100);
  analogWrite(PIN_LED, 0);  

  WiFi.begin("YOURSSID","YOURPASS");
  
}

void loop() {
  // put your main code here, to run repeatedly:
  analogWrite(PIN_LED,fadeValue);
  fadeValue += fadeIncrement;
  if (fadeValue > 100) {
    fadeValue = 100;
    fadeIncrement = -1;
  } else if (fadeValue < 0) {
    fadeValue = 0;
    fadeIncrement = 1;
  }
  delay(10);

  if (WiFi.status() == WL_CONNECTED && showWiFi == 0) {
    Serial.print("WiFi Connected. IP=");
    Serial.println(WiFi.localIP());
    showWiFi = 1;
  }
}

Debug Messages

SDK Version=2_4_0
WiFi Connected. IP=192.168.10.157

 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v4ceabea9
~ld


SDK Version=2_4_0
WiFi Connected. IP=192.168.10.157

[WereCatf]

Does it still happen, if you comment out the call to analogWriteRange()?

[devyte]

@yukini3 I can't reproduce this, and I tried on a WittyCloud and a Wemos D1 mini R2. The LED pulses correctly. I used the onboard RGB n the Witty and builtin led on the D1 mini.

Are you using a generic board? Such resets are typical of a bad power supply, noise or bad connections, (bad protoboard), or a bad LED pin (e,g,; resistor too small or damaged, or damaged pin, etc).

More unlikely, you have a board with bad flash, or you flashed at too high speed (going above 230Kbps for flashing your sketch is just asking for trouble).

Closing as can't reproduce.

[yukini3]

I purchased Wemos D1 mini R2 and was able to reproduce this problem. You need to run little longer than you did in order to reproduce. Although you think this is due to faulty wire or noise or lack of power but I think that this is other factor is involved.

I looked into the code for further investigation and found that the fault is always happening at the same place - timer1_write(1); in pwm_start_timer();. Because I was able to pin point the fault, I can workaround this fault by not calling pwm_start_timer() which you would call analogWrite with dummy PIN and non zero value for the PWM (ex. analogWrite(DUMMY_PIN, 10);) at the start of your code (it calls pwm_start_timer()) and don't change the value so that further pwm_start_timer calling wouldn't occur. I deployed this workaround in my production code and now running for over 3 days without problem.

For those of who having experiencing PWM problem, you could try this workaround.

[devyte]

I ran for something like 30mins on each board, and I still can't reproduce.
I don't understand the explanation of your workaround. Please provide an example.

[tonton81]

better idea, send your bin uploaded here so someone can flash it, if they CAN reproduce it it must be your installation issue of IDE/outdated core files..

[lrmoreno007]

Tonight I left an NodeMCU with the sketch supplied running and this morning I had 5 WDT.

I'm going to update git and activate debug messages, to see if I get any more information.

[d-a-v]

How do you power your ESPs ?
@yukini can you explain more your workaround ?
I will let a wemos d1 mini run over the WE. So far 3 hours and no wdt. Powered by an USB3 port on a PC, no hub.

[lrmoreno007]

With a USB3 port on a PC too. I never have WDT problems with this board and this supply. And sometimes I've had him running for a long time with other sketchs.

UPDATE: 7 hours and 3 WDT, debug does not return any valuable information.

[yukini3]

Apologize for my delay. Here's the code of workaround.
PWM of PIN_DUMMY is always 10 so that there will be no further pwm_start_timer() call.

#include <ESP8266WiFi.h>

#define PIN_LED 16
#define PIN_DUMMY 15

int fadeIncrement = 1;
int fadeValue = 0;
int showWiFi = 0;

void setup() {
	// put your setup code here, to run once:

	Serial.begin(115200);
	Serial.print("\n\nSDK VERsion=");
	Serial.println(ESP.getCoreVersion());

	pinMode(PIN_LED, OUTPUT);
	pinMode(PIN_DUMMY, OUTPUT);
	analogWriteRange(100);
	analogWrite(PIN_LED, 0);
	analogWrite(PIN_DUMMY, 0);
	analogWrite(PIN_DUMMY, 10);

	WiFi.begin("****", "****");

}

void loop() {
	// put your main code here, to run repeatedly:
	analogWrite(PIN_LED, fadeValue);
	fadeValue += fadeIncrement;
	if (fadeValue > 100) {
		fadeValue = 100;
		fadeIncrement = -1;
	}
	else if (fadeValue < 0) {
		fadeValue = 0;
		fadeIncrement = 1;
	}
	delay(10);

	if (WiFi.status() == WL_CONNECTED && showWiFi == 0) {
		Serial.print("WiFi Connected. IP=");
		Serial.println(WiFi.localIP());
		showWiFi = 1;
	}
}
```
`

[devyte]

Is this still valid with release 2.4.1?

[yukini3]

It still does also something wrong with SDK version number?

SDK Version=00000000
WiFi Connected. IP=192.168.10.148

ets Jan 8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v00000000
~ld

[msilenius]

I have exactly the same problem with 2.4.1

i thought i was going crazy, tried 3 different board, 3 power suply (including a lab one directly on the 3.3v), and 4 differents prototype circuitry (2 lab boards 2 soldered) all had was ramdom freeze on a call to analogwrite on a led driven by a darlington array.

thanks you yukini3 your workaround did save my life even though it cost me one gpio.

[msilenius]

it might be related to networking. the led i use with the analogwrite change color depending of network status: white = not connected; orange connected,
before using the workaround i never see it turn white once initialisation is over.
after workaround sometime it turn white for a very short time.
there might be a conflict betwneen wifi processing reconnection and the timer of the PWM.