ESP32-S3 goes into safe mode on real deep sleep

[dgriswo]

CircuitPython version

Adafruit CircuitPython 7.3.0-alpha.0-9-gf39c2b2e1 on 2022-02-24; FeatherS3 with ESP32S3
Board ID:unexpectedmaker_feathers3

Code/REPL

import time
import alarm

time_alarm = alarm.time.TimeAlarm(monotonic_time=(time.monotonic() + 600))
alarm.exit_and_deep_sleep_until_alarms(time_alarm)

Behavior

Board does not enter deep sleep. Code re-executes immediately.

Deep sleep is faked correctly when connected via USB.

Description

No response

Additional information

Also reproduced on 7.2.0-alpha.2 and 7.2.0-rc.2

[dgriswo]

I threw some code in to publish microcontroller.cpu.reset_reason to MQTT. (ignore the battery voltage, the voltage divider math is wrong.)

[dgriswo]

Also reproduced the issue (and reset_reason) using the Unexpected Maker TinyS3.

[prplz]

Reproduced on esp32 s3 devkitc n8r8

[prplz]

With some printf debugging, I tracked it down to this line hanging: https://github.com/adafruit/esp-idf/blob/circuitpython-v4.4/components/esp_hw_support/sleep_modes.c#L509.
If I comment that line out, sleep works as expected.

[tannewt]

@igrr Has anyone seen issues entering deep sleep from the APP core? It looks like it's hanging when trying to stall the PRO core and then the watchdog resets things.

[billr12]

Also reproduced on Adafruit ESP32-S3 Feather

[scarolan]

Confirmed on QT PY ESP32-S3. Updating the firmware to 8.0.0 alpha allow sleep to work when powered by USB-C, but not when powered by a LiPo battery.

[jepler]

Maybe there's a way to use IPC to make the sleep execute on the PRO CPU, but we'd really rather have the bug fixed upstream.

[dgriswo]

Confirmed on QT PY ESP32-S3. Updating the firmware to 8.0.0 alpha allow sleep to work when powered by USB-C, but not when powered by a LiPo battery.

If connected via USB-C and the data lines are active, CircuitPython fakes deep sleep.

[moefear85]

@prplz

Line 509 is a closing bracket, so I think the code has changed since then. has the issue been resolved? if not, which line are you referring to? I'm curious, because there is a uart line close nearby, and I wouldn't be surprised if that is part of the problem.

[prplz]

@moefear85 I think the line was esp_ipc_isr_stall_other_cpu();

[moefear85]

@ prplz

oh then idk... it's just that there's currently this issue, and I double checked, it doesn't call esp_ipc_is_stall_other_cpu, so whatever is triggering the wdt there, probably isn't the same thing causing this.

[yonaguska]

I wish I had seen this before I bought 5 of the UM FeatherS3 boards; I need deep sleep for an IoT project, to conserve battery power. I know my code works on an Adafruit QtPy ESP32-S2, which suffers from another issue that brought me to the FeatherS3.

The issue with the QtPy system is that it hangs up in what seems to be the SAFE_MODE, which I think is caused by voltage spikes in the supply when they are run off of a battery. I can't filter the spikes adequately, and a QtPy will run for hours or days before it gets hit, but it always gets hit eventually. Resolving this requires a hardware reset to get out of SAFE_MODE, and I built a hardware WDT to issue a reset signal to the processor. Since the QTPy lacks a reset pin, I soldered a wire from the WDT to the tiny reset switch on the QtPy, a real PIB. This is why I bought the UM FeatherS3, it has an exposed reset pin.

I am testing 5 of these QtPy systems, and the hardware WDT has fixed it on all of them. I looked to the FeatherS3 to rid myself of the frangible kluge of the reset wire; this system will be placed under my house (to monitor for water and gas leaks), and I really need it to be uber-reliable. I hate crawling under the house; at 72, it's not fun, trust me.

On a side note, I noticed someone had a similar WDT on eBay going for about $10; I built some extras that I could sell for about half.

But I digress, so back to my main concern. Has there been any progress on fixing this deep sleep issue?

[tannewt]

Maybe there's a way to use IPC to make the sleep execute on the PRO CPU, but we'd really rather have the bug fixed upstream.

I tried this with no luck. It still triggers a watchdog. My code is here: https://github.com/tannewt/circuitpython/tree/ipc_deep_sleep

[BeatArnet]

Reproduced error with immediate start after deep sleep

• adafruit feather s3 tft
• circuitpython 8.0.0 beta2
• example from the adafruit documentation (deep_sleep 20 secondes)

[yonaguska]

Also reproduced the error with an immediate start after deep sleep

• Unexpected Maker Feather S3
• CircuitPython 8.0.0 beta2
• example from the adafruit documentation (deep_sleep 20 seconds)

[dgriswo]

There may be more visibility to this bug. JP's CircuitPython Parsec for Oct 16, 2022 highlighted deep sleep.

[dhalbert]

As implied above, this appears to be an upstream bug: espressif/esp-idf#8569. Other Espressif users have reported this. It has been "selected for development" by Espressif. We will await an upstream fix for this. I'll remove this from the 8.0.0 issues and move to 8.x.x.

[dhalbert]

Reproduced on both Feather ESP32-S3 8MB flash no PSRAM and Feather ESP32-S3 4MB flash / 2MB PSRAM, using this test program. NeoPixel flashes three times indicating safe mode when connected to battery.

import digitalio
import board
import alarm
import time

uart = board.UART()
uart.baudrate = 115200

led = digitalio.DigitalInOut(board.LED)
led.switch_to_output(True)
time.sleep(2)
led.value = False
msg = "Alarm was " + str(alarm.wake_alarm) + "\r\n"
print(msg, end = "")
uart.write(msg.encode("utf-8"))


time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 5)

msg = "Entering deep sleep at " + str(time.monotonic()) + "\r\n"
print(msg, end="")
uart.write(msg.encode("utf-8"))

alarm.exit_and_deep_sleep_until_alarms(time_alarm)