Closed rickitaly closed 4 years ago
rickitaly
commented
5 years ago 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"
rickitaly
commented
5 years ago 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!
komeemokkome
commented
5 years ago 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!"
rickitaly
commented
5 years ago 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!
lbernstone
commented
5 years ago You are making a connection, but failing to transmit properly. Try a different cable, or reduce the transfer speed.
rickitaly
commented
5 years ago 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
BaaridunNasr
commented
5 years ago @rickitaly Any chance you have some peripherals at GPIO pins 6 through 11?
rickitaly
commented
5 years ago Nothing connected :-(
BaaridunNasr
commented
5 years ago These are the configs I use for the same board. Are you using the same?
BaaridunNasr
commented
5 years ago @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.
rickitaly
commented
5 years ago 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.
ozanoner
commented
5 years ago @rickitaly have you managed to find a solution? I faced the same problem in our custom board.
rickitaly
commented
5 years ago No way I had to give up
ozanoner
commented
5 years ago Ok, thank you. I will share here if I can find a solution
ozanoner
commented
5 years ago @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.
lbernstone
commented
5 years ago @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.
ozanoner
commented
5 years ago Yes, that is what we have in our design. thank you.
Marvin1968
commented
5 years ago 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!
stock86c
commented
5 years ago i second Marvin1968. pulled the external connecting device, and the ESP32 was able to flash properly
stale[bot]
commented
4 years ago [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[bot]
commented
4 years ago [STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.
ryan4volts
commented
4 years ago (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.
usane1
commented
4 years ago Interesting. I have a NodeMCU 32S. Putting a capacitor between +IN and GND cause the same error. Just an observation.
ghost
commented
4 years ago A workaround works for me: change flashing baudrate to 115200 i.e.
idf.py -p /dev/ttyS3 flash -b 115200
PeterBorisenko
commented
3 years ago 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?
ryan4volts
commented
3 years ago 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.
PeterBorisenko
commented
3 years ago 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?
lbernstone
commented
3 years ago ryan4volts
commented
3 years ago 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.
ryan4volts
commented
3 years ago @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
lbernstone
commented
3 years ago 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
wiegleyj
commented
3 years ago I've got five prototype simple dev boards I created. Copy of existing schematics for dev boards. 1 flashes fine the other four do the same crap reported here. I have nothing connected to GPIO2 or GPIO12. All four identify as:
Chip is ESP32-D0WD (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 98:cd:ac:6d:1b:34 Uploading stub... Running stub... Stub running... Configuring flash size...
The one that works comes up with: Auto-detected Flash size: 4MB And you HAVE to press the boot button to get programming started even though the device has the RTS/DTS auto boot/reset circuit that is designed into the original dev boards.
The four that don't work do enter boot loader automatically but they report incorrectly: Auto-detected Flash size: 2MB
Baud rate changes don't work. My guess is this auto-programming circuit is garbage. I've seen lots of people complain troubles with the auto-boot circuit. My guess is now likely wrong. I removed the transistors now it doesn't enter boot load automatically just like the board that works but it still exhibits the exact same problem.
Why are four of these auto-detecting the wrong flash size?
ryan4volts
commented
3 years ago Depending on you variant chosen, there are more than just IO2 and IO12 that are required to either be pulled correctly or simply left disconnected in order to boot into factory app, to jump into bootloader, or some effect general programming if connected.
Which variant are you using? Do you have a link to, say, Digikey to identify which one it was?
wiegleyj
commented
3 years ago ESP32-WROOM-32D
And everything I’ve come across indicates that with nothing attached the default state of the internal pull-up and pull-down resistors on all pins should allow proper function for either standard running or operation of the boot loader when ID0 is low when the device exits reset.
Jeff Wiegley Department of Computer Science, Chair College of Engineering and Computer Science California State University Northridge
From: ryan4volts @.> Sent: Monday, May 31, 2021 11:03 PM To: espressif/arduino-esp32 @.> Cc: Wiegley, Jeffrey @.>; Comment @.> Subject: Re: [espressif/arduino-esp32] ESP32DEVKIT V1 - A fatal error occurred: Timed out waiting for packet content (#2415)
Depending on you variant chosen, there are more than just IO2 and IO12 that are required to either be pulled correctly or simply left disconnected in order to boot into factory app, to jump into bootloader, or some effect general programming if connected.
Which variant are you using? Do you have a link to, say, Digikey to identify which one it was?
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_espressif_arduino-2Desp32_issues_2415-23issuecomment-2D851843389&d=DwMCaQ&c=Oo8bPJf7k7r_cPTz1JF7vEiFxvFRfQtp-j14fFwh71U&r=T1ybgm4nItaI5o0vJf9K6Q&m=wy9zYVOE0-pSWDEVTvdcB6U-BfaW0PqBJqoEUWtmOPk&s=_av0uxNUSxYSSuAoEI_6oA4T2TZhvcxyqDl0bGFzMYQ&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ACN5Q6JMMLIS57XITGR7BDTTQRZ2NANCNFSM4GT47VLQ&d=DwMCaQ&c=Oo8bPJf7k7r_cPTz1JF7vEiFxvFRfQtp-j14fFwh71U&r=T1ybgm4nItaI5o0vJf9K6Q&m=wy9zYVOE0-pSWDEVTvdcB6U-BfaW0PqBJqoEUWtmOPk&s=ivVD-h4l83FJBnQeP0z7eL7oXA13fWs3rTqSD33SlnY&e=.
ryan4volts
commented
3 years ago The schematic for the variant shows the following pins should not be touched for flash reasons:
Then these two must be pulled low to enter the bootloader:
Then this IO has special conditions:
Something that happened to me once, I had a capacitor to ground on one of the IOs. Despite not having any pullups, the capacitance on it for some reason made it so it either couldn't boot, or couldn't program. It was a long time ago in a galaxy far far away, so I forgot which one it was :) Just useful to note.
JompasGit
commented
2 years ago I had the same problem. "Timed out waiting for packet content". I had two sensors connected to the ESP32 board (DHT 22 and DS18B20) but when I disconnected the power line to the sensors, it worked fine to upload. All the best. vattenfelsbrytare.com
AllTracking
commented
2 years ago Had the same issue, searching for the pinout, i found that what is written on the pin as GND(besides the 5v pin) is not supposed to be used. instead, use the other GND pins on the board and the issue was solved.
tenchirocom
commented
2 years ago Disconnecting GP12 fixed it for me. Thank you. Wouldn't have thought of that on my own.
Ribisl
commented
2 years ago @AllTracking, thank you that solved my problem, do you have a clue why it behaves like that?
PragunJaswal
commented
1 year ago I had the same problem. "Timed out waiting for packet content". I had two sensors connected to the ESP32 board (DHT 22 and DS18B20) but when I disconnected the power line to the sensors, it worked fine to upload. All the best. vattenfelsbrytare.com
It works for me thanks
meesokim
commented
1 year ago Sometimes, it is related to upload speed. I can upload it by changing communication speed. My board is a TTGO VGA32.
opsquid
commented
1 year ago A workaround works for me: change flashing baudrate to 115200 i.e.
idf.py -p /dev/ttyS3 flash -b 115200
This was the solution for me. Thank you.
kabongsteve
commented
5 months ago I found the issue was not enough power supplied to the chip.
Switching to a 5V supply to the 5v rail, instead of the 3.3V to the programming header resolved the issue for me
Hardware:
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
Description:
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!
Debug Messages: