espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.67k stars 7.29k forks source link

Issue with example ulp_riscv\gpio_interrupt (IDFGH-13470) #14371

Closed mike-2020 closed 1 month ago

mike-2020 commented 2 months ago

Answers checklist.

IDF version.

5.2.2

Espressif SoC revision.

ESP32S3

Operating System used.

Linux

How did you build your project?

Command line with CMake

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32S3, with 8M PSRAM

Power Supply used.

Battery

What is the expected behavior?

Main processor is only waked up after button GPIO_NUM_0 is pressed.

What is the actual behavior?

looks like ULP is run automatically (without any press on GPIO_NUM_0 button), and then ULP wake up the main processor.

Steps to reproduce.

No change to the example source code. Just compile it and run.

Debug Logs.

No response

More Information.

No response

mike-2020 commented 2 months ago

This is logs:

`W (92) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header. ULP-RISC-V woke up the main CPU! Entering in deep sleep

ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x5 (DSLEEP),boot:0x2a (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3810,len:0x12b4 load:0x403c9700,len:0x4 load:0x403c9704,len:0xaf0 load:0x403cc700,len:0x2be4 entry 0x403c9898 W (92) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header. ULP-RISC-V woke up the main CPU! Entering in deep sleep

ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x5 (DSLEEP),boot:0x2a (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3810,len:0x12b4 load:0x403c9700,len:0x4 load:0x403c9704,len:0xaf0 load:0x403cc700,len:0x2be4 entry 0x403c9898 W (92) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header. ULP-RISC-V woke up the main CPU! Entering in deep sleep

ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x5 (DSLEEP),boot:0x2a (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3810,len:0x12:0x403c9700,len:0x4 load:0x403c9704,len:0xaf0 load:0x403cc700,ry 0x403c9898 W (92) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header. ULP-RISC-V woke up the main CPU! Entering in deep sleep

ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x5 (DSLEEP),boot:0x2a (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3810,len:0x12b4 load:0x403c9700,len:0x4 loa load:0x403cc700,len:0x2be4 entry 0x403c9898`

ESP-Marius commented 2 months ago

Seems to work fine on my devkit. Have you measured the voltage on the pin set as the wakeup pin? Does the value change?

mike-2020 commented 2 months ago

I added the follow log just before run into ULP, but the log did not show up.

image

I also check the level of GPIO_NUM_0 just before waking up the main processor. The code was excuted (main processor was waken up).

image

This means, GPIO_NUM_0 was not LOW before the main CPU runing into deep sleep, but it did wake up the ULP, and GPIO_NUM_0 testing result in ULP was LOW. How can this happen?

mike-2020 commented 2 months ago

After adding more logs, I can figure out where the GPIO_NUM_0 become low. See screenshot below. For the first loop after boot, "strange5: low" (and logs after it) were printed out. and then, for the second loop (main CPU is waken up by ULP), "strange8: low" (and logs after it) were printed out. So, it seems function ulp_riscv_config_and_run changes GPIO_NUM_0 state.

image

image

ESP-Marius commented 2 months ago

Are you able to check with a logic analyzer/scope connected to see what the actual state of the GPIO ?

Also what are you running this on? A devkit? What is connected to the GPIO?

ESP-Marius commented 1 month ago

Marking this as resolved due to no activity, feel free to reopen the issue if you are still experiencing any issues and wanna continue troubleshooting it.