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)
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!
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).
@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.
@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.
@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 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.
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?
@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.
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.