ESP8266 periodic freeze

[jasubot]

I'm running a program (Arduino framework) on my ESP8266, which polls data over WiFi once an hour. The polled data is displayed on 2x OLED displays (via I2C), and then (software) PWM adjusted to drive RGB Leds in matching color. In between the data polls, the ESP8266 sits executing a delay() command.

Problem: The ESP8266 may execute for days without any issue. But at some random point in time, I can notice the displays are no longer updated and the PWM (RGB color) is not changed. I have 6 prototypes running in my living room, so it's quite easy to detect when one of them has stopped updating its data.

Remarks:
a) The circuit doesn't heat up, or otherwise indicate any clear issues.
b) The RGB Leds keep their color, which indicates the software PWM keeps running.
c) The other prototypes keep running ok, with the same program, so it shouldn't be faulty code. I've also diagnosed the memory usage to ensure there are no leaks, to eliminate the possibility it was a software issue.
d) Once the ESP8266 has frozen, and if I power it off and back on relatively fast, the OLED displays don't come back to life. I need to wait for a longer time before they work again, which I assume means current gets stored somewhere and needed to first discharge?
e) Upon first boot, my program collects and stores the WiFi credentials to EEPROM memory. It's more an exception, but twice those seem to have gotten wiped out as well when I've rebooted my ESP8266 after it froze.

I've also checked the circuit with my oscilloscope (using triggers, etc.), and haven't noticed much of fluctuation in the voltage levels. But as this goes a bit beyond my expertise, I wouldn't exclude the possibility.

Circuit
I'm using AMS1117 to convert 5V to 3.3V input to my ESP8266. On V(in) I've had a 10uF or 20uF tantalum capacitor. On V(out) I've had a 100uF electrolytic capacitor (tried values up to 1000uF). The 5V input I've taken from different sources, to ensure the problem wasn't there. (What I haven't tried, would be 1uF or so ceramic capacitor right before the ESP.)

I have 3x MOSFETs (2N7000) to drive 4x RGB Leds that are in parallel. I started off without gate resistors, then adding 10ohm, eventually up to 300ohm. The gate resistors might've made the circuit slightly more stable.

Because my OLED displays share the same I2C address, I'm using 2x MOSFETs to switch their SCK line on/off. On the OLEDs' side I have 10k ohm pull-ups, which I forgot to draw in the attached image. With these MOSFETs, I also started off without gate resistors, adding them gradually up to 300ohm.

Then, I have 10k pull-ups on RST, EN, and gpio0, and a 10k pull-down on gpio15.

Remarks:
a) The MOSFETs add capacitance on the I2C SCK line, but it shouldn't be near the limits. While the SDA line doesn't have this capacitance, I guess it may add some slight offset in the signals.
b) I'm running my program in "debug mode", which means it's writing stdout to floating Serial RX/TX lines. I'm not sure if this may gradually build up to some issues as well which explained for the odd behavior.

Other

My first prototype was without MOSFET gate resistors. Oddly, the one ESP8266 that I never needed to reboot, and has been running smooth for almost 2 months now, is from this batch.

I've noticed the gpio0 and gpio2 have some limitations. Gpio0 couldn't produce 0V out (but was limited to about 1.7V when low), so that I later moved to gpio13. Then, in my first setups, a 10k pull-up on Gpio2 seemed to also be a destabilizing factor for the ESP8266.

IMPORTANT: None of the issues are present when I run the project on a breadboard with jumper cables. But when I move to a prototype board with soldered and shorter (in length) connections, the issues start.

Overall, more than fixing the problem, I'd be interested in understanding it (as I'm doing this to learn electronics). But after trying to study the problem for a month, I've come to conclude I need now someone else than just ChatGPT to try help me out. The two key findings that I believe are somewhere around the heart of the problem:
1) With a quick reboot the OLED displays don't come to life.
2) Works smooth (and allows quick reboots) on a breadboard with jumper cables.

[ESP_Sprite]

Few things I notice that may or may not add to the issue:
- Your reset circuit needs an additional capacitor of e.g. 1uF from /RST to GND.
- You only have an 100uF, electrolytic capacitor probably pretty far away from the ESP32 between +3V3 and GND. Try adding an additional ceramic or tantalum 10uF close to the ESP8266 module power pins, as you already suggested yourself.
- 10K pullups probably are too light for I2C at 3V3. (assuming that's all you have and your displays don't have pull-ups themselves). You want something like 1K - 3K3 of pullup in total on each line.

[jasubot]

Few things I notice that may or may not add to the issue:
- Your reset circuit needs an additional capacitor of e.g. 1uF from /RST to GND.
- You only have an 100uF, electrolytic capacitor probably pretty far away from the ESP32 between +3V3 and GND. Try adding an additional ceramic or tantalum 10uF close to the ESP8266 module power pins, as you already suggested yourself.
- 10K pullups probably are too light for I2C at 3V3. (assuming that's all you have and your displays don't have pull-ups themselves). You want something like 1K - 3K3 of pullup in total on each line.

Thanks!

Had forgotten about the capacitor for RST. Not sure why is it recommended there, in the many guides I've seen, but there's still a lot I have to learn about capacitors anyway. Will try adding also that 10uF close to the power pins (thought of 1uF myself, but that was just a guess).

What I'm still curious about, is that how can the ESP stop executing my program, while keeping the software PWM running. As I would assume if the program halted (or somehow crashed), also the PWM would be stopped. Then, as I'm rather convinced the issue is not in my code, what could be the hardware-level / external phenomena that can cause such?

I'm also wondering what can prevent the displays from being rebooted quick, and why I need to wait up to several minutes before they start on a power-up again. Simplest explanation was probably if the ESP was unable to control the MOSFETs for some reason, but I don't see how that could be. Guess I will need to monitor the signals around the MOSFET to see whether the issue is there or on the displays.

Not sure really what all is going on there. But I've come to think could the WiFi peak the current draw from the regulator (AMS1117), exhaust it, and by that exhaust the ESP itself - which somehow explained for the program to stall. But if that was the case, I'm not sure what explained for the power-up issues with the displays, unless the regulator needed some cool-off time (even that it doesn't catch up any heat).

[ESP_Sprite]

What I'm still curious about, is that how can the ESP stop executing my program, while keeping the software PWM running. As I would assume if the program halted (or somehow crashed), also the PWM would be stopped. Then, as I'm rather convinced the issue is not in my code, what could be the hardware-level / external phenomena that can cause such?

If you run any chip out-of-spec, it can do weird things. For instance, a low-power glitch can skip instructions in your code. Could be that your program layout plus lack of decoupling leads to one of those in such a way that your main code doesn't do anything anymore but ISRs still keep on running.