Repository navigation
esptool fails to write to ESP8266 with PUYA flash chip - The chip stopped responding (ESPTOOL-699) #890
Description
Operating System
Fedora38
Esptool Version
esptool-4.5.1-2.fc38.noarch
Python Version
https://packages.icinga.com/epel/8/release
Chip Description
ESP8266
Device Description
Wemos D1 Mini v4
Hardware Configuration
No response
How is Esptool Run
CLI
Full Esptool Command Line that Was Run
esptool write_flash 0x0 OTGW-firmware-0.10.2+50c3ed2.ino.bin 0x200000 OTGW-firmware-0.10.2+50c3ed2.littlefs.bin
Esptool Output
otgw]$ esptool write_flash 0x0 OTGW-firmware-0.10.2+50c3ed2.ino.bin 0x200000 OTGW-firmware-0.10.2+50c3ed2.littlefs.bin
esptool.py v4.5.1
Found 2 serial ports
Serial port /dev/ttyUSB1
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 7c:87:ce:be:25:e0
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00091fff...
Flash will be erased from 0x00200000 to 0x002f9fff...
Compressed 597664 bytes to 398357...
Wrote 597664 bytes (398357 compressed) at 0x00000000 in 48.1 seconds (effective 99.4 kbit/s)...
Hash of data verified.
Compressed 1024000 bytes to 75348...
Writing at 0x0025e8e9... (40 %)Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/esptool/__init__.py", line 1032, in _main
main()
File "/usr/lib/python3.11/site-packages/esptool/__init__.py", line 832, in main
operation_func(esp, args)
File "/usr/lib/python3.11/site-packages/esptool/cmds.py", line 586, in write_flash
esp.flash_defl_block(block, seq, timeout=timeout)
File "/usr/lib/python3.11/site-packages/esptool/loader.py", line 131, in inner
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/esptool/loader.py", line 1030, in flash_defl_block
self.check_command(
File "/usr/lib/python3.11/site-packages/esptool/loader.py", line 435, in check_command
val, data = self.command(op, data, chk, timeout=timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/esptool/loader.py", line 404, in command
p = self.read()
^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/esptool/loader.py", line 337, in read
return next(self._slip_reader)
^^^^^^^^^^^^^^^^^^^^^^^
StopIteration
A fatal error occurred: The chip stopped responding.More Information
I am able to always successfully flash the ino file, however, flashing the littlefs always failed.
I tried pretty much all baud rates from 9600 up to 115200, the errors would sometimes vary, including stating an "A serial exception error occurred: Write timeout".
This was tested with 2 v4 cards, multiple USB cables, multiple ports, and multiple machines.
I eventually got this to work (100% of the time), when including the --no-compress flag to the write_flash subcommand.
I've spoken to someone who's not had an issue writing to this hardware, however, they are using esptool v2.8
Though I've got this working, there was no apparent output to suggest --no-compress could resolve the issue, and as a new user this was a very painful experience.
Posting here so that.
a) the tooling can some how be updated to address this failure scenario.
b) some one searching for the same issue, may find this bug report, and the solution that worked for me.
Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide
- I confirm I have read the troubleshooting guide.
Activity
[-]esptool fails to write to ESP8266 chip - The chip stopped responding[/-][+]esptool fails to write to ESP8266 chip - The chip stopped responding (ESPTOOL-699)[/+]dobairoland commentedon Jun 19, 2023
Hi @wibbit. Are you able to flash it if you add
--no-compressafterwrite_flash?EDIT: I sorry, for some reason I haven't read everything.
radimkarnis commentedon Jun 19, 2023
Hi @wibbit,
I have tried reproducing this with several ESP8266's, esptool v4.5.1, and these bin files (please correct me if these binaries are not the right ones).
I was not able to reproduce the failure:
Could you please try the following:
radimkarnis commentedon Jun 19, 2023
Two more things to try:
You can create an
esptool.cfgfile in your current directory with this content:This custom configuration will then get loaded by esptool and will allow you to tune it for your environment. Can you please try increasing some of the timeouts and see if that helps?
wibbit commentedon Jun 19, 2023
I've not yet upgraded/downgraded esptool, however increasing the timeout from 3 to 30 allowed the process to finish without including --no-compress.
I'd increased in increments of 5, with 25 still failing.
I don't have another non-wemos based ESP8266 board to try with, but I can certainly go ahead and try out the other versions, probably Wednesday evening.
radimkarnis commentedon Jun 20, 2023
Thanks for the investigation!
Having to increase the timeout to 30s is a warning sign. None of the operations should take that much time. There might be an issue with the drivers of the ch340c USB-to-UART chip.
Please let me know if other devkits work for you!
wibbit commentedon Jun 20, 2023
Working with some people on a Discord channel, we think we have narrowed this down to the flash chip that is present.
The v3's (and good v4's) tested come with a T25S32 chip whereas the problematic v4's come with a puya branded chip, indicative throughput differences below.
Wrote 1032192 bytes at 0x00200000 in 62.8 seconds (131.5 kbit/s)...
v's
Wrote 1032192 bytes at 0x00200000 in 23.0 seconds (359.1 kbit/s)...
So, I assume the problem is that the CPU on the card is waiting on IO, and esptool eventually times out.
This is obviously an issue with the card, I'm not sure if there is anything in esptool that could be done to notify/warn a user, I'll leave this down to you lot to decide, as you obviously have a FAR more intimate understanding of the ecosystem then I do.
radimkarnis commentedon Jun 23, 2023
Nice investigation!
Could you please run
esptool.py flash_idon a faulty and a working unit and post the result?Maybe we could detect the faulty flash chip in esptool and at least provide a warning or a note.
Thank you!
wibbit commentedon Jun 26, 2023
Good chip
Manufacturer: 5e
Device: 4016
Detected flash size: 4MB
Problematic chip
Manufacturer: 85
Device: 6016
Detected flash size: 4MB
TD-er commentedon Jul 21, 2023
OMG... I really hoped those awfull Puya chips would be a one-time only disaster with their 1M chips.
But apparently they now also have 4M chips.
Do you know if those 4M units also need the 'PUYA' patch for ESP8266, which essentially does read the entire sector, alter it in memory and write it back, because those chips actually write what you tell them to write, instead of only turning a 1 into a 0 like normal flash chips do.
radimkarnis commentedon Jul 24, 2023
@wibbit I will try to get my hands on one of these devkits with Puya flash chips and investigate.
Thanks for your time! I will keep this open until then.
[-]esptool fails to write to ESP8266 chip - The chip stopped responding (ESPTOOL-699)[/-][+]esptool fails to write to ESP8266 with PUYA flash chip - The chip stopped responding (ESPTOOL-699)[/+]radimkarnis commentedon Aug 4, 2023
So I have ordered a batch of devkits, that were supposed to have the problematic PUYA flash chips. Unfortunately, they all arrived with the good stuff -
Manufacturer: 5e, Device: 4016.I guess the manufacturer knows about the issues and maybe started sourcing only the good flash chips.
wibbit commentedon Aug 5, 2023
Well that's not infuriating at all, i wonder if I can get a refund and a replacement product sent out.
Is there any thing I can do to provide additional information?
Sbsin-Ks commentedon Sep 13, 2023
Hi there Thank you so much for this hint. I stuck at the same problem and also tried every baud rate, different com ports and PCs. The option --no-compress made it work. I have uploaded the files with the actual esptool version v4.6.2.
@radimkarnis I have ordered multiple v4 boards with the problematic chip and I would like to conribute one chip to you if it helps others not wasting hours of playing try and error.
radimkarnis commentedon Oct 26, 2023
@Sbsin-Ks Thanks for the heads up and the
--no-compressworkaround!That would be appreciated, I didn't manage to get my hands on one of these. On the other hand, we didn't get any more reports of issues with these chips in the wild. Do you reckon adding a warning to esptool would be useful?
KrisBigK commentedon Jun 17, 2025
Hi everyone,
I have reproduced the issue that @wibbit was experiencing 2 years ago, and have already filed an issue report (#11462) in the arduino-esp32 repo. Below is a brief summary of what I have encountered. (more details could be found in the arduino-esp32 repo.)
I have built a board with ESP32-S3R2 and an external 4MB NOR flash manufactured by Zetta, a cheap flash supplier from China (similar to PUYA). The board have no issues on the hardware side, and even works at baud rates of up to 3,000,000 with the chip's internal USB Serial controller. I tested 3 Zetta flash chips from the same tape&reel, all of which have identical and slow write responses, especially when uploading with compression enabled. The longest response interval is around 5 seconds, causing esptool to time out, as the default flash timeout is only 3 seconds. When I upload with compression disabled, the upload would be successful, as the write progress of the flash is consistently reported back at ~1s intervals.
Esptool's output when failing to upload:
The issue could be characterized by looking the error log, with the traceback including
main,write_flash,inner,flash_defl_block,check_command,command,read, and reportingchip stopped respondingat the end.By searching with the keyword "stopped responding", there are 4 more previous issues that were closed (issue 842, 941, 966, 967). I did not read them in detail, but they may also point to the same issue.
When I use the config file to increase default timeout OR disable compression, the flash write would be consistently successful.
To accommodate the inexpensive flash available these days, the default 3 second flash timeout in esptool should be bumped up. Something like ~10s would make it compatible with my Zetta flash.
TD-er commentedon Jun 17, 2025
Oh no not again the whole PUYA saga, now on ESP32...
Please can you confirm whether those flash chips act exactly like those dreadful PUYA chips?
If so, then my suggestion would be to absolutely deny writing to it using esptool unless you enter a flag like
yes_i_know_i_will_regret_this_but_continue_writing_to_these_horrible_flash_chipsThe reason why those PUYA chips are so extremely horrible is that they read the flash block, update the changes and write the page back. (after erasing the page)
Any normal flash chip can only change a '1' into a '0' and not the other way around.
If you need to flip a bit back to '1', you need to erase the entire block.
This property is used in libraries like SPIFFS and I can't imagine it won't be used in others to implement some wear levelling administration.
Also what are the vendor IDs of these chips?
This so I can add huge warnings in my own software when encountering those...
KrisBigK commentedon Jun 18, 2025
My ZD25WQ32CEIGR has comparable write speeds with the one mentioned by @wibbit .
I tested the write speed of ZD25WQ32CEIGR with several example sketches in Arduino IDE (uploaded with compression disabled):
Sketch WireScan in Wire:
Wrote 360448 bytes at 0x00010000 in 24.5 seconds (117.8 kbit/s)...Sketch SPIFFS_Test in SPIFFS:
Wrote 360448 bytes at 0x00010000 in 25.4 seconds (113.4 kbit/s)...Sketch Beacon_Scanner in BLE:
Wrote 933888 bytes at 0x00010000 in 65.6 seconds (114.0 kbit/s)...Sketch BasicHttpsClient in HTTPClient:
Wrote 1015808 bytes at 0x00010000 in 71.0 seconds (114.5 kbit/s)...My Arduino IDE config:
The SPIFFS_Test example sketch ran just fine. Serial output of this sketch:
esptool.exe --port COM20 --baud 3000000 flash_idrun on my ZD25WQ32CEIGR:@TD-er Is there any other flaw with PUYA besides SPIFFS? The only functional problem with ZD25 I could find is that it has long write times.
On the hardware side, ZD25WQ32CEIGR is the perfect 4MB NOR flash, with an ultra small 2mm x 3mm package size, and supporting 1.65V to 3.6V VCC & 104MHz clock rate according to datasheet. With 0402 caps, I was able to design the core part of my ESP32-S3 board to have comparable dimensions with the much simpler ESP8266 module.
(left: esp8266 ESP-12F module with shield removed; right: core part of my ESP32-S3 board)
TD-er commentedon Jun 18, 2025
Not sure what other lib may rely on the write behavior of the other flash modules.
Also when testing SPIFFS, please make sure to try several file operations like file updates, adding files and removing so you are sure there have to be changes in the block allocation table.
Then also reboot and see if the file system is still how it should be.
Maybe also make a few calls to the garbage collector of SPIFFS before actually mounting it.
For the PUYA chip on ESP8266 there is a patch in the Arduino code to mimick the desired behavior so SPIFFS will work again.
However this patch is checking for a specific vendor ID and if your chip is having the same vendor ID, the patch may already be active (not sure if it is ported to ESP32-Arduino).
Block writes will probably be as fast as any other flash chip (or maybe even faster...), but small updates like in a 'block used table' for a file system may be quite a bit slower on these kind of flash chips. That is under the assumption they act like those PUYA chips.