Is it possible to keep UART powered while in light-sleep?

[doragasu]

I am using an ESP32-S3 with two UART connected peripherals.

To reduce power drain, I am using DFS and I want to implement auto light sleep. But when the chip enters light sleep, it looks like the UART stops working (either power is removed, clock is removed or both, I don't know). But I need the UART to keep working in light sleep. Using UART wake-up does not help because I cannot afford losing the initial bytes.

Can UART be kept powered and working while in light sleep mode? How?

Reading the datasheet, I cannot get clear information about if this is possible. According to this diagram, UART is in the digital power domain:

20250122_140834.png (170.82 KiB) Viewed 1948 times

And according to this diagram, the Digital domain power (that presumably has the UART inside) is controlled by the xpd_dg_wrap signal (that also according to datasheet is the same as xpd_dig_reg, governed by RTC_CNTL_DG_WRAP_PD_EN):

20250122_101450.png (121.31 KiB) Viewed 1948 times

My understanding is that the Digital System Voltage Regulator should be working, since I configured in menuconfig the CPU power to be maintained while in light-sleep (CONFIG_PM_POWER_DOWN_CPU_IN_LIGHT_SLEEP=n). Is this right? I have also configured GPIOs to keep working in light sleep (CONFIG_PM_SLP_DISABLE_GPIO=n).

If my assumption above is right, the only thing preventing the UART to work could be missing clock. I have tried configuring the UART to use UART_SCLK_RTC and UART_SCLK_XTAL without success.

Am I doing anything wrong? Is keeping the UART working in light-sleep even possible at all?

[ahsrabrifat]

The ESP32-S3 may not fully support high-speed UART operation during light sleep due to clock constraints. UART functionality is tied to the Digital Power Domain. When the chip enters light sleep, the xpd_dg_wrap (or xpd_dig_reg) signal may disable parts of this domain, potentially halting UART operation.
A clock source for UART is required. If the clock source is disabled or unavailable during light sleep, UART communication fails.
To know more about the low-power modes of ESP32, you can see the following articles.
https://www.theengineeringprojects.com/ ... modes.html
https://randomnerdtutorials.com/esp32-d ... p-sources/

[doragasu]

But is it possible at all? How? The links provided are quite basic and do not help for my questions.

[ves011]

Last year i was doing some power profiling on ESP32-S3, in various scenario.
Usually i use USB Serial / JTAG for console, but when exit from light sleep this requires a disconnect/connect cycle.
So i used UART0 on IO33-34 over a FTDI 232 module which i had in my hand. Just connecting the RX/TX with 2 wires.
UART was working fine in light sleep wo doing any specific setting except configuring the console to be uart0 in sdkconfig

[doragasu]

@ves011: thanks a lot for the info. Were you receiving data during light sleep? If you were using the UART only for the debug trace, and did not receive data, that's a different use case.

I have been doing some more tests with the C3 (that I would like to confirm work the same on the S3, but couldn't yet) by using a minimal test program. And I am getting some strange results:

• On my initial tests, when awaken from UART, I got either some pseudo random garbage or sometimes some skipped bytes. Lowering baudrate did not seem to help.
• This gave me the idea that maybe this random errors are because UART clock is not stable during wakeup. So I tried configuring both the UART and the RTC clock to use the fast RC clock. This way the clock used for UART continues running during light sleep. The result was that random garbage dissapears, but sometimes it still loses bytes. Lowering baudrate to 9600 or even 4800 bps helps here. Could this be caused because of electrical noise during wakeup?
• An interested and totally unexpected side effect of the test above using RTC fast clock, is that when baudrate is low (e.g. 4800 bps), I also receive the character causing the wakeup (a '$' in this case). According to documentation, the character used for wakeup is lost. I suppose that if I am getting it, is because effectively UART somehow continues working during light sleep!

I am still a bit confused and would like to know if there's an "official" way to make this work.

[doragasu]

Got time to make more tests, this time on the S3, got pretty similar results. Unfortunately, I couldn't get it to reliably receive a 64 byte frame attached to the wakeup character. For about 20 bytes, I could get it to reliably receive by using the RC fast clock for both UART and RTC, and low baud rates (9600 bps or even better with 4800 bps). but when you increase the frame size beyond that, you start randomly losing bytes. So there must be some problem with the clock and/or power noise causing this.

I'm frankly disappointed about these chips not being able to keep the UART receiving while in light sleep mode. With the really big FIFOs the UARTs have, it would be really convenient being able to feed them while the chip is in low power. I hope Espressif is able to improve power consumption and modes in these chips, because I love ESP32 devices, but they are not up to the task when talking about battery efficiency.

[MicroController]

For about 20 bytes, I could get it to reliably receive by using the RC fast clock for both UART and RTC, and low baud rates (9600 bps or even better with 4800 bps). but when you increase the frame size beyond that, you start randomly losing bytes. So there must be some problem with the clock and/or power noise causing this.

Maybe try running a calibration (ESP_CLK_TREE_SRC_FREQ_PRECISION_EXACT) on the RC clock and then (re-)set the baudrate for the driver to take the latest clock frequency into account.