ESP32-S3 tasks not working

[stevenbennett]

I can not get tasks to work with an ESP32-S3 dev module, but I have no problem when using ESP32s. The MCU constantly reboots with a message on the serial port about stack overflow. I have tried using stack sizes from 2000 to 10000 with the same result so I wonder if it is something more fundamental? The serial output is below, followed by the code:

***ERROR*** A stack overflow in task arduino_task has been detected.

Backtrace: 0x40376dde:0x3fcecfc0 0x4037b7b5:0x3fcecfe0 0x4037e58a:0x3fced000 0x4037ca8d:0x3fced080 0x4037e6f0:0x3fced0b0 0x4037e6e6:0x3fced0f0 0x4200210d:0x000003e8 |<-CORRUPTED

ELF file SHA256: 40291c4b1c2df599

07:27:41:482 -> Rebooting...
�07:27:41:516 -> ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403773f1
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3818,len:0x109c
load:0x403c9700,len:0x4
load:0x403c9704,len:0xb50
load:0x403cc700,len:0x2fd0
entry 0x403c98ac
07:27:41:702 -> Hello World
looping

code
====
#include <EasyNeoPixels.h>

unsigned long previousMillis = 0; // store for Millis value
const long interval = 1000; // 1-second interval for process 1
int currentColor = 0; // Tracks the current colour: 0 = red, 1 = green, 2 = blue


void setup() {

setupEasyNeoPixels(48, 1);

xTaskCreate(arduinoTask, "arduino_task", 5000, NULL, 1, NULL);

}

void arduinoTask(void *pvParameter)
{
Serial.begin(115200);
delay(100);
Serial.println("Hello World");

while (1) {
Serial.println("looping");
delay(1000);
}
}

void loop() {

unsigned long currentMillis = millis();

// Check if it's time to change the colour
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;

// Change the colour based on currentColor index
if (currentColor == 0) {
writeEasyNeoPixel(0, 10, 0, 0); // Red
currentColor = 1;
}
else if (currentColor == 1) {
writeEasyNeoPixel(0, 0, 10, 0); // Green
currentColor = 2;
}
else if (currentColor == 2) {
writeEasyNeoPixel(0, 0, 0, 10); // Blue
currentColor = 0;
}
}

}

[lbernstone]

Your code works fine if I remark out the Neopixel stuff. Try using the RMT based RGB driver in the arduino core.

[stevenbennett]

Thanks for that, yes it works without the Neo Pixel stuff - I wonder why. More seriously if I then add another task it starts doing the constant rebooting again, could you try this code:

void setup() {

xTaskCreate(printTask, "print_task", 5000, NULL, 1, NULL);

xTaskCreate(flashTask, "flash_task", 5000, NULL, 1, NULL);

}

void printTask(void *pvParameter)
{
Serial.begin(115200);
delay(100);
Serial.println("Hello World");

while (1) {
Serial.println("looping");
delay(1000);

}
}

void flashTask(void *pvParameter)
{
digitalWrite(RGB_BUILTIN, HIGH); // Turn the RGB LED white
delay(1000);
digitalWrite(RGB_BUILTIN, LOW); // Turn the RGB LED off
delay(1000);
}

void loop() {

}

I get this output on the serial port:

ELF file SHA256: 0d551d4e0bef4d54

Rebooting...
�ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403773f1
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3818,len:0x109c
load:0x403c9700,len:0x4
load:0x403c9704,len:0xb50
load:0x403cc700,len:0x2fd0
entry 0x403c98ac
Hello World
looping
looping
E (4126) FreeRTOS: FreeRTOS Task "flash_task" should not return, Aborting now!

abort() was called at PC 0x4037e283 on core 0

Backtrace: 0x40376dde:0x3fcf6d40 0x4037b7b5:0x3fcf6d60 0x40381211:0x3fcf6d80 0x4037e283:0x3fcf6e00

ELF file SHA256: 0d551d4e0bef4d54

Rebooting...

[Basalt]

Don't know if it makes any difference, but I would expect the Serial.start() be part of the setup(), like this:

Code: Select all

void setup() {

	Serial.begin(115200);
	delay(100);
	Serial.println("Hello World");

	xTaskCreate(printTask, "print_task", 5000, NULL, 1, NULL);

	xTaskCreate(flashTask, "flash_task", 5000, NULL, 1, NULL);
}

void printTask(void *pvParameter)
{
	while (1) {
		Serial.println("looping");
		delay(1000);
	}
}

[...]

[stevenbennett]

Yes thanks, you are correct that serial begin works if put into setup and should be there as it only needs invoking once. However it makes no difference to the problem, I had, of running one or two tasks. I have eventually got some code to run correctly with two tasks, but I can not see how there is any difference, in terms of task creation and implementation, from my earlier code that failed. The following works OK:

void setup() {

Serial.begin(115200);

xTaskCreate(printTask, "print_task", 5000, NULL, 1, NULL);

xTaskCreate(flashTask, "flash_task", 5000, NULL, 1, NULL);

}

static void printTask(void *pvParameter)
{
while (1) {
Serial.println("printing");
vTaskDelay(2000 / portTICK_PERIOD_MS); // Delay for 2000mS
}
}

static void flashTask(void *pvParameter)
{
while (1) {
//Serial.println("flashing");
//delay(1000);

digitalWrite(RGB_BUILTIN, HIGH); // Turn the RGB LED white
vTaskDelay(500 / portTICK_PERIOD_MS); // Delay for 500mS
digitalWrite(RGB_BUILTIN, LOW); // Turn the RGB LED off
vTaskDelay(500 / portTICK_PERIOD_MS); // Delay for 500mS
}
}

void loop() {

}

[Basalt]

Now you are using vTaskDelay() instead of delay()
I'm doing the same in my code (not sure why anymore )

[stevenbennett]

As I understand things delay() is a blocking function on simple MCUs like ATMega328s so some other things cannot happen until it completes, that's why it's recommended to use the Millis delay method for UNOs and NANOs. On a multi-core ESP32 MCU running RTOS I don't think it makes any difference as I have read that using delay() in ESP32 code simply calls the non-blocking vTaskDelay() anyway. So I tend to err on the safe side and use vTaskDelay() and not delay() even though I suspect it makes no difference. If anyone knows the precise details of vTaskDelay() versus delay() please comment as I'm sure many would like to know the answer.

[boarchuz]

https://github.com/espressif/arduino-es ... #L202-L204

[stevenbennett]

Ah ha, thankyou, I was not aware of this resource

[Basalt]

Now you are using vTaskDelay() instead of delay()
I'm doing the same in my code (not sure why anymore )

Probably I did it because of consistency in this environment ("more rtos") but obviously it's exactly the same.