Hi All,
I am trying to program ESP8266 LoLin new NodeMcu V3 (a clone, see picture) but am not able to connect to Arduino ide. It says "the selected serial port_does not exist or your board is not connected" (I am using blink example). The detailed error message is attached. However, on the same port, when I press the reset button on my board, the serial monitor shows " ets Jan 8 2013,rst cause:2, boot mode:(7,7) waiting for host". Also, the baud rate for the serial communication is 74880 which is odd.
This is the first time I am trying any ESP programming. Any suggestion is welcome.
I tried with CH340G driver also but no luck. And I think if you are using windows 10 it automatically sets up the serial connection when you attach the device.
I think communication is happening because I am able to see outputs when I am pressing the reset key. I think the problem is somewhere else. Though I may be wrong.
You are correct. But for uploading you need to press the 'flash' button, hold it down and press and release the reset button. If you have done that, all that remains is IDE settings that could be incorrect. (The picture you've posted is not clear enough, please copy the error message and post in between </> code-tags ) or that the port is not free, due to some other program (like the serial monitor) is using it.
I have that same (photo's look identical) ESP8266 from an eBay vendor. And it would fail programming on the arduino IDE, both the 1.8.16, and the new 2.0 version. Only once did I get blink to program, but with difficulty. So reading about the problem, I went down the path of grounding GPIO00 (D3), which turns out to be a mistake with a hard ground as it permanently damaged that pin. I was still able to see the boot code on the IDE serial monitor (57600 baud), as your last copy image has, even after the damage.
When I looked at the GPIO00 pin with an Oscope, it had a 20MHz sine wave output, which is supposed to be a square wave. It was difficult to program from original power application, and me damaging it with a hard ground killed it.
I just got "WeMos D1 CH340 WiFi Full Size Board ESP8266 ESP-12F Arduino UNO R3" from an eBay seller, qty 2, and they both programmed up perfectly from the start. There is only a reset switch on these, and no boot enable switch.
Sorry but that was my solution to what most likely is a bad programming design, or a vendor problem of some versions of this board.
I did go down the path of trying capacitors between the 3.3 pins and ground (in the 3 locations with 47uF cap), and using a 5volt supply into the +5 input to use the onboard 3.3 regulator again with a 47Uf cap to gnd), and it would start programming then error out before finishing. Very frustrating!
@Deva_Rishi, I agree with @runaway_pancake. For uploading a program to NodeMcu, both the push buttons (reset and flash) are not needed. I think when we use a bare ESP8266 module and use Rx Tx and TTL converter then your method is used. I am posting the error code, let me know if you see anything.
Arduino: 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Board: "NodeMCU 1.0 (ESP-12E Module),
80 MHz, Flash, Disabled (new aborts on oom), Disabled, All SSL ciphers (most compatible), 32KB
cache + 32KB IRAM (balanced), Use pgm_read macros for IRAM/PROGMEM, 4MB (FS:2MB
OTA:~1019KB), 2, v2 Lower Memory, Disabled, None, Only Sketch, 115200"
Executable segment sizes:
ICACHE : 32768 - flash instruction cache
IROM : 231724 - code in flash (default or ICACHE_FLASH_ATTR)
IRAM : 26793 / 32768 - code in IRAM (IRAM_ATTR, ISRs...)
DATA : 1496 ) - initialized variables (global, static) in RAM/HEAP
RODATA : 876 ) / 81920 - constants (global, static) in RAM/HEAP
BSS : 25608 ) - zeroed variables (global, static) in RAM/HEAP
Sketch uses 260889 bytes (24%) of program storage space. Maximum is 1044464 bytes.
Global variables use 27980 bytes (34%) of dynamic memory, leaving 53940 bytes for local variables. Maximum is 81920 bytes.
esptool.py v3.0
Serial port COM5
Connecting........_____....._____....._____....._____....._____....._____.....____Traceback (most recent call last):
File "C:\Users\piyus\Documents\ArduinoData\packages\esp8266\hardware\esp8266\3.0.2/tools/uplo
d.py", line 66, in <module>
esptool.main(cmdline)
File "C:/Users/piyus/Documents/ArduinoData/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool\esptool.py", line 3552, in main
esp.connect(args.before, args.connect_attempts)
File "C:/Users/piyus/Documents/ArduinoData/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool\esptool.py", line 529, in connect
raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
the selected serial port _does not exist or your board is not connected
Some sketches cause the NodeMCU to be non-responsive to an upload and require the button resetting sequence. I haven't figured out what is special about those sketches, but I've experienced it first hand. It's true, most of the time it's not needed.
They all look alike, but there are quite a few variants going around.
Well regardless, the ESP needs to be put into flash mode, which is done by connecting GPIO 0 to GND during powerup, but it is possible that the board has an automated method for that. The state of some of the other pins may also be relevant, but i suppose you have nothing else connected to it.
Nothing special other than that the sketch compiles, but there is no response.
Consider trying nodeMCU 0.9 as a board selection.
So just in case ( i mentioned something about this already) make sure that there is no other application hogging the COM port.
That is the normal baud-rate for debug reset causes.
Now the reset cause 2 simply means that the reset button was pressed, but boot mode (7,7) looked unfamiliar but with some digging i found this table, where it shows that that means that all relevant pins GPIO 0 GPIOP 2 & GPIO 15 are all pulled HIGH or at least not pulled low at powerup. Now for GPIO 2 that is fine, but GPIO 0 needs to be pulled LOW for it topo be in flash mode, so clearly that is not happening, but that GPIO 15 is pulled HIGH is a different issue altogether, in that case it will not go into any proper usable mode at all. GPIO 15 can not be pulled HIGH at boot. So just to be a little careful, use a multimeter to confirm that, and pull it LOW, and use the 'flash' button to pull GPIO 0 LOW and hit reset.
If you do that with a sketch running that can happen if the GPIO is in output mode and HIGH, but if you only have it pulled HIGH at boot and you burn the pin, there was something wrong already.
Always possible, they don't come cheap because they all work perfectly, some of those batches are rejects, which mostly work, but some may be defective. (out of my last batch of 50 ESP-01's (8285) there was 1 unit that i never worked, still 1 in 50 is ok for that price, but most companies want 100% functional, and you may have been just unlucky. QC also takes time.
I found that using GPIO15 (aka D8) causes problems.
When I set up a DS18B20 data line and associated 4.7k pullup on GPIO15, I could not program and got a "waiting for host" message on startup after programming independently. Moving to GPIO4 solved both problems.
