Hi everyone. I'm having some issues with my controller randomly freezing/resetting and wanted to

fastled-support
gplus
(Dylan Lovinger) #1

Hi everyone. I’m having some issues with my controller randomly freezing/resetting and wanted to see if anyone else has experienced similar issues. I believe it is a problem with my ESP8266 ESP-12E NodeMCU.

The issue is random freezing, where the controller will simply freeze. It typically restarts itself after a freeze, but will sometimes hang indefinitely. It seems to occur completely randomly, sometimes with hours between freezes and sometimes minutes. The following is one of the crash reports output to serial:
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
v614f7c32
~ld

To explain my hardware/software. I don’t believe it is a software issue, as the freezes will occur on the simplest of test/example code (typical barebones fill_rainbow for example). For hardware, I am using an ESP8266 NodeMCU with an external 5V 25W & 50W power supply (tried both). 5V is connected to VIN on the ESP, GND to GND, data to various pins GPIO0-5 (and more, I’ve tried them all). There is a 470ohm resistor on the data line, and a 1000uF cap in parallel across the +/- going into the LEDs. I’ve tried multiple ESP8266 NodeMCU boards, all with the same issue.

Does anyone have experience with this? The random freezes are unacceptable behavior, but the ESP8266 is such good value for the power it packs. Is there an ESP variant other than the NodeMCU that’s more stable? Advice and ideas welcome, thank you!

(Chris Parton) #2

Could simply be a damaged board. Have you tried more than one of them?

I use ESP32 boards, I’ve got 12 of them running my Xmas display. One of them sometimes doesn’t start up until I reboot it a couple of times (it’ll be going in the bin soon).

(Dylan Lovinger) #3

@Chris_Parton Yeah my first thought as well. I’ve tried about 4 of them with the same issue, so it’s not the board. They were all the same board type, ESP-12E NodeMCU though, so I’m also wondering if these are just unreliable and if there’s a better alternative.

(Ken White) #4

@Dylan_Lovinger - - Could you please post your code that hangs up the ESP8266 MCU in GitHub or Gist.

I have been using the Wemos D1 Mini Pro and Lolin ESP 32 boards with the current version of FastLED and the Arduino 1.8.7 IDE without any problems.

I assume you are running a FastLED sketch when this happens. Does this happen when you run one of the FastLED examples like DemoReel100?

Check to make sure any of your Led[X] = color in your code is never X>= NUM_LEDS where NUM_LEDS is used in CRGB leds[NUM_LEDS].

Also check any arrays that you are using so that the number used to define an element in an array is never equal to or greater than the number of elements in the array.

Remember, both CRGB array and standard arrays start at 0 and not 1. Putting a value outside the array maximum value does strange things to your MCU including causing it to freeze. I learned this the hard way.

(Dylan Lovinger) #5

@Ken_White Indeed, what I meant by example code was that the FastLED examples, like DemoReel100, still freeze up. So I don’t think that it’s an issue with the code. Though I will go through and double check my main code to ensure I’m not going over in any indices. Thank you.

(Jeremy Spencer) #6

Which version of the ESP8266 core are you using (from boards manager)?

Stick to version 2.4.x, the latest ones don’t play nicely with FastLED.

And which version of FastLED and which version of the Arduino IDE?

(Dylan Lovinger) #7

@Jeremy_Spencer Good call. I’m using the latest FastLED 3.2.1 and Arduino 1.8.7, but I was using an older 2.4.0 ESP8266 core. I’ve updated to 2.4.2, so we’ll see if that has any effect. Thanks for the advice.

(Dylan Lovinger) #8

I actually managed to get some info on the reset through serial, if this helps:

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
v614f7c32
~ld

(Yves BAZIN) #9

@Dylan_Lovinger how many leds are you using ?

(Dylan Lovinger) #10

@Yves_BAZIN Using 264 total, two strips of 132 LEDs each, on GPIO 4&5. I’m not certain it occurs with fewer LEDs, but I can try it out.

(Jeremy Spencer) #11

I find that pins 5,6,7 and 8 are usually best on an ESP8266

(Jeremy Spencer) #12

Wdt reset, is the watchdog timer. Try reducing or removing your delays, especially FastLED.delay()

(Ken White) #13

@Dylan_Lovinger - Try my following sketch on your MCU:

For the Wemos D1Mini Pro, I change the DATA_PIN to D6. I have run this sketch successfully on the Wemos D1Mini Pro for up to 256 NEOPIXELS on a single strip or matrix. If it does not run for one strip of about 30 pixels on your MCU, then there is something wrong with your MCU or with the ESP8266 library in the Arduino IDE.

Just a thought, do you have more than one version of the ESP8266 library on your computer?

(Dylan Lovinger) #14

@Jeremy_Spencer By pins 5-8 you mean GPIO12-15? The issue is that I’m planning to use SPI communication, so these four pins will all be accounted for. There aren’t really any delays in the code, so I think the wd timer is being triggered falsely somehow.

@Ken_White I’ll give that sketch a shot, thanks. As for versions of the ESP8266 library, there is indeed only one version installed, 2.4.2.

(Dylan Lovinger) #15

Wanted to provide an update since I think I figured it out. Disabling the WiFi module seems to have solved the freezing issue. This single line under setup: WiFi.forceSleepBegin();

The WiFi module is a bit power hungry, and I think it gets unhappy when receiving unstable power. Ultimately the problem is likely due to power supplies outputting a moderately unstable current, even though I’ve tried 3. I suppose it doesn’t take much to reset the WiFi module. Either way, I’m not currently using WiFi so simply turning it off works as a solution for now.