3.1.0 with ESP32 C6 - SimpleTime.ino produces mutex not ready errors

[Daedelos]

Board

M5Stack M5NanoC6

Device Description

None

Hardware Configuration

Nothing

Version

latest master (checkout manually)

IDE Name

Arduino IDE 2.3.4

Operating System

Windows 11

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

115200

Description

3.1.0 with ESP32 C6 - SimpleTime produces mutex not ready errors

Running SimpleTime.ino example under 3.1.0 with a M5NanoC6 (ESP32 C6) produces repeated:

E (50100) OPENTHREAD: esp_openthread_task_switching_lock_acquire(38): Failed to acquire the lock because the mutex is not ready
E (50100) OPENTHREAD: esp_openthread_task_switching_lock_release(46): Failed to release the lock because the mutex is not ready
E (50111) OT_DNS64: Cannot find NAT64 prefix
No time available (yet)

Sketch

Example SimpleTime.ino code

Debug Message

E (50100) OPENTHREAD: esp_openthread_task_switching_lock_acquire(38): Failed to acquire the lock because the mutex is not ready
E (50100) OPENTHREAD: esp_openthread_task_switching_lock_release(46): Failed to release the lock because the mutex is not ready
E (50111) OT_DNS64: Cannot find NAT64 prefix

Other Steps to Reproduce

SimpleTime.ino on M5NanoC6 with 3.0.7 works correctly.
ESP32 & ESP32 S2 work correctly on 3.1.0.

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

@me-no-dev - I confirm the issue.
The error message points to some issue with SDK Config settings related to IPv6 and OpenThread.

[desiFish]

I am getting the same error. Is there any fix to it? I am unable to make HTTP GET calls. Even the Async Server is broken now. Everything seems broken with XIAO ESP32C6 moving from XIAO ESP32C3.
This is my code on ESP32C6:

static WiFiClient client;
  HTTPClient http;

  // Your Domain name with URL path or IP address with path
  http.begin(client, serverName);

  // Send HTTP POST request
  httpResponseCode = http.GET();

  String payload = "{}";

  if (httpResponseCode > 0) {
    Serial.print("HTTP Response code: ");
    Serial.println(httpResponseCode);
    payload = http.getString();
  } else {
    Serial.print("Error code: ");
    Serial.println(httpResponseCode);
  }
  // Free resources
  http.end();

  return payload;

Gives error:

E (3862) OPENTHREAD: esp_openthread_task_switching_lock_acquire(38): Failed to acquire the lock because the mutex is not ready
E (3863) OPENTHREAD: esp_openthread_task_switching_lock_release(46): Failed to release the lock because the mutex is not ready
E (3874) OT_DNS64: Cannot find NAT64 prefix
Error code: -1

[desiFish]

Another Example. While running this program, the same error on XIAO ESP32C6.
Program:

#include <NTPClient.h>
// change next line to use with another board/shield
//#include <ESP8266WiFi.h>
#include <WiFi.h> // for WiFi shield
//#include <WiFi101.h> // for WiFi 101 shield or MKR1000
#include <WiFiUdp.h>

const char *ssid     = "SSID";
const char *password = "PASS";

WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP);

void setup(){
  Serial.begin(115200);

  WiFi.begin(ssid, password);

  while ( WiFi.status() != WL_CONNECTED ) {
    delay ( 500 );
    Serial.print ( "." );
  }

  timeClient.begin();
}

void loop() {
  timeClient.update();

  Serial.println(timeClient.getFormattedTime());

  delay(1000);
}

Error:

E (36035) OPENTHREAD: esp_openthread_task_switching_lock_acquire(38): Failed to acquire the lock because the mutex is not ready
E (36035) OPENTHREAD: esp_openthread_task_switching_lock_release(46): Failed to release the lock because the mutex is not ready
E (36046) OT_DNS64: Cannot find NAT64 prefix

[desiFish]

I can confirm that any kind of network activity, mostly requests are leading to this issue.

[SuGlider]

The issue has been found, but the fix will require a new Arduino release because it is embedded into OpenThread static precompiled library.

We are working to solve it. I'll post the progress in this issue thread.
Fell free to ask about it.

[SuGlider]

Lib Builder PR espressif/esp32-arduino-lib-builder#257 fixes this issue.
A new ESP32 Arduino Release will address and solve the problem.
Thanks for the report!

[desiFish]

@SuGlider Wow, you people are like heroes without the cape of the open-source world. Thank You very much.

[desiFish]

Lib Builder PR espressif/esp32-arduino-lib-builder#257 fixes this issue. A new ESP32 Arduino Release will address and solve the problem. Thanks for the report!

@SuGlider I am new to these things, I explored few things, so a new ESP32 Arduino Release will happen when these milestones are completed right? These: Milestones

[motamman]

I have reproduced this error on all the C6 boards I have laying around. Basically, anytime I use a domain name for anything, it blows up. If I shift to IP addresses, the problem disappears. It makes it a little cumbersome switching back and forth between chips.

[SuGlider]

The issue is directly related to DNS resolution.

ESP32 Arduino will solve it by releasing a new package version that fixes it by removing the OpenThread protocol DNS64 client feature.

This shall be done soon in the beginning of 2025.

At the same time OpenThread IDF Team is investigating the issue in order to fix DNS64 client. When this is solved, we shall reactivate it in the ESP32 Arduino Configuration.

That shall be done by releasing again a new version package.

[SuGlider]

FYI: An IDF fix has been tested and I confirmed that it solves this issue.

Therefore, it will be merged soon to IDF and we will be able to enable back OpenThread DNS64 Client support with no problems related to WiFi DNS Client resolution as here reported.

[SuGlider]

Lib Builder PR espressif/esp32-arduino-lib-builder#257 fixes this issue. A new ESP32 Arduino Release will address and solve the problem. Thanks for the report!

@SuGlider I am new to these things, I explored few things, so a new ESP32 Arduino Release will happen when these milestones are completed right? These: Milestones

I think that a fix release will be released first.
I'll confirm that on the Jan 6th when the team will back from vacation.