Board: ESP32 DEVKIT V1
Core Installation/update date: new
IDE name: Arduino IDE
Flash Frequency: 40Mhz
PSRAM enabled: ?no?
Upload Speed: 115200
Computer OS: Windows 10
Hi, i just got a new ESP32 that i am trying to flash without success.
This is an ESP32 DEVKITV1 i got from here:
I am trying to upload exactly the same sketch from Arduino IDE which i upload without problems on an ESP32 NODEMCU.
In this case of course the only difference is the setting of the Board in Arduino IDE because i select DOIT ESP32 DEVKIT V1.
This is what i get, all the times. I tried any possible combination of the BOOT and EN pushbuttons but always the same! I read all the posts here but no way to solve!
Someone can help? Thank you!
```
^
Lo sketch usa 1621478 byte (98%) dello spazio disponibile per i programmi. Il massimo è 1638400 byte.
Le variabili globali usano 74860 byte (25%) di memoria dinamica, lasciando altri 220052 byte liberi per le variabili locali. Il massimo è 294912 byte.
esptool.py v2.3.1
Connecting........_
Chip is ESP32D0WDQ6 (revision (unknown 0xa))
Features: WiFi, BT, Dual Core, VRef calibration in efuse
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```
As additional information, i tried also without using local USB and directly connecting to VIN, GND, TX/RX, pulldown GPIO12 and push BOOT at connecting step, still i get "A fatal error occurred: Timed out waiting for packet content"
Looking at serial monitor in Arduino IDE, when i push the BOOT i change from message
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57
which is looping,
to this:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
so i guess i am correctly in boot mode! but still no way to proceed with upload!
I had a same problem with same board! Problem was that i was pulling GPIO2 to high. If GPIO2 is pulled high, it will not boot.
More info about esp32 pins: https://desire.giesecke.tk/index.php/2018/07/06/reserved-gpios/
From there you can read: "GPIO2 pin is used as a bootstrapping pin, and should be low to enter UART download mode. Make sure it is not pulled high by a peripheral device during boot or you will not be able to flash a firmware to the module!"
Hi, i tried also pulling GPIO2 to GND at boot and result is the same:
`esptool.py.exe erase_flash
esptool.py v2.6
Found 2 serial ports
Serial port COM3
Connecting......
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: xxxx
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
A fatal error occurred: Timed out waiting for packet content`
Any help? Thank you!
You are making a connection, but failing to transmit properly. Try a different cable, or reduce the transfer speed.
Thank you for your suggestion.
I could try with very short and good quality cable, on another port, on another pc, on another OS (ubuntu) but i always get this. Now i tried also lower speed (57600) but still "A fatal error occurred: Timed out waiting for packet content".
I have other esp32 (nodemcu) and i can flash in any way without issue.
Any other suggestion?
Thank you
@rickitaly Any chance you have some peripherals at GPIO pins 6 through 11?
Nothing connected :-(
These are the configs I use for the same board. Are you using the same?
@rickitaly Also, you only need to press Boot from the "------" (dashed line) to the "......" (dotted line) when it says esptool.py from what I observed while using the Arduino IDE exclusively.
yes settings are the same and i do press the boot at connecting
Da: Baaridun Nasr notifications@github.com
Inviato: giovedì 7 febbraio 2019 07:30
A: espressif/arduino-esp32
Cc: rickitaly; Mention
Oggetto: Re: [espressif/arduino-esp32] ESP32DEVKIT V1 - A fatal error occurred: Timed out waiting for packet content (#2415)
@rickitalyhttps://github.com/rickitaly Also, you only need to press Boot from the "------" (dashed line) to the "......" (dotted line) when it says esptool.py from what I observed while using the Arduino IDE exclusively.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/espressif/arduino-esp32/issues/2415#issuecomment-461302976, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AshnmQ0EA5hglaB9tpFo2LqGlFDZGBN_ks5vK8f0gaJpZM4afP1X.
@rickitaly have you managed to find a solution? I faced the same problem in our custom board.
No way I had to give up
Ok, thank you. I will share here if I can find a solution
@rickitaly In our case, the cause of the problem is GPIO12. it is pulled-up on our board which prevents flashing. See here for more info. Hope this helps for you too.
@ozanoner : If you are building your own system, you have different issue. Are you using a USB UART adapter? If so, you probably need to add a DTR/RTS crossover (http://loboris.eu/ESP32/ESP32_AutoReset.jpg). Otherwise, you can test your connection by running python esptool.py chip_id. If you get the chip info, but can't upload, make sure you hold gpio0 low during programming, and ground the EN pin for a moment before the upload.
Yes, that is what we have in our design. thank you.
Hope my experience helps: I had the same issue, but I also had 5v & gnd connected to an external device (spi). When I pulled those, I could upload. Check your monitor (crlt/shift/m) to see if the system keeps rebooting. Hope this helps!
i second Marvin1968. pulled the external connecting device, and the ESP32 was able to flash properly
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.
(Not sure if this comment will work).
I had the same issue. I was testing all available IOs and pulling them high to see what the gpio capabilites were during sleep. Needless to say, by pulling io2 High at boot, all future operations didn't work. Including using the boot and rst/en buttons. It would jump into the bootloader but wouldn't timeout at the packets.
I fixed it by power cycling the chip while holding down the boot pin, instead of doing a rst. This ensured the internal flash had never seen the 3.3v and triggered something like a ptc internally.
Interesting. I have a NodeMCU 32S. Putting a capacitor between +IN and GND cause the same error. Just an observation.
A workaround works for me: change flashing baudrate to 115200 i.e.
idf.py -p /dev/ttyS3 flash -b 115200
BTW I've just finished flashing 100 custom boards and have one case like this.
All readings is successful. But there is timeout on erase_flash and flash targets.
Selecting lower baudrate does not solve it.
Is there any possibility to recover chip or just replace it and send to rubbish bin?
One of the major reasons this could happens is from contention on IO2. If worst comes to worst, disconnect IO2 and check again. I _think_ pulling this IO to ground when flashing helps. Though yet to diagnose the issue myself.
One of the major reasons this could happens is from contention on IO2. If worst comes to worst, disconnect IO2 and check again. I _think_ pulling this IO to ground when flashing helps. Though yet to diagnose the issue myself.
Thanks for the clue, @ryan4volts
IO2 is connected to cathode of LED. So it has level slightly different than zero (3.3v - Vled). It should be about 1V.
What exactly IO2 do on the module?
I have also had contention on IO12, where the below happens and timesout. This is because I have the IO attached to an SPI CLK. Despite the micro being the master and the device being the slave, by default it holds the IO high. and reading through the link lbernstone provided, you can also see that this IO should not be driven high at bootup, else it will try to use 1v8 logic for internal flash. Thus it needs to be grounded on boot. This could potentially be your contention as well.
[2/4] Performing build step for 'bootloader'
ninja: no work to do.
Executing action: flash
Running esptool.py in directory c:\esp32app\build
Executing "C:\Users\Owner\AppData\Local\Programs\Python\Python38\python.exe C:\esp\esp-idf-v4.1\components/esptool_py/esptool/esptool.py -p COM24 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash @flash_project_args"...
esptool.py -p COM24 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x8000 partition_table/partition-table.bin 0xd000 ota_data_initial.bin 0x1000 bootloader/bootloader.bin 0x10000 Firmware.bin
esptool.py v2.9-dev
Serial port COM24
Connecting....
Chip is ESP32D0WDQ5 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 7c:9e:bd:cf:00:9c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Compressed 3072 bytes to 144...
A fatal error occurred: Timed out waiting for packet content
esptool.py failed with exit code 2
@ryan4volts : Unless you intend on desoldering flash and installing your own 1v8 chips, it is quite safe to burn the efuse controlling that behavior on gpio12.
@lbernstone Looking through the efuse settings, I cannot see the fuse you're refering to.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/efuse.html
Sorry, I post it so often I forget where I've posted it.
https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card#note-about-gpio12-esp32-only
Most helpful comment
I had a same problem with same board! Problem was that i was pulling GPIO2 to high. If GPIO2 is pulled high, it will not boot.
More info about esp32 pins: https://desire.giesecke.tk/index.php/2018/07/06/reserved-gpios/
From there you can read: "GPIO2 pin is used as a bootstrapping pin, and should be low to enter UART download mode. Make sure it is not pulled high by a peripheral device during boot or you will not be able to flash a firmware to the module!"