Which IDF version are you using? I have tried now and could successfully run idf.py flash with the latest master, i.e. v4.1-dev-1677-g30372f5a4f.

Try calling esptool.py directly, and if that also doesn't work, try adding --no-stub option.

One other thing, since you have created flash_image.bin, the idf.py flash step is not needed, since the application is already stored in the flash image...

from qemu.

i have the same problem, didn't work with --no-stub option either

from qemu.

@balamurali27 same question: which IDF version are you using? (git describe --tags to find it)

from qemu.

cloned it yesterday v4.1-dev-1572-g30372f5a4
It's the latest one, right?

from qemu.

I also had to specify a bios file for not giving -bios option when running qemu. I used the file esp32-r0-rom.bin in pc-bios/ directory for that.

from qemu.

Which IDF version are you using? I have tried now and could successfully run idf.py flash with the latest master, i.e. v4.1-dev-1677-g30372f5a4f.

Try calling esptool.py directly, and if that also doesn't work, try adding --no-stub option.

One other thing, since you have created flash_image.bin, the idf.py flash step is not needed, since the application is already stored in the flash image...

$ idf.py --version
ESP-IDF v4.1-dev-1572-g30372f5a4-dirty
$ git describe --tag
v4.1-dev-1572-g30372f5a4
$ git remote -vvv
origin	https://github.com/espressif/esp-idf.git (fetch)
origin	https://github.com/espressif/esp-idf.git (push)
$ git branch
* master

I would like to update the flash_image.bin with subsequent flash - or, how do I load an empty esp32 QEMU and flash it later?

No luck with --no-stub:

$ esptool.py -p socket://localhost:5555 -b 460800 --before default_reset --after hard_reset --no-stub --chip esp32 write_flash --flash_mode dout --flash_freq 40m --flash_size 2MB 0x8000 build/partition_table/partition-table.bin 0x1000 build/bootloader/bootloader.bin 0x10000 build/hello-world.bin 
esptool.py v2.9-dev
Serial port socket://localhost:5555
Connecting...
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core, Coding Scheme None
Crystal is 40MHz
MAC: 00:00:00:00:00:00
Changing baud rate to 460800
Changed.
Enabling default SPI flash mode...

A fatal error occurred: Timed out waiting for packet header

from qemu.

Could you please try again with the esp-develop-20191228 tag (just pushed to this repository)?

from qemu.

Hi @igrr thanks for the update but it failed with same error, could I have made any mistake in my steps below?

Build the QEMU

~ $ rm -rf espressif-qemu
~ $ git clone --recurse-submodules https://github.com/espressif/qemu.git espressif-qemu --branch esp-develop-20191228
~ $ cd espressif-qemu
~/espressif-qemu $ ./configure --target-list=xtensa-softmmu     --enable-debug --enable-sanitizers     --disable-strip --disable-user     --disable-capstone --disable-vnc     --disable-sdl --disable-gtk
~/espressif-qemu $ make -j8
~/espressif-qemu $ export QEMUBIN=`pwd`/xtensa-softmmu

Build the esp-idf and hello-world example

~ $ git clone https://github.com/espressif/esp-idf.git
~ $ cd esp-idf
~/esp-idf $ python -m pip install -r requirements.txt
~/esp-idf $ ./install.sh
~/esp-idf $ . ./export.sh
~/esp-idf $ cd examples/get-started/hello_world/
~/esp-idf/examples/get-started/hello_world $ idf.py menuconfig # change flash to DOUT
~/esp-idf/examples/get-started/hello_world $ idf.py build
~/esp-idf/examples/get-started/hello_world $ ./make-flash-img.sh hello-world flash_image.bin
# verify the image
~/esp-idf/examples/get-started/hello_world $ ${QEMUBIN}/qemu-system-xtensa -nographic -machine esp32 -serial mon:stdio -drive file=flash_image.bin,if=mtd,format=raw -echr 0x02

Emulate UART to TCP

~/esp-idf/examples/get-started/hello_world $ ${QEMUBIN}/qemu-system-xtensa -nographic -machine esp32 -serial mon:stdio -drive file=flash_image.bin,if=mtd,format=raw -echr 0x02 -global driver=esp32.gpio,property=strap_mode,value=0x0f -serial tcp::5555,server,nowait
Adding SPI flash device
==20722==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0xf (UART_BOOT(UART0))

Attempt to flash with esptool.py

Timed out connecting to socket:5555

~/esp-idf/examples/get-started/hello_world $ esptool.py -p socket://localhost:5555 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dout --flash_freq 40m --flash_size 2MB 0x8000 build/partition_table/partition-table.bin 0x1000 build/bootloader/bootloader.bin 0x10000 build/hello-world.bin
esptool.py v2.9-dev
Serial port socket://localhost:5555
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

Same error when flashing with --no-stub

~/esp-idf/examples/get-started/hello_world $ esptool.py -p socket://localhost:5555 -b 460800 --before default_reset --after hard_reset --no-stub --chip esp32 write_flash  --flash_mode dout --flash_freq 40m --flash_size 2MB 0x8000 build/partition_table/partition-table.bin 0x1000 build/bootloader/bootloader.bin 0x10000 build/hello-world.bin 
esptool.py v2.9-dev
Serial port socket://localhost:5555
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

Thanks!

from qemu.

Indeed I can reproduce the issue with the steps you have listed! The command you are using to start QEMU is slightly different from what is listed in the wiki. Please try this:

${QEMUBIN}/qemu-system-xtensa -nographic -machine esp32 -monitor stdio -drive file=flash_image.bin,if=mtd,format=raw -global driver=esp32.gpio,property=strap_mode,value=0x0f -serial tcp::5555,server,nowait

