-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected light sleep and deep sleep behaviour on ESP32-S3 #6612
Comments
Oh, my bad... I am so used to boards that have a dedicated serial to USB converter chip 😉 However the Adafruit ESP32S3 Feather board comes only with the native USB inside the the ESP32S3 module... so when the MCU goes to light/deep sleep the board simply cuts the serial connection to the PC. And it does not reestablish a working serial connection to the PC when the board wakes up. Is there any solution for that? |
Are you using the S3 feather board definition? It should be using TinyUSB (USB-OTG) for serial, which should re-enumerate on boot. |
@me-no-dev |
By the way meanwhile i also tried putty, but even that behaves exactly the same as Arduino IDE's own serial monitor and the serial connection does not seem to automatically reestablish when the board wakes up from sleep. However if i close the serial monitor and reopen that again just when the board is waking up, then i see the serial output generated in the actual wake cycle, but as soon the board goes to sleep next time, the serial connection breaks again, and does not reestablish automatically when the board wakes up next time. |
Thanks @idea--list . I'll give it a try. Did not expect to have issues with USB-OTG :) |
I tested the sketch and it works fine at least on MacOS. I think that you have a small misunderstanding of how light sleep works. As opposed to Deep Sleep, Light Sleep will continue the execution from where Some operating systems / USB drivers might not like the fact that the ESP is not responding on the USB while in light sleep and can disable the device/halt it. At least on MacOS that does not seem to be an issue with CDC. @VojtechBartoska can we get this tested on Linux and Windows? |
cc @SuGlider (Please test on Windows) |
@PilnyTomas please help testing this on Linux. |
Linux works ok in both Arduino IDE and terminal when connected to the UART terminal on the dev board. Serial.begin(115200);
while(!Serial){;}
Serial.println("Serial: Starting");
log_d("log: Starting");
delay(15000);
Serial.println("Serial: Entering sleep");
log_d("log: Entering sleep");
esp_sleep_enable_timer_wakeup(10e6); //
Serial.print("Attempting to connect to SSID: ");
Serial.println(ssid);
log_d("log: Attempting to connect to SSID: %s", ssid); And the resulting output in Arduino IDE is this:
Also on the RESET button press, the port number in Linux changes and I have to manually switch the port number in Arduino IDE therefore I miss some output if I try to reset the board - the output was captured after flashing. |
Light Sleep & Deep sleep needs to be tested, same setup with 10 seconds. |
Retested. Exact code and logs |
@me-no-dev I created a sketch for testing it with a "LED signaling" / ESP32-S3 devkit board uses pin 48 as RGB NeoPixel LED
#define BUILTIN_RGBLED_PIN 48
// RMT peripheral is used to drive the RGB LED
rmt_obj_t* rmt_LED = NULL;
rmt_data_t led_data[8 * 3]; // 8 bits x 3 colors per LED
enum {WHITE, RED, GREEN, BLUE, YELLOW, CYAN, MAGENTA, OFF};
int LED_Colors[8][3] = {
//Green, Red, Blue
{ 0xFF, 0xFF, 0xFF }, // White
{ 0x00, 0xFF, 0x00 }, // Red
{ 0xFF, 0x00, 0x00 }, // Green
{ 0x00, 0x00, 0xFF }, // Blue
{ 0xC0, 0xFF, 0x00 }, // Yellow
{ 0xB0, 0x00, 0xFF }, // Cyan
{ 0x00, 0xD0, 0xB0 }, // Magenta
{ 0x00, 0x00, 0x00 }, // Off | Black
};
void setLEDColor(int *color, rmt_obj_t *rmtObj) {
if (rmtObj == NULL || color == NULL) return;
// Init data with only one led ON
int col, bit;
int i = 0;
for (col = 0; col < 3; col++ ) {
for (bit = 0; bit < 8; bit++) {
if ( color[col] & (1 << (7 - bit)) ) {
led_data[i].level0 = 1;
led_data[i].duration0 = 8;
led_data[i].level1 = 0;
led_data[i].duration1 = 4;
} else {
led_data[i].level0 = 1;
led_data[i].duration0 = 4;
led_data[i].level1 = 0;
led_data[i].duration1 = 8;
}
i++;
}
}
// Send the data
rmtWrite(rmt_LED, led_data, 8 * 3); // 8 bits x 3 colors per LED
}
void setup() {
//Initialize serial and wait for port to open:
Serial.begin(115200);
while (!Serial) {
delay(100);
}
if ((rmt_LED = rmtInit(BUILTIN_RGBLED_PIN, RMT_TX_MODE, RMT_MEM_64)) == NULL) {
Serial.println("RGB LED init failed\n");
rmt_LED = NULL;
}
if (rmt_LED) rmtSetTick(rmt_LED, 100);
esp_sleep_enable_timer_wakeup(10e6);
setLEDColor(LED_Colors[WHITE], rmt_LED);
#if 0
// DEEP sleep test.
Serial.println("\n\nEntering in DEEP Sleep...");
Serial.flush();
esp_deep_sleep_start();
// From this point on it will never get executed back from deep sleep
// Board will hard reset after returning from deep sleep.
Serial.println("Got back from DEEP Sleep");
#else
// LIGHT Sleep test.
Serial.println("\n\nEntering in LIGHT Sleep...");
Serial.flush();
esp_light_sleep_start();
Serial.println("Got back from LIGHT Sleep...\n");
#endif
Serial.flush();
}
void loop() {
static uint32_t count = 0;
Serial.printf("Loop CDC OUTPUT#%d\n", count++);
setLEDColor(LED_Colors[count & 7], rmt_LED);
delay(2000);
}
IDE Settings for CDC: |
@PilnyTomas - If everything works fine, using CDC or UART, you should see a log output like this:
|
For windows the output on CDC USB port is:
And nothing else, just the LED changing colors after that.... |
Update...It seems that the whole ESP32-S3 hangs! Set Menu->Tools->Upload Mode: "UART0 / Hardware CDC" Now.... the trick! With the Serial Monitor still open, Change the COM port back to the UART one (in my case COM21)..... That's really wierd! Change it back to the USB CDC port.... it freezes again! There is some sort of bug there, for sure! @me-no-dev Update 2The issue has to do with the Light Sleep... |
@SuGlider sounds like the sketch is waiting to be able to write to somewhere and since nobody is reading, the fifo is full and hanging. Switching the port probably re-sends some packet to the USB and it let's it run. On MacOS where light sleep is not an issue, the sketch continues to run without issues and switching ports. |
It need deeper investigation to find why CDC can't recover and send the data from FIFO out when using Windows. For Windows, there is this problem and after returning from light sleep it can't recover and CDC hangs along with the Arduino Task execution. |
just stumbled on this issue on my search for *sleep examples.. i converted the example from to use the adafruit neopixel library as the rmt thing did not compile for me.. // https://github.com/espressif/arduino-esp32/issues/6612#issuecomment-1135183742
// converted to use Adafruit NeoPixel lib
#include <Adafruit_NeoPixel.h>
Adafruit_NeoPixel pixels(1, PIN_NEOPIXEL, NEO_GRB + NEO_KHZ800);
enum {
WHITE,
RED,
GREEN,
BLUE,
YELLOW,
CYAN,
MAGENTA,
OFF
};
uint32_t LED_Colors[8] = {
// Red, Green, Blue
0xFFFFFF, // White
0xFF0000, // Red
0x00FF00, // Green
0x0000FF, // Blue
0xFFC000, // Yellow
0x00B0FF, // Cyan
0xD000B0, // Magenta
0x000000, // Off | Black
};
void setup() {
// Initialize serial and wait for port to open:
delay(100);
Serial.begin(115200);
while (!Serial) {
delay(100);
}
Serial.println("");
Serial.println("test_sleep.ino");
#if defined(NEOPIXEL_POWER)
// If this board has a power control pin, we must set it to output and high
// in order to enable the NeoPixels. We put this in an #if defined so it can
// be reused for other boards without compilation errors
pinMode(NEOPIXEL_POWER, OUTPUT);
digitalWrite(NEOPIXEL_POWER, HIGH);
#endif
pixels.begin(); // INITIALIZE NeoPixel strip object (REQUIRED)
pixels.setBrightness(20); // not so bright
esp_sleep_enable_timer_wakeup(10e6);
pixels.fill(LED_Colors[WHITE]);
#if 0
// DEEP sleep test.
Serial.println("Entering in DEEP Sleep...");
Serial.flush();
esp_deep_sleep_start();
// From this point on it will never get executed back from deep sleep
// Board will hard reset after returning from deep sleep.
Serial.println("Got back from DEEP Sleep");
#else
// LIGHT Sleep test.
Serial.println("Entering in LIGHT Sleep...");
Serial.println("");
Serial.flush();
esp_light_sleep_start();
Serial.println("");
Serial.flush();
Serial.println("Got back from LIGHT Sleep...");
#endif
Serial.flush();
}
void loop() {
static uint32_t count = 0;
Serial.print("Loop CDC OUTPUT #");
Serial.println(count++);
pixels.fill(LED_Colors[count & 7]);
pixels.show();
delay(2000);
} i tested this with an adafruit Feather ESP32-S3 Reverse TFT. arduino-cli profile:
for me the output on my kubuntu 23.10 is: light sleep minicom
light sleep arduino ide 2.2.1
light sleep minicom
deep sleep arduino ide 2.2.1
→ 😄 so for me it is working :party: |
Board
Adafruit ESP32-S3 Feather
Device Description
Adafruit ESP32-S3 Feather
Hardware Configuration
Nothing attached
Version
latest development Release Candidate (RC-X)
IDE Name
Arduino IDE V1.8.19
Operating System
Windows 10
Flash frequency
80MHz
PSRAM enabled
no
Upload speed
115200
Description
Began to try the ESP32-S3 today and find unexpected behaviour of the native USB-Serial converter.
When the sketch uses deep sleep:
I can hear the sound playing when the COM port detaches and even when the board is recognized when waking up after deep sleep. However the the Serial output updates only before the board goes to deep sleep for the first time. Later on the serial output does not update despite the board is waking up. Power consumption is as expected.
Did not find earlier report regarding deep sleep.
When the sketch uses light sleep:
I do not see any serial output at all (not even in the 1st cycle). Do not hear any sounds for detaching/recognition and also the power consumption drops to the expected level only in the 1st cycle but after that it remains at least 87mA without ever dropping back to low levels. Seem like the board can not reenter light sleep after it has waken up for the first time.
This might be related to #6581
Sketch
Debug Message
Other Steps to Reproduce
No response
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: