I have constantly been getting this error while trying to upload a sketch on Wemos D1 Mini R1 & R2 type board.

A fatal esptool.py error occurred: Write timeout

I've recently updated my Arduino IDE, so I assumed that it might be due to a bad installation. But after reinstalling everything including the Board Manager lib for ESP, Arduino IDE itself nothing worked. When I click on the Board Info, it displays an error "Native serial port, can't obtain info".

I've also tried different type of ESP boards (e.g. NodeMCU) but for all boards the problem is same. When I plug an Arduino to the same USB Port, it auto-detect the board, but when I plug-in the ESP boards, it doesn't recognize the boards automatically. So my guess is it has something to do with the CH34X driver. However I have tried reinstalling few versions of the driver from authentic sources, but nothing made an impact.

Any help is appreciated.

Following is the full trace of log getting printed:

. Variables and constants in RAM (global, static), used 28104 / 80192 bytes (35%)
╠══ DATA     1496     initialized variables
╠══ RODATA   920      constants       
╚══ BSS      25688    zeroed variables
. Instruction RAM (IRAM_ATTR, ICACHE_RAM_ATTR), used 59667 / 65536 bytes (91%)
╠══ ICACHE   32768    reserved space for flash instruction cache
╚══ IRAM     26899    code in IRAM    
. Code in flash (default, ICACHE_FLASH_ATTR), used 232148 / 1048576 bytes (22%)
╚══ IROM     232148   code in flash   
esptool.py v3.0
Serial port COM8

A fatal esptool.py error occurred: Write timeout

Following is the IDE Settings while uploading:


3 Answers 3


I've run into this a bunch recently, and typically, but not always, the cause is that I was using a GPIO pin that was reserved and couldn't be used during boot up. It's surprising how many of the pins cannot be used.

Check out this chart I found and saved, unfortunately I do not know the source, but I have found it to be very accurate, and I reference it a lot:

take a look at this graph I found

  • For my case, a simple Blink program is not getting uploaded. I am not sure how failure to upload a program to the board can be caused by a reversed GPIO pin. Do you mean the board is damaged and it can't be used? I do not see an solution or conclusion to the problem, in your answer. Still need help.
    – sribasu
    Jun 3 at 0:06

I had the same problem.

My solution:

Program for blinking led ESP8266MOD (cheap Chinese esp8266mod module)

I used Arduino IDE 2.1.0

info from https://vimalb.github.io/IoT-ESP8266-Starter/Lesson_01/lesson.html

Connect resistor 220 Ohm and LED in serial. Connect resistor on D8 and the LED

on G (Ground). I used a breadboard and connect 5V pin on the esp board and

the pin G on the esp board to the Red en Bleu line on mij breadbord.

Write the program.

// Base ESP8266

#include <ESP8266WiFi.h>



#define LED 15    // this is pin D8 on the board

#define BUTTON 4

void setup() {

  // Initialize the serial port


  // Configure light sensor pin as an input


  // Configure LED pin as an output

  pinMode(LED, OUTPUT);

  // Configure BUTTON pin as an input with a pullup



void loop() {

  // Turn the LED on (HIGH is the voltage level)

  digitalWrite(LED, HIGH);

  // Wait for 1000 milliseconds


  // Turn the LED off by making the voltage LOW

  digitalWrite(LED, LOW);

  // Wait another 1000 milliseconds


  // Send a message over the serial port

  Serial.println("Finished loop");


Compile the program.

If Fault check the program.

Go to Tools -> Port (I used com6)

Push the reset button on the espboard and keep it.

Connect the usb-cable on the espboard.

Release the reset button.

Besure everthing is connect.

Upload the program by using the upload button arduino IDE.

Start the serial monitor and check text "Finished loop" every 2 seconds.

Maybe this will help


The "most common reason" mentioned in this answer was actually the problem I had. Unfortunately I was using a charge only cable even though the cable package clearly said it was a data-cable. At times, these cheap electronics products confuses us a lot and we often miss to critically scrutinize the most obvious problems. As described in this Adafruit tutorial this problem seems to be a very common one.

Not the answer you're looking for? Browse other questions tagged or ask your own question.