A fatal error occurred: Timed out waiting for packet content - problem after writing to SPIFFS memory of ESP32 (ESPTOOL-403) #263
Comments
|
Hi @Electromania , Thanks for reporting this. You're seeing some very unusual behaviour, different to other reports despite the similar final error. These two messages:
Indicate some kind of low-level hardware problem. The chip is reporting an invalid/corrupt silicon revision, and then it's failing to talk to the attached flash chip at all.
No, this is a lower level problem than anything related to SPIFFS. Is it possible the ESP32 was running outside of its specified temperature or voltage range for a period? (for example more than 3.3V applied to the chip, or running in extreme heat?) Can you please run the following two commands (you'll find espefuse.py in the components/esptool_py/esptool directory) and post the output? Thanks, Angus |
|
(BTW, I deleted your duplicate post on #226 as I think this is a different issue - they're getting a failure to Connect and in your case it's connecting fine and then falling apart later. For future reference, please don't post duplicate information in multiple places - it can be very confusing for us.) |
|
Thanks for quick reply and removing other post. I had posted there first and then realized, as you mentioned, it had slightly different problem. But now i have new problem, i am getting following error for SPIFFS_Test program for all boards i have. i also tried ESP32-pico sent by espressif. i can upload all sketches and those are running fine. The SPIFFS_Test.ino gives me following message on serial port, and attached images are screenshots of commands you suggested. i have just erased mac address. (since this is slightly different issue than original , if you want i can make new thread. error i am getting is. .............................................. rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) espefuse.py --port COMx summary
espefuse.py --port COMx dump thanks |
|
Sorry i forgot to answer your other questions.
the previous night i had kept it running in same conditions, but i was sampling only max 100-200 data points. this time accidently it was sampling every few seconds, so it must have taken few thousand data points.
|
|
I am having a similar problem. I have two Wemos ESP32 Pro boards. Both of these boards use to flash and work properly. Now neither board will flash. Both boards produce the following log on the monitor during flashing. The problem seemed to start after I wrote a small program to set all GPIO to inputs (except the flash related GPIO). When one board quit flashing, I moved to my other Wemos board. After that I could no longer get either Wemos board to flash. I can successfully flash every other manufacturers board I have tested using any of my programs. Because both boards are messed up, I wonder if I have set something wrong in menuconfig. Here are some of my settings: Serial Flasher: baud rate: 115200, Flash SPI Mode: DIO, Flash SPI speed: 40 MHz, Flash Size: 4 MB, Detect flash size I think this is the last Wemos boards I will used. I already don't like it because their XTAL Freq is non- standard. That caused me a lot of lost time. Now the boards appear to be damaging the processor. I ran the two espefuse commands you wanted. Here are my results |
|
Hi @csann, Thanks for posting all these details. Your problem looks a little different, because the chip identifier (ESP32D0WDQ6) is read successfully (this is stored in efuse) but then esptool.py fails to talk to the flash chip. The efuse values you have look normal for a factory fresh chip.[*] This is probably a hardware failure (dead flash chip on the board, or a bad soldering joint), unless there is something connected to the WeMos board which might be interfering with the SPI flash pins in some way. Angus [*] The reason I asked for an efuse dump when the chip identifier was invalid in @Electromania's case is because efuse settings can also change the SPI flash pin assignments, so if some efuses have been set somehow to corrupt the chip identifier then they may also have been set in a way which changes the SPI flash pin configuration to use the wrong pins. |
|
Thanks csann and projectgus, i have been scanning through several forums and blogs, this kind of error - irrespective of cause, seems quite often by espxxx users. i am not sure if this is getting into hardware or firmware issue. but needs to be addressed quickly so that the makers, enthusiasts and professional OEMs do not end up with product that - literally needs to be scrapped because of this issue. because, i had to completely remove the wemos board and replace with new one - and finally again stuck with SPIFFS not working so far. |
|
Hi @projectgus and @Electromania I believe this problem is related to some design problem with the Wemos board. I am experimenting with several different manufacturers boards and I have this problem only with Wemos. And I have I will all of my Wemos boards (two of them). I won't buy another one. Plus the Wemos board is totally undocumented...no pictures or schematics on their web site. From looking at their web site you wouldn't even know the board exists. Angus mentioned it might be something attached to the SPI flash pins. I doubt it. One of my failed boards has no IO connected to it. Never has. Hmmmm....just thought of something. I did use that board for my IO test. In my IO test I looped from GPIO0 to GPIO39, setting the GPIO to input and setting pull-up and pull-down. I first set all GPIO to pull-up, then I grounded the GPIO to detect a 0. Then I set all GPIO to pull-down and I put 3V3 on each pin to detect a 1. I did not put GND or 3V3 on the six SPI pins, but I did configure them as inputs and set PU and PD resistors. Could this fry the SPI? Note: I did this to another manufacturers board and it still works fine. Could the other boards have a more robust design that protects against what I did? I wish the manufacturers would not even bring out the 6 SPI flash pins to the edge connectors. Why do they do this? If the pins are unusable for anything, why bring them out? The same goes with GPIO pins 0, 1, 2, and 3. As far as I can tell, these pins should not be used for general purpose GPIO. If you use 0 or 2 I understand you risk screwing up the boot of the board. (I suppose you could use them for output after the board is booted. And I suppose you could use them for input, but you better not have anything connected before the processor boots.) If you use 1 or 3, you screw up the UART and you cannot monitor the board. (I suppose there is a use case where you don't need to monitor the board....probably after the board goes into production....if you trust never being able to monitor a board once the design has gone into production and the UART pins are used as GPIO.) Clark |
|
Hi @Electromania, Sorry, I wrote a reply to you yesterday but it must have not sent. My apologies for that, will reply in a second.
We need to improve the esptool.py error handling because "A fatal occured: Timed out waiting for packet content" is the last line of output for a lot of totally different errors. 99% of the time this is problems with the serial interface or power poorly supplied to the module in a DIY way, and can be rectified without replacing the chip. It's the output that comes before this error that determines what's actually going wrong. I realise this is misleading and we need to improve it. The issue @Electromania saw, with an invalid ESP32 chip ID in the log output, I have literally never seen reported before. If I google for the first part of the error message then the only other link I find is to the duplicate forum post. So this seems like something quite unique so far. Issues with invalid flash chips (FlashID=0xffffff, SizeID=0xff) do happen on occasion. Quite often a SPI flash pin of the ESP chip has been connected to some other device and removing this connection fixes it. Sometimes the flash chip is faulty. Unfortunately we're not responsible for sourcing board manufacturer's flash chips, this is a third party part. Going back to yesterday''s post:
OK, good to hear you found a way to keep working. The efuse output from the new board looks normal, but this makes sense as it's programming correctly.
SPIFFS is fundamentally a software construct, a way of taking a region of the flash and using it as a filesystem for data storage. esptool.py only sees the ESP32's flash as a range of bytes it can read/erase/write. Putting things like a partition table and a SPIFFS partition onto this happens entirely in software, in this case it's done by esp32-arduino. esptool.py doesn't know anything about SPIFFS, apart from seeing it as some bytes written to some range of addresses in the flash. The Did you flash an initial SPIFFS image to the ESP32's flash? If you didn't, it's failing because it didn't find an existing SPIFFS filesystem formatted in the SPIFFS partition. One solution is to call More details can be found here: espressif/arduino-esp32#638
Just like a filesystem on a hard disk partition, there is a certain amount of space assigned for a SPIFFS partition and it will fill up if you keep writing to it. I believe the default Arduino-ESP32 partition table gives a 1.5MB SPIFFS partition. |
|
Hi @csann,
No, it should be fine (at worst, needs a power cycle to come good). My guess is bad soldering or a bad chip. If you have access to a hot air rework station, you might be able to sort it out. Otherwise asking the seller you bought it from for a refund/replacement is probably easiest.
This is a good question. There are circumstances under which you can use most of these pins, with varying degrees of complexity. But at minimum it'd be good if they were marked "handle with care", I agree.
There are a lot of "Wemos" clones that aren't actually made by Wemos, which might also explain the poor quality. This is the Wemos "Pro" ESP32 board I'm aware of, Lolin32 Pro: https://wiki.wemos.cc/products:lolin32:lolin32_pro |
|
thanks a lot for detailed reply. ** "So this seems like something quite unique so far." ** i have tried to test your suggestions with my 'damaged' board with external usb-ttl adapter, unfortunately now it only shows following thing... seems now board is completely dead. i tested with several different ways - esp programming module, us-uart adapters, conneting rx tx of other board etc. none works anymore. ** GOOD NEWS - thanks for your suggestion - SPIFFS.begin(true); worked. now i can read and write to other esp32 board. if you want this issue could be closed now. but since original issue remains lingering - i.e. cause of failure of first board; may be we can keep it open until someone finds similar problem or a solution. i leave it to you. ** "I believe the default Arduino-ESP32 partition table gives a 1.5MB SPIFFS partition." thanks for help... at least i can now continue with project. and as i get time, i will keep playing with old damaged board, just to know what might have gone wrong there. |
This is possible. Do you know how low the battery voltage got? A protected Lithium cell should only go as low as ~3.0V before it cuts off entirely. This is safe and within specifications for the ESP32, but an unprotected cell can discharge much further (to the point where the cell itself may be damaged and unsafe to recharge, as well). Most of the rectangular lithium batteries with JST-style connectors integrate a small protection circuit in-battery. Most 18650 cells don't integrate anything unless specifically marketed as "protected". I don't know if any Wemos boards have an onboard protection chip. The Arduino configuration sets the brownout detector at the lowest value, ~2.43V. So if the voltage got this low it may have started triggering and ended up in a reset loop. If an unprotected battery continued to drain then this may push it below the rated safe minimum voltage for the ESP32, and this could possibly have corrupted the internal efuses (I don't know). I'll check with my hardware colleagues about this possibility.
Do you mean ESP-IDF rather than esptool? esptool doesn't know anything about partitions or SPIFFS. It just reads & writes bytes from the raw flash. Partition tables in IDF are documented here: http://esp-idf.readthedocs.io/en/latest/api-guides/partition-tables.html The default partition table layout file for Arduino is here:
You can add a second SPI flash chip on different pins, although I don't think either ESP-IDF or Arduino have existing software support for mounting SPIFFS on such a chip. Probably the easiest thing you can do is to find a board with 16MB of flash (or swap flash chips on your board) and then change the partition table to expand the SPIFFS partition to use the additional 12MB. The other option is to add an SD card slot, which gives you at least an order of magnitude more storage very cheaply. If you have more questions about SPIFFS or data storage, the best place to ask is the esp32.com forum - either the Arduino subforum or the SDK subforum depending on if you want to use Arduino or not. |
|
Oops, I missed a part:
If you want to keep debugging this, start with the troubleshooting steps here: https://github.com/espressif/esptool/#bootloader-wont-respond |
|
Hello projectgus, i have the same problem like Electromania. esptool.py v2.1 A fatal error occurred: Timed out waiting for packet header In the serial monitor i am getting this message after i press the EN button: rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) After i press the BOOT button i get the following message: rst:0x10 For espefuse.py --port COMx summary : espefuse.py v2.3.1 Config fuses: Calibration fuses: Efuse fuses: Security fuses: Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V). For espefuse.py --port COMx dump : espefuse.py v2.3.1 I ran this board two times on brand new 18650 batteries then one time on a battery i got from a laptop. |
|
(Edit: Removed my original comment which was wrong.) It looks like your efuses have corrupted in a similar way to @Electromania's. Is it possible the ESP32 was running on batteries which significantly discharged to a very low operating voltage? Any other unusual operating conditions? What software environment were you using for the code you successfully programmed? |
|
Yes you are right, the ESP32 was running on a battery and discharged completely. Thank you for your response. |
|
Hi projectgus, Chip is ESP32D0WDQ6 (revision 1) Writing at 0x0000e000... (100 %) A fatal error occurred: Timed out waiting for packet header I am running Arduino 1.8.5 on a MAC OS x 10.13. the board is connected to the computer for power. It is a board I purchased from Xiuxin on Amazon. The board is running a sketch that reads a DHT22 sensor, sends data out on the USB port, and runs a WiFi server with Temperature data and links to turn on and off two outputs. The sketch has a bug so that the board will hang in a "while" statement after the temperature goes out of equality and an output 2 goes low. The sketch would upload fine before I added the bug! ;^)
I have a Parallels Windows VM and I am using ESPFlashDownloadTool_v3.6.4 to try to erase the flash drive with empty 1MB .bin files. This program fails while communicating with esp32 board also. |
|
@cslehel Unfortunately there's no way to un-set efuses once they've become set. I've been talking to my colleagues about the root cause of this issue, but the best workaround is to use a "protected" lithium battery type where the protection circuit automatically cuts the battery off if it discharges to 3.0V. This is also important for safety, as recharging a lithium battery which has been over-discharged can cause it to swell up or explode. Hi @Salty-Doug , Thanks for supplying these details. I'm not sure why you're seeing "SyntaxError" from espefuse.py, as this usually indicates a Python syntax error (in the code) rather than anything with the command line. However esptool.py is tested on both Python 2 & 3 so I'm not quite sure what's going on there. Is there any other output printed when you run espefuse.py? It seems like the issue you're seeing may be different, as you say you're not running on battery. Is it possible something is connected to or shorting GPIOs 6-11? (These GPIOs are connected to the onboard SPI flash pins.) |
|
Thank you for the answer projectgus. |
|
Thanks for the reply Angus. |
|
@Salty-Doug That's quite strange. GPIO2 needs to be low on reset (it's a strapping pin, see datasheet Section 2.4) but I'm not aware of any problems like this which would case it to fail during flashing. I'm glad you resolved the issue, though. |
|
I'm having similar issues with a TTGO board. For what it's worth, it has "fixed" itself a couple of times, I'm presuming either due to emptying of the internal battery and coming out of a reset loop or conversely, charging of the battery and getting stable power. |
|
I had same issues with wemos lolin32 board with integrated OLED display, but I could finally flash it after disconnecting all sensors from the board. |
|
For others with this same problem: after swapping through about 8 different USB cables (no help), putting in a large electrolytic between Vcc and Gnd (no help), disconnecting everything else on the breadboard around the ESP 32 (no help), I finally removed the ESP32 from the breadboard entirely, so that it was hooked only to the USB cable during programming. That seems to have done the trick, and better still, now that I've successfully downloaded one program, I can download more with the ESP32 actually plugged INTO the breadboard. This worked both on an NodeMCU ESP-32S AND on a Geekworm ESP32 WROVER IPEX, neither of which worked when plugged into the breadboard; that suggests to me that this might be a general solution. Best of luck to one and all. |
|
Confirmed. @spike7638 I have M5Stack core, and had the same (in common) error I have had protoboard 2.54 with voltage step down regulator that was not powered (board powered 5v using usb, and level shifters module , and when i have removed the protoboard, the M5stack could be flashed without problem over usb. later i'll check if there is a problem with ota also when externals are connected and i'll post here. |
|
Closing as this issue went in a variety of directions but seemed like they were all hardware issues (connections to the board, problems resolved by swapping modules, etc.) If anyone still experiences issues of this kind, please open a new issue with full details. |
|
rst:0x10 (RTCWDT_RTC_RESET),boot:0x37 (SPI_FAST_FLASH_BOOT) |
|
@elennaro This error indicates that something other than a valid bootloader was found at flash offset 0x1000: https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#early-flash-read-error If you have more questions, please open a new issue with more details. |
|
Thank you, @projectgus . |
|
Good to hear. In case it's unclear, this is probably the GPIO12 pin mentioned at the link (causing the flash to start up at 1.8V and brown out.) |
|
Hello, hey friend I figured out the solution. http://arduinoamuete.blogspot.com/2015/12/reiniciar-nodemcu-en-windows.html on this link you can see the solve problem it worked for me, just remember while is started flash you need to press down flash button and keep it down until the program finish. and then your board is gonna work |
Hey! FYI I had the same issue as @csann, but with a brand new board. The chip was showing up but the uploading failed with the same errors. My problem was that the pin next to the VIN is marked as CND on my board, which I tought would be a GND with a printing error. When I connected an external CAN Transciever chip to the VIN and "CND" (which is just GPIO11), the MCU were not able to boot, but I did not see that, because it did not came with a blink example code uploaded, and I tried to upload my code from the beginning. Thanks to your comment @projectgus, I realized that I haven't even tried to upload the code with everything disconnected, and boom. It worked, thus I could find the issue with the mislabeled pin. So just as a reminder, try to remove every external device from your MCU if you have issues while programming it, folks :) Cheers, |
Ah yes, this pin is |
|
spike7638 "I finally removed the ESP32 from the breadboard entirely, so that it was hooked only to the USB cable during programming. That seems to have done the trick, and better still, now that I've successfully downloaded one program" - YESSS!!! |
I was implied by this info, I can program an ESP32 DevKit DOIT last week, but it didn't work this time and the error prompts were the same with uppers, what I have changed was just add a DHT11 sensor, at first, I removed the data line (I connected it to G15 before), the error was still there, then I disconnected VCC line, and it was OK. |
github-actions
bot
changed the title
I noticed there are several threads related to this problem, but i am creating new because this is the problem i am encountering after writing to SPIFFS memory of ESP32.
After writing to SPIFFS memory for long time (overnight), the problem of . I had perfectly working wemos board. i kept it running overnight (accidentally) with measurement data being stored into SPIFFS memory. In the morning, i noticed my OLED display was Frozen - i.e. no values were changing. I restarted the ESP32 and then......... everytime i try to upload any sketch i get errors shown at the end of this post.
I did tons of google searchers and forums, tried all options mentioned everywhere. Tried Arduino IDE, Eclipse Oxygen, platformIO. Tried to skip onboard USB-Serial IC of Wemos and use external USB-Serial adapter. Pressed Boot, Enable buttons, reduced baud rate, changed USB ports, updated drivers, etc. Nothing help and problem remains same. My PC is windows 8.1 64bit. Arduino ide 1.8.1, Eclipse Oxygen, esptool.py v2.1.
But when i program my other ESP32 bare boards or dev boards all are working fine, so i am sure i have not messed up with my PC settings etc.
Could it be that since i was writing to SPIFFS memory (unfortunately in infinite loop - accidentally) it might have just filled up whole memory ? if that is so, there should be some way of Clearing this memory ??? because, if someone does this accidentally again , then each time the ESP32 board will be useless.
Is the flash memory separate from esp32 chip ? can only that be replaced with new IC ?
Is it a hardware issue or software issue ?
------------------------------Following is error from Arduino IDE----------------------
Sketch uses 184176 bytes (14%) of program storage space. Maximum is 1310720 bytes.
Global variables use 11040 bytes (3%) of dynamic memory, leaving 283872 bytes for local variables. Maximum is 294912 bytes.
C:\Users\xxx\Documents\Arduino\hardware\espressif\esp32/tools/esptool.exe --chip esp32 --port COM3 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 C:\Users\xxx\Documents\Arduino\hardware\espressif\esp32/tools/partitions/boot_app0.bin 0x1000 C:\Users\xxx\Documents\Arduino\hardware\espressif\esp32/tools/sdk/bin/bootloader_qio_80m.bin 0x10000 C:\Users\xxx\AppData\Local\Temp\arduino_build_147733/SPIFFS_Read_Write_sample.ino.bin 0x8000 C:\Users\xxx\AppData\Local\Temp\arduino_build_147733/SPIFFS_Read_Write_sample.ino.partitions.bin
esptool.py v2.1
Connecting........_
Chip is unknown ESP32 (revision (unknown 0xe))
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 8192 bytes to 47...
A fatal error occurred: Timed out waiting for packet content
A fatal error occurred: Timed out waiting for packet content
-----------------------following error is from Eclipse-----------------
Flashing binaries to serial port COM3 (app at offset 0x10000)...
python /home/xxxx/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port "COM3" --baud 115200 --before "default_reset" --after "hard_reset" write_flash -z --flash_mode "dio" --flash_freq "40m" --flash_size detect 0x1000 /home/xxxx/esp/blink/build/bootloader/bootloader.bin 0x10000 /home/xxx/esp/blink/build/blink.bin 0x8000 /home/xxx/esp/blink/build/partitions_singleapp.bin
esptool.py v2.1-beta1
Connecting....
Chip is unknown ESP32 (revision (unknown 0xe))
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Flash params set to 0x0220
Compressed 17552 bytes to 10304...
make: *** [/home/xxxx/esp/esp-idf/components/esptool_py/Makefile.projbuild:53: flash] Error 2
A fatal error occurred: Timed out waiting for packet content
14:00:28 Build Finished (took 1m:19s.935ms)
The text was updated successfully, but these errors were encountered: