I defined 'pin' as 2 and it works.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
TL;DR: For VS Code + PlatformIO users flashing an ESP-01S on COM3,
115200baud plus "upload_resetmethod = nodemcu" turned repeated packet-header timeouts into a working upload path. This FAQ solves two linked problems: PlatformIO upload failures and Blink sketches that upload but still do not run until the LED pin is set to GPIO2. [#20795458]
Why it matters: This thread shows that ESP-01S failures can come from both upload/reset settings and wrong LED pin mapping, so fixing only one side may still leave Blink apparently broken.
| Tool or setting | What happened in the thread | Result |
|---|---|---|
| Arduino IDE + Generic ESP8266 Module | Upload worked earlier | Sketch behavior used as reference |
PlatformIO + basic esp01_1m config |
Upload timed out on COM3 | Failed to connect |
PlatformIO + upload_speed = 115200 + upload_resetmethod = nodemcu |
Upload completed | Flashing succeeded |
Blink with LED_BUILTIN |
LED did not blink | Misleading "not running" symptom |
Blink with explicit pin = 2 |
LED blinked | Working result |
Key insight: The timeout was fixed by changing PlatformIO upload/reset behavior, but the final Blink result required a second fix: define the LED pin explicitly as GPIO2 instead of relying on
LED_BUILTIN.
COM3, and the user later confirmed COM3 was the correct port. [#20791782]upload_speed = 115200, monitor_speed = 115200, and upload_resetmethod = nodemcu. [#20795458]ESP8266EX with a 26MHz crystal and wrote 265648 bytes in 17.1 seconds. [#20800473]115200 8-N-1, yet reset output still appeared as garbage before the final diagnosis. [#20800431]GPIO2 (pin = 2). [#20800674]esptool.py v3.0 opened COM3, kept retrying Connecting........, and never received a valid response header from the ESP8266. In this thread, the board compiled correctly, but the upload handshake failed before flashing started, so the problem was connection or reset behavior, not C++ compilation. [#20790596]GPIO0 to ground before starting the flash process. The helper explicitly asked for that condition and showed a reference wiring image; the thread supports GPIO0 -> GND for flashing but does not provide a full written pin-by-pin reset schematic. [#20791321]platform.ini in this case kept platform = espressif8266, board = esp01_1m, and framework = arduino, then added upload_speed = 115200, monitor_speed = 115200, and upload_resetmethod = nodemcu. Earlier additions such as monitor_dtr = 0 and monitor_rts = 0 were tried first, but the final proposal included the reset method change. [#20795458]Using manually specified: COM3. In this thread, COM3 was the valid port, and the log changed from auto-detection to a manual selection message, which is the key check that the override took effect. [#20795150]upload_speed = 115200, monitor_speed = 115200, and especially upload_resetmethod = nodemcu. That final platform.ini proposal was the turning point before the user reported that the program uploaded successfully instead of timing out waiting for the packet header. [#20795458]upload_resetmethod = nodemcu is a PlatformIO upload setting that changes how the board is reset into upload mode, using a NodeMCU-style reset sequence rather than leaving reset behavior implicit. In this thread, changing to that reset method, together with 115200 upload speed, moved the ESP-01S from repeated timeout failures to successful flashing. [#20795458]esptool.py started the serial connection but did not receive the expected first response packet from the ESP8266. "Packet header" is the initial serial-response marker that starts an ESP8266 upload exchange, confirming the chip is answering in the required communication state. In the thread, the tool stayed in repeated Connecting... attempts and then aborted. [#20790596]Generic ESP8266 Module, while PlatformIO used a separate esp01_1m environment and needed extra upload tuning. That difference changed defaults enough that Arduino uploads worked as a reference, but PlatformIO still needed explicit reset and speed settings before it would flash the same ESP-01S reliably. [#20800540]Chip is ESP8266EX, Crystal is 26MHz, wrote 265648 bytes, verified the hash, and ended with Hard resetting via RTS pin plus [SUCCESS] Took 27.44 seconds. Those lines confirm the flash completed. [#20800473]115200 8-N-1 suggested the expected sketch output was not actually running, even though the monitor speed matched the configured speed. After the user confirmed 115200 in both code and monitor, the next diagnosis was blunt: the program looked not to have loaded correctly after all. [#20800469]GPIO2 for Blink on this ESP-01S setup. The original code used LED_BUILTIN, but the LED still did not blink after a successful upload; once the pin was defined explicitly and then corrected to 2, the Blink test worked, showing that the built-in alias did not match this hardware/profile combination. [#20800674]GPIO2 made Blink work because that was the actual LED-controlled line on this board setup. The user first relied on LED_BUILTIN, saw no blink, then changed the code to an explicit pin and reported success with pin = 2, which removed the board-definition ambiguity. [#20800674]Generic ESP8266 Module, while PlatformIO used the esp01_1m environment name; that change affected behavior enough that PlatformIO needed extra upload settings and an explicit LED pin before the same simple Blink logic matched the hardware. [#20791782]SUCCESS. 2. Reset the module and watch the serial monitor at 115200. 3. Test Blink with an explicit LED pin, and on this setup use GPIO2. That exact last change turned a "successful" but non-blinking upload into a working result. [#20800674]