IDE V2.0 beta 10, ESP8266 sometimes doesn't upload

Windows10/64

I'm using an ESP8266 (NodeMCU) board. Its CP210x is connected as Com11.
The IDE knows this board is on com11.
When compiling is complete the uploader shows "Waiting for upload port..." and hangs there for maybe 5 - 10 seconds then shows "No upload port found, using COM11 as fallback"

However sometimes it does not go past "Waiting for upload port..."

Is this an issue (known?) or normal behavior (but not the hanging) or might my installation be corrupted?

Thanks
John

Screenshot 1:
image

Screenshot 2:
image

IDE output Window:

--------------------------
Compilation complete.
Waiting for upload port...
No upload port found, using COM11 as fallback
"C:\Users\John\AppData\Local\Arduino15\packages\esp8266\tools\python3\3.7.2-post1/python3" -I "C:\Users\John\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.2/tools/upload.py" --chip esp8266 --port "COM11" --baud "115200" ""  --before default_reset --after hard_reset write_flash 0x0 "C:\Users\John\AppData\Local\Temp\arduino-sketch-3F727CE5A70368309075A65567618910/GxEPD2_NotPagedExample.ino.bin"
esptool.py v3.0
Serial port COM11
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz

So it's a V2?
Have you programmed other identical boards from this computer and current ide install?

No I haven't. At the moment I don't have another of this card.

It is using the CP2102 USB chip. Earlier I was using an FTDI adapter with a Pro Mini and had no issues.
I do have a yellow caution triangle next to the board - port selection. See Screenshot 2.
I'm guessing that is related.

Just got a bunch of those. 10 for $30.

What steps did you do to set up for programming the ESP8266?

No, this is expected and normal for the boards that have a general-purpose USB chip like the CP2102 on your board. The :warning: is indicating that the board could not be automatically identified, meaning that there is no assurance that the port you have selected is the port of that board. Some boards use a dedicated USB VID/PID pair that was purchased by the board manufacturer. The IDE is able to automatically identify the board on that port, and in this case you will not see the warning icon. However, the general purpose chips like the CP2102, CH340, and FT232R use a VID/PID pair provided by the chip manufacturer and there is no way to know which board is associated with those common shared VID/PID pairs.

So just make sure that you have the right port selected. If you're not sure, you can verify it via this procedure:

  1. Unplug your Arduino board from the computer.
  2. Select Tools > Port from the Arduino IDE's menus.
  3. Note the ports, if any, listed in the menu.
  4. Close the Tools menu. The ports list is only updated when the Tools menu is re-opened, so this step is essential.
  5. Plug your Arduino board into the computer.
  6. Select Tools > Port from the Arduino IDE's menus. - The new port listed in the menu is your Arduino board.

After that, don't worry about the :warning: . There is a feature request for tracking the need to improve the way the IDE communicates this situation here:

1 Like

Select the board and pick the com port.

Thank you for your explanation.

Does this also explain the "No upload port found, using COM11 as fallback" with the preceding delay?

FWIW I just went into the driver list (nirsoft) and uninstalled all the non system discovery ports. I then went into the registry and reset the port numbers. Then I installed the updated CP210x driver.
No change in the IDE nor "No upload port found"

So I guess this is just how it works....

That is a separate issue. The ESP8266 boards platform is specifically configured to do this:
https://github.com/esp8266/Arduino/blob/3.0.2/boards.txt#L5562

nodemcuv2.upload.wait_for_upload_port=true

The upload.wait_for_upload_port platform property is documented here:
https://arduino.github.io/arduino-cli/latest/platform-specification/#1200-bps-bootloader-reset

  • wait_for_upload_port causes the upload procedure to wait for the serial port to (re)appear before and after the upload. This is only used when use_1200bps_touch is also set. When set, after doing the 1200 bps touch, the development software will wait for a new serial port to appear and use that as the port for uploads. Alternatively, if the original port does not disappear within a few seconds, the upload continues with the original port (which can be the case if the board was already put into bootloader manually, or the the disconnect and reconnect was missed). Additionally, after the upload is complete, the IDE again waits for a new port to appear (or the originally selected port to be present).

This feature is used on the native USB boards (e.g., Leonardo) where the serial port re-enumerates when the board is put into the bootloader mode needed to initiate an upload.

It is very odd that the ESP8266 boards platform developers set this property for their boards because the ESP8266 does not have native USB capability, and thus no re-enumeration occurs during the upload. My suspicion is that they just happened to copy/paste it from some other Arduino boards platform they were using as a model, without understanding the significance. I see that happening quite often in Arduino boards platforms, especially in years past when the system was not so well documented.

The odd configuration doesn't do any real harm, since the upload will eventually go ahead just as it would have without the property being set. However, it does unnecessarily increase the duration of the upload process because it must wait for the timeout to expire before carrying on with the upload, so it's inefficient and inconvenient for the user.

Now, you might have noticed that the classic Arduino IDE does not have this behavior. The reason is explained here:

This is only used when use_1200bps_touch is also set.

The "NodeMCU 1.0 (ESP-12E Module)" board definition does not set an upload.use_1200bps_touch property, and so the pointless upload.wait_for_upload_port should have no effect, and that is the case in the classic Arduino IDE. When the upload system was reimplemented in the Arduino CLI tool, that part was forgotten. Since Arduino IDE 2.x uses Arduino CLI for the upload process, it inherited that bug. This was reported here:

and fixed here:

That fix is in Arduino IDE 2.0.0-beta.12.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.