Closed mike-2020 closed 1 month 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`
Seems to work fine on my devkit. Have you measured the voltage on the pin set as the wakeup pin? Does the value change?
I added the follow log just before run into ULP, but the log did not show up.
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).
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?
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.
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?
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.
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