Hello, I had the same problem and after your solution the board worked for a minute, but then the "internet site" of the node mcu board shut down, the blue led is blinking every few seconds and in the serial monitor there's this error message:
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v0004a520
~ld
� a�n�r��n|� l � l` b brl�nb�n l`� rl�l� �
The message you see here is printed by the ROM bootloader on the ESP8266 microcontroller. If you consult table 1-1 of the "ESP8266 Reset Causes and Common Fatal Exception Causes" application note provided by the manufacturer of the ESP8266 microcontroller, you can learn the significance of the reset cause code:
Table 1-1. Identifying Reset Cause in ROM Code
Rst cause No.
Cause
0
Undefined
1
Power reboot
2
External reset or wake-up from Deep-sleep
4
Hardware WDT reset
So the reset cause is "Hardware WDT reset". The "WDT" stands for "watchdog timer". The watchdog timer is a feature that allows the device to recover from a bugged state where the program is hanging. The way it works is that there is a timer that is constantly counting down. While the program is running normally, this timer will be reset periodically and so it never times out. But if for some reason the program completely hangs then the watchdog timer times out and automatically resets the microcontroller.
Now the question is: why is the watchdog timer timing out? It might be caused by a bug in your sketch program, or by the board being subjected to some conditions that are outside its rated specs. A good way to bisect this is to upload a sketch that we know has no bugs. Please try this experiment:
Select File > Examples > 01.Basics > BareMinimum from the Arduino IDE menus.
A sketch that contains only the minimum code will open in an Arduino IDE window.
Upload the sketch to your board as usual.
Now add a forum reply here that answers the following question:
Does the problem of the board repeatedly resetting and printing the "rst cause:4" message to Serial Monitor still occur when the board is running that "BareMinimum" sketch program?
This is the message we expect when the board is working normally.
This result verifies that the unexpected resets you were experiencing previously are in some way related to the code of the sketch program that was running on the board when you experienced that behavior, rather than being a universal problem that occurs regardless of the running program.
This means the focus should be on analyzing the code of the sketch that caused the problem to pinpoint the exact cause.
Thank you. I tried to upload the same code on another laptop and it worked. I read that this kind of esp needs much current for uploading and it may cause trouble with the usb port. I'm not sure if was that error, but I'm glad that it works now.
Thank you for your great help in the forum!
I'm glad it is working now. Thanks for taking the time to post an update.
The current could definitely be the cause.
If the board is drawing more current than the power supply is capable of, this can result in a voltage drop to a level below the minimum required for stable operation of the board. That might cause the program to hang and thus trigger the hardware watchdog. A tricky thing about the ESP8266 is that its current draw spikes periodically when the Wi-Fi radio is in use. So even if the power supply is plenty capable of the average current draw, you need significantly more capability in order to handle those spikes.
It might be that the problematic sketch used the Wi-Fi capabilities in a way that increased the current requirements, or maybe even that there were some transient conditions in the RF environment (I believe the current draw can vary depending on the characteristic of the communication between the ESP8266 and the access point).