Not able to flash ESP-01m chip (ESPTOOL-580)

[besi]

Operating System

macOS 11.7 (20G817)

Esptool Version

4.4

Python Version

Python 3.10.7

Chip Description

Chip is ESP8285H16

Device Description

ESP-01m from AI Thinker
https://docs.ai-thinker.com/_media/esp8266/docs/esp-01m_product_specification_en.pdf

Hardware Configuration

Nothing functional attached.

• RST pulled high with 10k with a Reset button pulled to GND
• GPIO0 pulled to GND

How is Esptool Run

Terminal

Full Esptool Command Line that Was Run

esptool.py --port $PORT --baud 460800 write_flash --flash_size=detect 0 $IMAGE --flash_mode=dout

Esptool Output

esptool.py v4.4
Serial port /dev/cu.usbserial-FTFRNN7Y
Connecting...................
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285H16
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: 4c:eb:d6:0b:f5:22
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 2MB
Flash will be erased from 0x00000000 to 0x00091fff...
Flash params set to 0x0030
Compressed 596836 bytes to 397442...
Writing at 0x0000b99c... (12 %)Traceback (most recent call last):
  File "/usr/local/bin/esptool.py", line 34, in <module>
    esptool._main()
  File "/usr/local/lib/python3.10/site-packages/esptool/__init__.py", line 1026, in _main
    main()
  File "/usr/local/lib/python3.10/site-packages/esptool/__init__.py", line 826, in main
    operation_func(esp, args)
  File "/usr/local/lib/python3.10/site-packages/esptool/cmds.py", line 556, in write_flash
    esp.flash_defl_block(block, seq, timeout=timeout)
  File "/usr/local/lib/python3.10/site-packages/esptool/loader.py", line 109, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/esptool/loader.py", line 991, in flash_defl_block
    self.check_command(
  File "/usr/local/lib/python3.10/site-packages/esptool/loader.py", line 407, in check_command
    val, data = self.command(op, data, chk, timeout=timeout)
  File "/usr/local/lib/python3.10/site-packages/esptool/loader.py", line 376, in command
    p = self.read()
  File "/usr/local/lib/python3.10/site-packages/esptool/loader.py", line 308, in read
    return next(self._slip_reader)
StopIteration

More Information

The program seems stuck always at the same percentage (eg. 11% or 5% using the -z option)

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[besi]

I was able to finally flash the Micropython image, but I had to get into the code and adjust the timeouts.
I did at least double all the timeouts in loader.py.

Edit /usr/local/lib/python3.10/site-packages/esptool/loader.py:

DEFAULT_TIMEOUT = 10 #3  # timeout for most flash operations
START_FLASH_TIMEOUT = 40 #20  # timeout for starting flash (may perform erase)
CHIP_ERASE_TIMEOUT = 240 #120  # timeout for full chip erase
MAX_TIMEOUT = CHIP_ERASE_TIMEOUT * 4 #2  # longest any command can run
SYNC_TIMEOUT = 1 # 0.1  # timeout for syncing with bootloader
MD5_TIMEOUT_PER_MB = 16 #8  # timeout (per megabyte) for calculating md5sum
ERASE_REGION_TIMEOUT_PER_MB = 60 # 30  # timeout (per megabyte) for erasing a region
ERASE_WRITE_TIMEOUT_PER_MB = 80 # 40  # timeout (per megabyte) for erasing and writing data
MEM_END_ROM_TIMEOUT = 2 #0.05  # short timeout for ESP_MEM_END, as it may never respond
DEFAULT_SERIAL_WRITE_TIMEOUT = 20 #10  # timeout for serial port write
DEFAULT_CONNECT_ATTEMPTS = 14 #7  # default number of times to try connection
WRITE_BLOCK_ATTEMPTS = 6 #3  # number of times to try writing a data block

So it seems that some of the timeouts were too conservative for my case.

I wonder if there is a way to get the upload done without messing with the code in such a fashion.

[dobairoland]

Hi @besi. We plan to support user configuration files in the near future where similar hacks would be easier.

Is this a new chip or have you re-flashed it a lot? (I'm just asking out of curiosity because we've not got similar reports for 8285)

[besi]

@dobairoland Thanks for your comment. It was in fact the first flash of that device and also my first time flashing such a device.

[dobairoland]

By any chance, can you provide us the used image or give instructions how to build one?

[besi]

Of course I did use the ESP8266 2MB Image:

https://micropython.org/resources/firmware/esp8266-20220618-v1.19.1.bin

[dobairoland]

Thanks. We will try to reproduce.

[radimkarnis]

Hi @besi,
I tried to reproduce the issue. I used ESP8285H16 and flashed the image you provided. Flashing always worked, I even tried different USB-to-UART chips cp2102 and ch340. I am also on macOS (although it's 13.0.1).

Can you please tell us more about the serial adapter you are using? This information is missing, but I think it's critical for us to understand where this issue is coming from. Also - have you by any chance tried the same setup with a different host machine (maybe a PC)?

[besi]

I‘m using a TTL 3.3V FTDI adapter.

I‘m only connecting Tx, Rx, GND and 3.3V powering the circuit from the FTDI Adapter.

The 5V label is actually wrong and should say 3.3V

• Reset is pulled up with a resistor ans a button to GND
• GPIO0 is pulled to GND for flashing
• I had to press reset while esptool was looking for the board

Since I‘m using a recent macOS I had to add dedicated serial driver from one of the chinese chip vendors because the hardware stopped working due to Apple‘s Kernel Extension restrictions (I think).

FTDI_TTL_232
https://ftdichip.com/drivers/vcp-drivers/

Latest apple 11.x and 12.x
https://ftdichip.com/wp-content/uploads/2022/06/FTDIUSBSerialDextInstaller_1_5_0.dmg

[radimkarnis]

Thanks for sharing more.

There are two things to consider:

1. These Chinese adapters are notoriously unreliable, even when they use a chip from a reputable brand. The fact that you had to add the driver manually is also alarming.
2. If you are powering the circuit from the FTDI Adapter, you can run into problems with an insufficient power supply. Increasing the delays and number of attempts in this case maybe helps to ease power requirements.

[besi]

Thanks for your comments I might try to revert my changes made to the codebase and re-try while powering the ESP from another source.

Also if you can recommend a product that‘s superior to the FTDI-thing feel free to add that.

Please note that I did only conect TX and RX in terms of IO .
So last question for now: Do you think that wiring up RTS and CTS might help to mitigate some of the issues?

[Jason2866]

@besi We (project Tasmota) have always users with problems flashing esp device.
We recommend only Usb serial adapters with an onboard 3.3V LDO (power regulator)
For example the "golden" CH340

[besi]

@Jason2866 Thanks for pointing that out. I ordered two right away.

[IPTRAIN]

I am using this board:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html

Same issue with

MEM_END_ROM_TIMEOUT = 0.05 # short timeout for ESP_MEM_END, as it may never respond

When I have changed to MEM_END_ROM_TIMEOUT = 2.5 it worked ... BUT only after closing VS (PlatformIO) and reopening the Visual Code environment (some frustrating retries before ...!)!

For beginners as me it would be worth to mention the "Must of Restarting the IDE" ...!

Nevertheless - great Thanks!

[eried]

DEFAULT_TIMEOUT = 10 #3  # timeout for most flash operations
START_FLASH_TIMEOUT = 40 #20  # timeout for starting flash (may perform erase)
CHIP_ERASE_TIMEOUT = 240 #120  # timeout for full chip erase
MAX_TIMEOUT = CHIP_ERASE_TIMEOUT * 4 #2  # longest any command can run
SYNC_TIMEOUT = 1 # 0.1  # timeout for syncing with bootloader
MD5_TIMEOUT_PER_MB = 16 #8  # timeout (per megabyte) for calculating md5sum
ERASE_REGION_TIMEOUT_PER_MB = 60 # 30  # timeout (per megabyte) for erasing a region
ERASE_WRITE_TIMEOUT_PER_MB = 80 # 40  # timeout (per megabyte) for erasing and writing data
MEM_END_ROM_TIMEOUT = 2 #0.05  # short timeout for ESP_MEM_END, as it may never respond
DEFAULT_SERIAL_WRITE_TIMEOUT = 20 #10  # timeout for serial port write
DEFAULT_CONNECT_ATTEMPTS = 14 #7  # default number of times to try connection
WRITE_BLOCK_ATTEMPTS = 6 #3  # number of times to try writing a data block

Even with this settings some transfers still get stuck in the middle in my wt32-sc01 plus (with esp32s3). Strange that the esp webtools manage to program it normally :/

[tyeth]

DEFAULT_TIMEOUT = 10 #3  # timeout for most flash operations
START_FLASH_TIMEOUT = 40 #20  # timeout for starting flash (may perform erase)
CHIP_ERASE_TIMEOUT = 240 #120  # timeout for full chip erase
MAX_TIMEOUT = CHIP_ERASE_TIMEOUT * 4 #2  # longest any command can run
SYNC_TIMEOUT = 1 # 0.1  # timeout for syncing with bootloader
MD5_TIMEOUT_PER_MB = 16 #8  # timeout (per megabyte) for calculating md5sum
ERASE_REGION_TIMEOUT_PER_MB = 60 # 30  # timeout (per megabyte) for erasing a region
ERASE_WRITE_TIMEOUT_PER_MB = 80 # 40  # timeout (per megabyte) for erasing and writing data
MEM_END_ROM_TIMEOUT = 2 #0.05  # short timeout for ESP_MEM_END, as it may never respond
DEFAULT_SERIAL_WRITE_TIMEOUT = 20 #10  # timeout for serial port write
DEFAULT_CONNECT_ATTEMPTS = 14 #7  # default number of times to try connection
WRITE_BLOCK_ATTEMPTS = 6 #3  # number of times to try writing a data block

Even with this settings some transfers still get stuck in the middle in my wt32-sc01 plus (with esp32s3). Strange that the esp webtools manage to program it normally :/

I used to think webtools was better, but to be honest it was just quicker to retry that than firing off another platformIO upload attempt. In the end I modified my timeouts and have not had a problem since. My chip erases (esp32s3) take just over 30seconds for 16mb of flash so I didn't change from the 120s default.
My settings:

DEFAULT_TIMEOUT = 10  # timeout for most flash operations
START_FLASH_TIMEOUT = 30  # timeout for starting flash (may perform erase)
CHIP_ERASE_TIMEOUT = 120  # timeout for full chip erase
MAX_TIMEOUT = CHIP_ERASE_TIMEOUT * 4  # longest any command can run
SYNC_TIMEOUT = 1 # 0.1  # timeout for syncing with bootloader
MD5_TIMEOUT_PER_MB = 16  # timeout (per megabyte) for calculating md5sum
ERASE_REGION_TIMEOUT_PER_MB = 40  # timeout (per megabyte) for erasing a region
ERASE_WRITE_TIMEOUT_PER_MB = 50  # timeout (per megabyte) for erasing and writing data
MEM_END_ROM_TIMEOUT = 2.5  # short timeout for ESP_MEM_END, as it may never respond
DEFAULT_SERIAL_WRITE_TIMEOUT = 20  # timeout for serial port write
DEFAULT_CONNECT_ATTEMPTS = 10  # default number of times to try connection
WRITE_BLOCK_ATTEMPTS = 6  # number of times to try writing a data block

[radimkarnis]

Hi @tyeth, could you please try to pinpoint which of these timeouts does the trick for you?

By the way, we have implemented a way to configure these variables in esptool without having to dig into the code. You can now create a simple configuration file to override these default values. See https://docs.espressif.com/projects/esptool/en/latest/esp32/esptool/configuration-file.html for more information.

[tyeth]

Hi @tyeth, could you please try to pinpoint which of these timeouts does the trick for you?

By the way, we have implemented a way to configure these variables in esptool without having to dig into the code. You can now create a simple configuration file to override these default values. See https://docs.espressif.com/projects/esptool/en/latest/esp32/esptool/configuration-file.html for more information.

Ah brilliant, config available already! Not sure I can go through and narrow down such timings, other things to be getting on with I'm afraid, unless there's a paid job there ;) - I will have another go when it bites me again in the future. I'd be curious to know if the memory timings of 2.5 rather than 2.0 made a difference for @eried

One thing is I am running USBpcap, like wireshark, which I know is never recommended, not actively capturing but installed (v1.5.4.0). That's bound to cause micro-delays. I also only occasionally saw a problem with firmwares under 1-2mb as they transfer so fast.

[eried]

I'd be curious to know if the memory timings of 2.5 rather than 2.0 made a difference for @eried

Im using the new arduino ide now, upload never fails, never hangs on any %, just normal fast steady upload. I was going to investigate the differences between them to try to post a solution, but for now, I dont have time.