Arduino: 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

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.

[d-a-v]

I can reproduce this wdt bug too, by including this sketch in another one doing network things (and which is proven to not wdt-fail by itself alone).
While I'm running the test, and before it fails, the led is sometimes badly glitching - not smoothly as it should.

[msilenius]

meanwhile someone on an other thread suggest to use a non existing dummy pin (255) this way you don't sacrifice a gpio for the workaround

[d-a-v]

Can you try and repeat the bug with this quick fix ?
This will at least eliminate the need of external workarounds.

--- a/cores/esp8266/core_esp8266_wiring_pwm.c
+++ b/cores/esp8266/core_esp8266_wiring_pwm.c
@@ -180,11 +180,16 @@ void ICACHE_RAM_ATTR pwm_stop_pin(uint8_t pin)
 extern void __analogWrite(uint8_t pin, int value)
 {
     bool start_timer = false;
+#if 0
+// workaround #4321: (not really a bugfix)
+// do not call pwm_stop_pin() when analogWriting 0
+// pwm is anyway stopped with digitalRead/Write and pinMode
     if(value == 0) {
         digitalWrite(pin, LOW);
         prep_pwm_steps();
         return;
     }
+#endif
     if((pwm_mask & (1 << pin)) == 0) {
         if(pwm_mask == 0) {
             memset(&_pwm_isr_data, 0, sizeof(_pwm_isr_data));

[d-a-v]

I spoke too fast, I just got my wdt again with the above patch.

[d-a-v]

I'm currently trying #4640 from @earlephilhower.
The led is no more flickering, and I let the sketch run for a while to check whether it wdt again.
I encourage you to try it too.

git fetch origin pull/4640/head:pr-4640-analogfixes
git checkout pr-4640-analogfixes

and restart the IDE

[d-a-v]

Almost 3 days without wdt, led is still breathing while doing network traffic at the same time.
I think we should wait for #4640 to be merged.

[SunboX]

Is there a plan when this will be released? Will it be in v2.4.2 ?

[d-a-v]

It is merged, so it will be in 2.4.2. Due date is August, 1st.