Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't run code when using IDF v4.4 #26

Closed
thinksilicon opened this issue Dec 20, 2021 · 8 comments
Closed

Can't run code when using IDF v4.4 #26

thinksilicon opened this issue Dec 20, 2021 · 8 comments

Comments

@thinksilicon
Copy link

I've successfully used the emulator for running some PlatformIO/Arduino sketches. PlatformIO used IDF v3.3.5.

Recently I switched to IDF v4.4 and ever since the application doesn't run in the emulator anymore. It does run fine when I flash it to the actual hardware, so it looks like the code that's generated runs fine, generally speaking.

I'm running qemu with the following options:
bin/qemu-system-xtensa -nographic -machine esp32 -drive file=../flash_image.bin,if=mtd,format=raw -global driver=esp32.gpio,property=strap_mode,value=0x12 -drive file=../efuse/qemu_efuse.bin,if=none,format=raw,id=efuse -global driver=nvram.esp32.efuse,property=drive,value=efuse

The output I'm getting is

==22289==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
Adding SPI flash device
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1284
load:0x40078000,len:12808
load:0x40080400,len:3032
entry 0x400805e4
ets ets Jul 29 2019 12:21:46

rst:0x7 (TG0WDT_SYS_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1284
load:0x40078000,len:12808
load:0x40080400,len:3032
entry 0x400805e4

It basically runs into a watchdog timeout. If I disable the watchdog, nothing happens at all.

Please let me know what other useful information I can provide to debug the problem. I upload the firmware through esptool.py and setting the esp32.gpio.property value to 0x01 and writing to the socket:

esptool.py v3.1
Serial port socket://localhost:5555
Connecting...
Device PID identification is only supported on COM and /dev/ serial ports.

Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, Coding Scheme None
Crystal is 40MHz
MAC: 00:00:00:00:00:00
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x000bafff...
Compressed 17216 bytes to 11867...
Writing at 0x00001000... (100 %)
Wrote 17216 bytes (11867 compressed) at 0x00001000 in 0.6 seconds (effective 229.0 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 128...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.0 seconds (effective 611.6 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 627.1 kbit/s)...
Hash of data verified.
Compressed 698432 bytes to 445097...
Writing at 0x00010000... (3 %)
Writing at 0x0001d172... (7 %)
Writing at 0x0002a21e... (10 %)
[...]
Writing at 0x000b3f48... (96 %)
Writing at 0x000b9890... (100 %)
Wrote 698432 bytes (445097 compressed) at 0x00010000 in 21.0 seconds (effective 266.5 kbit/s)...
Hash of data verified.

Leaving...
@igrr
Copy link
Member

igrr commented Dec 20, 2021

Thanks for reporting this @thinksilicon. I was able to reproduce the issue, but the cause of this issue is not clear yet. It seems that the startup code on CPU1 doesn't run properly in emulation. This might be connected to the fact that we are using CPU0 ROM binary when emulating CPU1. Unfortunately I can't give you any timeline for resolving this issue, but i'll update it if there is any progress.

Edit: this issue might actually be a bug in ESP-IDF that just so happens to be not observable on the real chip. Investigating further...

@thinksilicon
Copy link
Author

Thanks for verifying! At least I know now it is an issue with the emulator and not my code.

@igrr
Copy link
Member

igrr commented Jan 2, 2022

The issue was fixed in the master branch of esp-idf in espressif/esp-idf@5d32e80, we are also backporting it into release/v4.4 branch. Once that is done, arduino-esp32 will pick up this fix.

@thinksilicon
Copy link
Author

Cool, thank you! I'll try once the changes have made it into arduino-esp32.

@me-no-dev
Copy link
Member

@thinksilicon changes are in :) please test!

@thinksilicon
Copy link
Author

Are you planning on a new release of the arduino-esp32 framework with the updated IDF as well?
https://github.com/espressif/arduino-esp32/releases

Looks like the changes are not integrated into there just yet? (I've been using the Arduino framework when I discovered the behavior of this bug regport).

@me-no-dev
Copy link
Member

Yes we will. Can't quote a day yet, but soon :)

@igrr
Copy link
Member

igrr commented Apr 1, 2022

Arduino 2.0.3-rc1 is now available and should contain the fix.

@igrr igrr closed this as completed Apr 1, 2022
igrr pushed a commit that referenced this issue Aug 2, 2022
Include the qtest reproducer provided by Alexander Bulekov
in https://gitlab.com/qemu-project/qemu/-/issues/542.
Without the previous commit, we get:

  $ make check-qtest-i386
  ...
  Running test tests/qtest/intel-hda-test
  AddressSanitizer:DEADLYSIGNAL
  =================================================================
  ==1580408==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc3d566fe0
      #0 0x63d297cf in address_space_translate_internal softmmu/physmem.c:356
      #1 0x63d27260 in flatview_do_translate softmmu/physmem.c:499:15
      #2 0x63d27af5 in flatview_translate softmmu/physmem.c:565:15
      #3 0x63d4ce84 in flatview_write softmmu/physmem.c:2850:10
      #4 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18
      #5 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16
      #6 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      #7 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12
      #8 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12
      #9 0x62ae5ec0 in stl_le_dma include/sysemu/dma.h:275:1
      #10 0x62ae5ba2 in stl_le_pci_dma include/hw/pci/pci.h:871:1
      #11 0x62ad59a6 in intel_hda_response hw/audio/intel-hda.c:372:12
      #12 0x62ad2afb in hda_codec_response hw/audio/intel-hda.c:107:5
      #13 0x62aec4e1 in hda_audio_command hw/audio/hda-codec.c:655:5
      #14 0x62ae05d9 in intel_hda_send_command hw/audio/intel-hda.c:307:5
      #15 0x62adff54 in intel_hda_corb_run hw/audio/intel-hda.c:342:9
      #16 0x62adc13b in intel_hda_set_corb_wp hw/audio/intel-hda.c:548:5
      #17 0x62ae5942 in intel_hda_reg_write hw/audio/intel-hda.c:977:9
      #18 0x62ada10a in intel_hda_mmio_write hw/audio/intel-hda.c:1054:5
      #19 0x63d8f383 in memory_region_write_accessor softmmu/memory.c:492:5
      #20 0x63d8ecc1 in access_with_adjusted_size softmmu/memory.c:554:18
      #21 0x63d8d5d6 in memory_region_dispatch_write softmmu/memory.c:1504:16
      #22 0x63d5e85e in flatview_write_continue softmmu/physmem.c:2812:23
      #23 0x63d4d05b in flatview_write softmmu/physmem.c:2854:12
      #24 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18
      #25 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16
      #26 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      #27 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12
      #28 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12
      #29 0x62ae5ec0 in stl_le_dma include/sysemu/dma.h:275:1
      #30 0x62ae5ba2 in stl_le_pci_dma include/hw/pci/pci.h:871:1
      #31 0x62ad59a6 in intel_hda_response hw/audio/intel-hda.c:372:12
      #32 0x62ad2afb in hda_codec_response hw/audio/intel-hda.c:107:5
      #33 0x62aec4e1 in hda_audio_command hw/audio/hda-codec.c:655:5
      #34 0x62ae05d9 in intel_hda_send_command hw/audio/intel-hda.c:307:5
      #35 0x62adff54 in intel_hda_corb_run hw/audio/intel-hda.c:342:9
      #36 0x62adc13b in intel_hda_set_corb_wp hw/audio/intel-hda.c:548:5
      #37 0x62ae5942 in intel_hda_reg_write hw/audio/intel-hda.c:977:9
      #38 0x62ada10a in intel_hda_mmio_write hw/audio/intel-hda.c:1054:5
      #39 0x63d8f383 in memory_region_write_accessor softmmu/memory.c:492:5
      #40 0x63d8ecc1 in access_with_adjusted_size softmmu/memory.c:554:18
      #41 0x63d8d5d6 in memory_region_dispatch_write softmmu/memory.c:1504:16
      #42 0x63d5e85e in flatview_write_continue softmmu/physmem.c:2812:23
      #43 0x63d4d05b in flatview_write softmmu/physmem.c:2854:12
      #44 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18
      #45 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16
      #46 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      qemu#47 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12
      #48 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12
      ...
  SUMMARY: AddressSanitizer: stack-overflow softmmu/physmem.c:356 in address_space_translate_internal
  ==1580408==ABORTING
  Broken pipe
  Aborted (core dumped)

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211218160912.1591633-4-philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants