how is core development work prioritised?

[kjm1102]

What's the correct etiquette if you see a problem but don't have the smarts to do a pull request to fix it? I can't get esp32.wake_on_ext0 working on an esp32s2 in deepsleep (https://github.com/orgs/micropython/discussions/14539). Since it works OK on regular esp32s I figure it must be some subtlety of the s2?

Is there a proper channel to bring an observation like this to the attention of people with the wherewithal to make a fix? I've noticed some discussion posts with a red 'BUG' applied but can't figure how that flag is selected.

[peterhinch]

I would suggest first starting a discussion under ESP32 in case someone knows a fix. If this is in fact a missing feature the next step is to check if there is an issue in the micropython bug tracker and, if not, to raise one. Include a simple reproducer that works on ESP32 but not on the S2.

[scruss]

seconding raising this as an issue.

It might be helpful if you were running the most recent release version on both boards (v1.23.0)

[kjm1102]

I've tried it on an esp32 & esp32s2 both running v1.23.0 & got the same results, works on the esp32 but not the esp32s2 . It's going to be awkward for me to write this up in a rigorous way as an issue though because the behaviour also depends on the USB. The esp32 for example will go to into deepsleep & wake when I press the button if the USB is not plugged into anything or I'm using thonny but wakes immediately if I've got it plugged into Atom. It's a real PIA when boards behave differently in different development environments.

[peterhinch]

USB and deepsleep are frequently problematic. I tend to debug using a serial port and FTDI adaptor - but there aren't many platforms that actually give a REPL on a serial port.

[scruss]

especially since the ESP32 used an external USB UART chip but the ESP32S2 handles all USB connections on-chip. This makes keeping a connection open more complex on the S2

[kjm1102]

Separate usb chip repl seemed better behaved with deepsleep 6 years ago when I started my upython journey or maybe I was just less aware then? Anyway I've had a novice go at raising an issue, #15260, so see what gels I guess?

[ThinkTransit]

What code are you using?

I have an esp32s2 here that uses wake_on_ext0 successfully, pull up resistor and button drives pin low. Wakes from deepsleep using the following code.

slp = Pin(pins.WAKE_BUTTON, Pin.IN, Pin.PULL_UP)
esp32.wake_on_ext0(pin=slp, level=esp32.WAKEUP_ALL_LOW)

If you don't have a pull up resistor it will most likely wake immediately after it goes asleep.

[kjm1102]

I tried running your code on my board Pat but pins is undefined for me so I added the pullup

import os,time,esp32
from machine import Pin,deepsleep

time.sleep(5)
pb=Pin(0, Pin.IN, Pin.PULL_UP); esp32.wake_on_ext0(pb,0)
deepsleep(10*1000)

still wakes immediately after entering deepsleep.

I had a look with a multimeter, something is sending gpio0 lo after the abortive deepsleep & the default powerup state (input with pullup) is not restored till I press the reset button.

This is my s2 what flavour of s2 are you using? Can you give details of pins & WAKE_BUTTON? I'd like to try the exact same code you're using.

[ThinkTransit]

'pins' is just a python module containing my pin definitions. Have you tried running your code on a different pin? GPIO0 is a strapping pin and behaves differently at boot/reset so that might be causing an issue.

I'm using the code on a proprietary board running an older version of micropython however I have a feather S2 here and will test it over the weekend with the latest version and let you know.

[kjm1102]

You're right about gpio0 being an oddball Pat, it's pullup becomes a pulldown as soon as the s2 goes into deepsleep which causes the immediate wakeup. I managed to stop this quirk by putting hold=1 in the pin setup (pb=Pin(0, Pin.IN, hold=1)) but other pins that power up natively with a pullup (eg gpio 14) don't need it. Also confirming that s2 pins that don't natively power up with a pullup (eg gpio2) need Pin.PULL_UP in their setup.