i.e. -monitor stdio instead of -serial mon:stdio. I think the latter merges serial with the monitor, and serial doesn't get redirected to the TCP port.

from qemu.

Thanks @igrr! Using -monitor stdio and the flash works using idf.py -p socket://localhost:5555 flash. In fact, without -monitor or -serial works for the flash.

However, after flash I couldn't see any output from the idf.py -p socket://localhost:5555 monitor. In another word, I am to start the qemu with -global driver=esp32.gpio,property=strap_mode,value=0x0f, there is no output with idf.py -p socket://localhost:5555 monitor.

On the other hand, if I am to use 0x1f for the strap_mode as according to https://github.com/espressif/qemu/blob/esp-develop/hw/xtensa/esp32.c#L179, I gets output from idf.py -p socket://localhost:5555 monitor, and an opcode from gdb.

So strap_mode=0x1f seems to load the image properly, but timed out in the flashing. Where else you think could be the cause?

screen -dmS qemu

~/esp-idf/examples/get-started/hello_world$ ${QEMUBIN}/qemu-system-xtensa -nographic -machine esp32 -drive file=flash_image.bin,if=mtd,format=raw -global driver=esp32.gpio,property=strap_mode,value=0x1f -echr 0x02 -serial tcp::5555,server,nowait -gdb tcp::1234

screen -dmS idf

~/esp-idf/examples/get-started/hello_world$ idf.py -p socket://localhost:5555 monitor
Hello world 2!
This is ESP32 chip with 2 CPU cores, WiFi/BT/BLE, silicon revision 0, 2MB external flash
Restarting in 10 seconds...
Restarting in 9 seconds...
Restarting in 8 seconds...

screen -dmS gdb

~/esp-idf/examples/get-started/hello_world$ xtensa-esp32-elf-gdb build/hello-world.elf
(gdb) target remote :1234
Remote debugging using :1234
0x400e29b6 in esp_pm_impl_waiti () at /home/ubuntu/github/esp-idf/components/esp32/pm_esp32.c:484
484         asm("waiti 0");

Timed out flashing when strap_mode=0x1f

However, using 0x1f I encountered the same Timed out waiting for packet header, same error with or without --no-stub.

~/esp-idf/examples/get-started/hello_world $ idf.py -p socket://localhost:5555 flash monitor
esptool.py v2.9-dev
Serial port socket://localhost:5555
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
esptool.py failed with exit code 2

~/esp-idf/examples/get-started/hello_world $ esptool.py -p socket://localhost:5555 -b 460800 --before default_reset --after hard_reset --no-stub --chip esp32 write_flash  --flash_mode dout --flash_freq 40m --flash_size 2MB 0x8000 build/partition_table/partition-table.bin 0x1000 build/bootloader/bootloader.bin 0x10000 build/hello-world.bin
esptool.py v2.9-dev
Serial port socket://localhost:5555
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

from qemu.

Now that seems to be the expected behavior: with strap_mode=0x0f, the emulated chip is in "download mode". When esptool finishes loading the program, the chips still runs the ROM bootloader. In a real development board, esptool.py resets the chip into "flash boot" mode by DTR and RTS UART signals, which are wired to IO0 and EN pins of the chip. However in the case of QEMU, esptool communicates with the emulated chip over a TCP socket, so there are not DTR and RTS signals to toggle, and the emulated chip stays in the download mode.
To run the program after flashing, you need to close QEMU and re-open it with strapping set to flash boot mode.
In other words, idf.py flash and idf.py monitor can work only if strapping mode was previously set to 0xf and 0x1x, respectively. But idf.py flash monitor doesn't work because something needs to modify the strapping mode and reset QEMU between these commands.

from qemu.

That explained!

To summarize and resolve this:

To flash

1. Runs qemu with strap_mode=0x0f

$ ${QEMUBIN}/qemu-system-xtensa -nographic -machine esp32 -drive file=flash_image.bin,if=mtd,format=raw -global driver=esp32.gpio,property=strap_mode,value=0x0f -echr 0x02 -serial tcp::5555,server,nowait -gdb tcp::1234

2. Flash withidf.py flash

To monitor

1. Runs qemu without strap_mode

$ $ ${QEMUBIN}/qemu-system-xtensa -nographic -machine esp32 -drive file=flash_image.bin,if=mtd,format=raw -echr 0x02 -serial tcp::5555,server,nowait -gdb tcp::1234

2. Flash withidf.py monitor
3. Connect gdb with xtensa-esp32-elf-gdb build/hello-world.elf

~/esp-idf/examples/get-started/hello_world $ xtensa-esp32-elf-gdb build/hello-world.elf -ex "target remote :1234" -ex "tb app_main"
Reading symbols from build/hello-world.elf...done.
Remote debugging using :1234
0x40007d16 in ?? ()
Temporary breakpoint 1 at 0x400d39d8: file /home/ubuntu/esp-idf/examples/get-started/hello_world2/main/hello_world_main.c, line 25.
(gdb) c
Continuing.

Thread 1 hit Temporary breakpoint 1, app_main () at /home/ubuntu/github/esp-idf/examples/get-started/hello_world2/main/hello_world_main.c:25
25      {
(gdb) s
26          printf("Hello world 2!\n");
(gdb) s
puts (s=0x3f403018 "Hello world 2!") at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/puts.c:129

Thanks @igrr !

from qemu.

Yes, that's a good summary. I haven't considered the interactive use case before, as my main use case was automated testing. I'll see what can be done to support interactive use cases better. One immediate idea is to make the gpio_strap register writable. This will allow changing the strap mode from GDB.

from qemu.