esp32/modmachine: wake_ext1_pins() returns which EXT1 pins caused wakeup. - #7990

Fails to build GENERIC_C3 with ESP-IDF 4.4.
I think this is an ESP-IDF bug.

/home/runner/.espressif/tools/riscv32-esp-elf/esp-2021r1-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: esp-idf/main/libmain.a(modmachine.c.obj): in function `machine_wake_ext1_pins':
/home/runner/work/micropython/micropython/ports/esp32/modmachine.c:220: undefined reference to `esp_sleep_get_ext1_wakeup_status'
collect2: error: ld returned 1 exit status

I'd love to have this functionality in my project. Is there a way I could compile and test this myself? or merge this PR?

Of course, if you are comfortable with GIT and have the environment (e.g. ESP-IDF) to compile micropython.
However, I will create a binary within the next two days or so.

@karfas much appreciated. I am confident enough with git and I don't have esp-idf but I am sure I can figure how to install it. Is there a guide somewhere I can follow to compile it for the esp32? (maybe I missed it on the docs? I tried to find one)

@academo: I don't think there is a complete description in the upy docs. In Linux, the process is (relative) straight:

1. install ESP-IDF (see https://docs.espressif.com/projects/esp-idf/en/v4.4/esp32s2/get-started/index.html#get-started-get-esp-idf)
2. clone micropython (+maybe merge the PR).
   You might find the generic instructions for building uPy useful => https://docs.micropython.org/en/latest/develop/gettingstarted.html?highlight=compiling
3. set your environment to use the variables from esp-idf export.sh
4. (cd micropython/mpy-cross && make)
5. (cd micropython/ports/esp32 && make)

BTW, the forum https://forum.micropython.org/ is most likely a better place to ask about compilation issues.

@academo: I just uploaded the binary including #7990, based upon the current micropython master branch to https://github.com/karfas/upy-bin/blob/master/micropython-GENERIC-ext1_reason.bin
It works (in principle, I didn't try to actually wake the thing from deep sleep) on the esp32-pico-d4.

Rebased to current master.

@karfas I'll give it a try this coming week. I am finishing my current project with c++ and arduino (mainly because of this feature and the pwm problem).

@karfas I tried today to run your .bin in a generic esp32 dev board and it got stuck in an infinite reboot loop. I fully erased the flash before installing your binary

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:0x3f400020,len:197324
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (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:0x3f400020,len:197324
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (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:0x3f400020,len:197324

... and so on...

I confirmed by reinstalling esp32-20220221-unstable-v1.18-141-gff9c70850.bin which works as expected (no reboot loop)

EDIT:
This was the flashing command and output:

❯ esptool.py --chip esp32 --port /dev/ttyUSB0 write_flash -z 0x1000 micropython-GENERIC-ext1_reason.bin
esptool.py v3.2
Serial port /dev/ttyUSB0
Connecting...........
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: [redacted]]
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00165fff...
Compressed 1461984 bytes to 989481...
Wrote 1461984 bytes (989481 compressed) at 0x00001000 in 87.4 seconds (effective 133.9 kbit/s)...
Hash of data verified.

To followup: I build my own firmware.bin and I also get this reboot loop. I guess there's something in master that is broken.

@academo: I also get the boot loop when flashing using your esptool.py command.
However, a fresh build (my script uses idf.py ... flash) - gives me a working REPL on the ESP32.
idf.py ... flash uses

esptool.py --chip esp32 -p /dev/ttyUSB0 -b 115200 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x1000 bootloader/bootloader.bin 0x10000 micropython.bin 0x8000 partition_table/partition-table.bin

• this also worked on the command line.

Most likely, I had created the bin in some wrong way.

This is now tested and working on my ESP32-D0WDQ6 (revision 1) chip on an ESP32 DevKit V1 board (or clone).
My test program:

import machine
from machine import Pin, TouchPad
import time
import esp32
import esp

if machine.reset_cause() == machine.DEEPSLEEP_RESET:
    print("Reset: Wakeup from deep sleep")
else:
    print("Reset: Other reason")

print("wakeup_reason(): {}".format(machine.wake_ext1_pins()))

pin4 = Pin(4, mode = Pin.IN, pull = Pin.PULL_DOWN)
wake = Pin(2, mode = Pin.IN, pull = Pin.PULL_DOWN)
esp32.wake_on_ext1(pins = [wake,pin4], level = Pin.WAKE_HIGH)

time.sleep(2)
print('Going to sleep')
machine.deepsleep()

returns e.g.

>>> import main1
Reset: Wakeup from deep sleep
wakeup_reason(): (4,)
Going to sleep

or

>>> import main1
Reset: Wakeup from deep sleep
wakeup_reason(): (2, 4)
Going to sleep

For the second test, I connected both inputs to the same button.

@robert-hh: Can you test/review this ? It's mostly your code, anyway.

@karfas can you share me the new bin? I can help you testing in some of my ESP32 dev boards. I

@academo: New binary was uploaded to https://github.com/karfas/upy-bin. Flashing worked on two of my test devices.

I'm sorry for bumping an old post (I've been watching it for some time), but having this functionality would be really excellent. The log automated check did not retain a record of why the build failed in "docs / build". I'm not an expert, but could this mean there was some formatting mistake in the documentation?

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
        rp2:    +0 +0.000% PICO

Codecov Report

Merging #7990 (9544155) into master (9e6885a) will not change coverage.
The diff coverage is n/a.

❗ Current head 9544155 differs from pull request most recent head 7205a66. Consider uploading reports for the commit 7205a66 to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@           Coverage Diff           @@
##           master    #7990   +/-   ##
=======================================
  Coverage   98.50%   98.50%           
=======================================
  Files         155      155           
  Lines       20549    20549           
=======================================
  Hits        20241    20241           
  Misses        308      308           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Fails to build GENERIC_C3 with ESP-IDF 4.4. I think this is an ESP-IDF bug.

/home/runner/.espressif/tools/riscv32-esp-elf/esp-2021r1-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: esp-idf/main/libmain.a(modmachine.c.obj): in function `machine_wake_ext1_pins':
/home/runner/work/micropython/micropython/ports/esp32/modmachine.c:220: undefined reference to `esp_sleep_get_ext1_wakeup_status'
collect2: error: ld returned 1 exit status

I've done some digging as I'd like this feature for a project. The build fails because despite what the docs say, esp_sleep_get_ext1_wakeup_status isn't available because SOC_PM_SUPPORT_EXT_WAKEUP isn't set for the c3. esp_sleep_get_gpio_wakeup_status does work. If you combine this change (swapping out ext1 for gpio) with this one (that uses gpio wake under the hood) you get a micropython build for the c3 that you can wake from deep sleep and tell which pins woke it.

I'm hitting this same bug, it's terrible.

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

Closing in favour of #17542.