Page 1 of 1

manually entered download mode, saw "waiting for download", what is next?

Posted: Fri May 24, 2019 8:20 am
by adherent
Yes I know, there are tons of similar posts, and I do read them through, but cannot get my problem solved :(

So basically I made a custom board based on ESP32 WROOM module. Then I used "make monitor" to monitor the serial port output. By toggling the GPIO0 button I am able to see ESP32 is entering download mode with the indication: "waiting for download". (Even to this stage takes me several days, but its a another story 8-) )

The question is now what is supposed to be the next step? In the command window where this waiting message is, I cannot do anything, as the input from keyboard is blocked.

I did the following tries:

1. opened a new console, did "make flash" from there, was told that COM port cannot be opened. I tried also to use esptool.py directly, same result.

2. used esp32 download GUI tool, same error message: COMx port cannot be opened.

3. used arduino IDE to upload, same error. I tried also first to move ESP32 to download mode, then started uploading, no success.

So I think the problem is the monitoring console where I run make monitor is occupying the COM port, other console or tools cannot access the same port.

What should I do now? Any hint is appreciated. Thanks.

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Fri May 24, 2019 8:24 am
by WiFive
Close the monitor (Ctrl + ] )

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Fri May 24, 2019 9:14 am
by adherent
thanks for the quick reply, I did not try that....

I tried ctrl+c to terminate "make monitor" though, then make flash. It did not work.

So ctrl + ] will gracefully exit "make monitor" without breaking the download mode?

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Fri May 24, 2019 10:52 am
by WiFive
The only thing that should exit download mode is a chip reset.

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Fri May 24, 2019 5:41 pm
by adherent
WiFive wrote:
Fri May 24, 2019 10:52 am
The only thing that should exit download mode is a chip reset.
immediately after work I tried your suggestion. Still the same :(

Basically after I see the following:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x27 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2
))
waiting for download
I exit make monitor using ctrl + ]

Then I run:

Code: Select all

python ../esp/esp-idf/components/esptool_py/esptool/esptool.py -p com13 -b 115200 -c auto write_flash 0x10000 ./build/hello-world.bin
Still I got the same error:

Code: Select all

esptool.py v2.6-beta1
Serial port com13
Connecting........__
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:0a:c4:9c:42:a0
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 136960 bytes to 67442...

A fatal error occurred: Timed out waiting for packet content
I suspect the download mode is exited after ctrl + ], as when I did one more make monitor, I saw the again this constantly rebooting message:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57
What could be reason? Thanks.

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Fri May 24, 2019 5:51 pm
by WiFive
Your boot mode is 3f indicating you pulled up gpio12 which is setting the flash voltage to 1.8v and wroom32 uses 3.3v flash. Set the flash voltage via efuse or remove the pullup.

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Sat May 25, 2019 9:07 am
by adherent
WiFive wrote:
Fri May 24, 2019 5:51 pm
Your boot mode is 3f indicating you pulled up gpio12 which is setting the flash voltage to 1.8v and wroom32 uses 3.3v flash. Set the flash voltage via efuse or remove the pullup.
thanks for pointing it out.

I have also one wrover kit board on which flashing is working fine. While resetting I can see the following:

Code: Select all

rst:0xc (SW_CPU_RESET),boot:0x3e (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
So GPIO12 is also pulled up while resetting there. But flash chip can be correctly detected. When I manually entered download mode on wrover kit, I get this:

Code: Select all

rst:0x1 (POWERON_RESET),boot:0x26 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_FEO_V2))
waiting for download
Here GPIO12 is pulled up as well. (by the way the strapping value on my custom board while resetting is 0x27)

I checked the relevant efuse configuration, they all have default values:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/ W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/ W (0x0)

I do not really understand, why it is working on Wrover kit, but not on my custom board?

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Sat May 25, 2019 9:50 am
by WiFive
Wroom32/32D/32U uses 3.3v flash
Wrover/wrover-I uses 1.8v flash
Wrover-B/IB uses 3.3v flash
Pico-d4 uses 3.3v flash
D2WD uses 1.8v flash

Know your parts

Re: manually entered download mode, saw "waiting for download", what is next?

Posted: Sun May 26, 2019 3:02 pm
by adherent
WiFive wrote:
Sat May 25, 2019 9:50 am
Wroom32/32D/32U uses 3.3v flash
Wrover/wrover-I uses 1.8v flash
Wrover-B/IB uses 3.3v flash
Pico-d4 uses 3.3v flash
D2WD uses 1.8v flash

Know your parts
Many thanks for the hints. You are right, I need to think about if I should burn efuse to use 1.8v, as the burning action cannot be reverted :D