Network Connectivity Fails with Latest ESP32-HUB75-MatrixPanel-DMA Library Update

[Stdorn01]

Description: After updating to the latest version of the ESP32-HUB75-MatrixPanel-DMA library, my ESP32-S3 N16R8 setup experiences network connectivity issues. The setup initially connects successfully, but network requests start failing intermittently and eventually completely. Rolling back to the previous version resolves the issue.

Steps to Reproduce:

Update to the latest version of the ESP32-HUB75-MatrixPanel-DMA library.

Run the code that initializes the matrix display and makes periodic HTTP requests.

Observe the network connectivity failing after a short period (less than 1 min).

Expected Behavior: The setup should maintain stable network connectivity and successfully send HTTP requests without intermittent failures or reboots.

Observed Behavior:

Initial successful network connection and HTTP requests.

Intermittent HTTP request failures followed by complete network failure.

Environment:

ESP32-S3 N16R8

Latest version of ESP32-HUB75-MatrixPanel-DMA library

Arduino IDE

Relevant Logs:

23:13:22.800 -> Free heap: 109612 bytes
23:13:22.800 -> Task high watermark: 5588 bytes
23:13:22.800 -> Uptime: 45152 milliseconds
23:13:32.832 -> Current time: 05:13:31
23:13:32.832 -> RSSI: -37 dBm
23:13:32.832 -> Sending HTTP request to local server...
23:13:37.848 -> HTTP Response code: -1
23:13:37.848 -> Error code: -1
23:13:37.848 -> Sending HTTP request to example server...
23:13:44.235 -> HTTP Response code: -11
23:13:44.235 -> Error code: -11
23:13:54.215 -> Current time: 05:13:53
23:13:54.215 -> RSSI: -37 dBm
23:13:54.215 -> Sending HTTP request to local server...
23:13:58.582 -> HTTP Response code: 200
23:13:58.582 -> Received payload: ...
23:13:58.582 -> Sending HTTP request to example server...
23:14:03.631 -> HTTP Response code: -1
23:14:03.631 -> Error code: -1
Possible Causes:

Memory Issues: Free heap memory remains stable, suggesting memory fragmentation or depletion might not be the primary cause. However, there could be an issue with how the library manages memory, leading to instability over time.

Concurrency and Task Yielding: Frequent task yields (delay(0)) have been added to allow background processes to run efficiently, but the issue persists.

Library-Specific Bug: The problem started occurring after updating to the latest library version, indicating a possible bug introduced in the update affecting the network stack or its interaction with the matrix operations.

Additional Notes:

Im very new to programing but I don't think I'm doing anything wrong. My code ran without error for 2 months. rolling back to 3.0.10 resolves the network issues.

The test at end of post appears to cause the same failure as my code. it checks a local air sensor and a nonlocal webpage in a loop. Upon boot both servers respond as expected but within 1-3 loops 1 or both will fail then both at which point no communication is possible via WIFI until reboot at which time the issue repeats.

Any insights or fixes from the library maintainers would be greatly appreciated.

I also seem unable to enable psram without entering a boot loop as soon as sketch starts. I get lines and dashes on matrix and it reboots. This does not seem to be version specific. I may be doing something wrong but I cant figure out what.

"#include <WiFi.h>
#include <HTTPClient.h>
#include <ESPmDNS.h>
#include <WiFiUdp.h>
#include <ArduinoOTA.h>
#include <NTPClient.h>
#include <ESP32-HUB75-MatrixPanel-I2S-DMA.h>
#include <ArduinoJson.h>

// Constants
const char* ssid = "";
const char password = "";
const char urlOutside = "http://10.0.0.187/JSON";
const char urlExample = "http://www.example.com";

WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP, "pool.ntp.org", 0, 60000);
MatrixPanel_I2S_DMA *dma_display = nullptr;

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

// Connect to WiFi
Serial.println("Connecting to WiFi...");
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(500);
}
Serial.println("\nWiFi connected.");
Serial.printf("RSSI: %d dBm\n", WiFi.RSSI());

// Start OTA
ArduinoOTA.begin();

// Start NTP client
timeClient.begin();

// Setup matrix display
setupMatrixDisplay();

Serial.println("Setup complete.");

}

void loop() {
// Handle OTA
ArduinoOTA.handle();

// Update NTP time
timeClient.update();
Serial.print("Current time: ");
Serial.println(timeClient.getFormattedTime());

// Check WiFi connection
if (WiFi.status() != WL_CONNECTED) {
    Serial.println("WiFi not connected. Reconnecting...");
    WiFi.begin(ssid, password);
    while (WiFi.status() != WL_CONNECTED) {
        Serial.print(".");
        delay(500);
    }
    Serial.println("\nWiFi reconnected.");
} else {
    Serial.printf("RSSI: %d dBm\n", WiFi.RSSI());
}

// HTTP request to local server
Serial.println("Sending HTTP request to local server...");
httpRequest(urlOutside);

// HTTP request to example server
Serial.println("Sending HTTP request to example server...");
httpRequest(urlExample);

// Print free heap memory
Serial.printf("Free heap: %d bytes\n", ESP.getFreeHeap());

// Check task stack high water mark
TaskHandle_t currentTask = xTaskGetCurrentTaskHandle();
Serial.printf("Task high watermark: %d bytes\n", uxTaskGetStackHighWaterMark(currentTask));

// Print uptime
Serial.printf("Uptime: %lu milliseconds\n", millis());

// Wait before repeating the loop
delay(20000); // Reduced frequency of loop

}

void setupMatrixDisplay() {
HUB75_I2S_CFG mxconfig(128, 64, 2);
mxconfig.gpio.r1 = 42;
mxconfig.gpio.g1 = 41;
mxconfig.gpio.b1 = 40;
mxconfig.gpio.r2 = 38;
mxconfig.gpio.g2 = 39;
mxconfig.gpio.b2 = 37;
mxconfig.gpio.a = 45;
mxconfig.gpio.b = 36;
mxconfig.gpio.c = 48;
mxconfig.gpio.d = 35;
mxconfig.gpio.e = 21;
mxconfig.gpio.lat = 47;
mxconfig.gpio.clk = 2;
mxconfig.gpio.oe = 14;

dma_display = new MatrixPanel_I2S_DMA(mxconfig);
dma_display->begin();
dma_display->clearScreen();
dma_display->setTextColor(dma_display->color565(255, 255, 255));
dma_display->setCursor(10, 10);
dma_display->print("Matrix Initialized");

}

void httpRequest(const char* url) {
HTTPClient http;
http.begin(url);
int httpResponseCode = http.GET();
Serial.printf("HTTP Response code: %d\n", httpResponseCode);
if (httpResponseCode > 0) {
String payload = http.getString();
Serial.println("Received payload:");
Serial.println(payload);
} else {
Serial.printf("Error code: %d\n", httpResponseCode);
Serial.printf("HTTPClient Error: %s\n", http.errorToString(httpResponseCode).c_str());
}
http.end();

// Yield to the system frequently
delay(0); 

}
"

[j-g00da]

It's just a guess looking at the diff, but have you tried changing i2sspeed to HZ_15M? That was the default previously.
No idea why that would cause the issue but from what I see, it's the only thing in diff that would influence your code on ESP32-S3.

[j-g00da]

Oh and there is also #include "esp_heap_caps.h" in the main header file, this in theory can have some side effects.
I think it's unnecessary and should be moved to /esp32s3/ and /esp32c6/, where it is actually used.
Let me know what you think.
9b2dd8f#diff-dbad1632870c6b5ffc152f71f3f9610eebd2ae296cc63aa7e4572b1043e3cde2R10
@Lukaswnd
@mrcodetastic

[Stdorn01]

Hi,

Thank you for your quick response and suggestions. I apologize for taking a while to test and get back to you.

Test Setup: I have a similar setup where my code connects to multiple local servers to fetch air quality data. After updating to the latest version of the ESP32-HUB75-MatrixPanel-DMA library, I encountered network connectivity issues. Here's a summary of the behavior observed with the modified library:

Behavior with Modified Library:

Initial Improvement: The network failures now take longer to occur, and the failures are intermittent rather than permanent once they start occurring. This is an improvement compared to the unmodified library where the network failed completely and permanently within 15-45 seconds.

Intermittent Failures: The network issues are still present. After a few minutes, HTTP requests start to fail intermittently. Initially, some servers fail to respond for a few minutes up to 10ish minutes but then recover, only to have other servers fail. Eventually, all servers fail but will intermittently recover.

Relevant Log Snippet:

18:33:08.013 -> [278306][D][HTTPClient.cpp:378] disconnect(): tcp keep open for reuse
18:33:08.111 -> Free heap: 110388 bytes
18:33:08.111 -> Task high watermark: 5552 bytes
18:33:08.111 -> Uptime: 278321 milliseconds
18:33:28.647 -> Current time: 00:33:27
18:33:28.647 -> RSSI: -52 dBm
18:33:28.647 -> Sending HTTP request to local server...
18:33:28.680 -> [298870][V][HTTPClient.cpp:242] beginInternal(): url: http://10.0.0.187/JSON
18:33:28.680 -> [298884][D][HTTPClient.cpp:293] beginInternal(): protocol: http, host: 10.0.0.187 port: 80 url: /JSON
18:33:32.359 -> [302571][V][HTTPClient.cpp:1201] handleHeaderResponse(): RX: 'HTTP/1.1 200 OK'
18:33:32.391 -> [302607][D][HTTPClient.cpp:1257] handleHeaderResponse(): code: 200
18:33:32.427 -> HTTP Response code: 200
18:33:32.427 -> Received payload:
18:33:32.461 -> {"Temperature":31.16199,"Humidity":59.99991,"Dew Point":22.51874,"TVOC":750,"eCO2":934,"AQI":4,"Sensor Status":0,"RSSI":-59}
18:33:32.461 -> [302660][D][HTTPClient.cpp:393] disconnect(): tcp is closed
18:33:32.461 -> Sending HTTP request to example server...
18:33:32.497 -> [302885][D][NetworkManager.cpp:127] hostByName(): DNS found IPv4 23.215.15.41
18:33:34.862 -> [305078][D][HTTPClient.cpp:1112] connect(): connected to www.example.com:80
18:33:39.878 -> [310097][D][HTTPClient.cpp:618] sendRequest(): sendRequest code=-11
18:33:39.920 -> HTTP Response code: -11
18:33:39.920 -> Error code: -11
18:33:39.920 -> HTTPClient Error: read Timeout
18:33:39.920 -> Free heap: 109648 bytes
18:33:39.920 -> Task high watermark: 5552 bytes
18:33:59.928 -> Current time: 00:33:58
18:33:59.928 -> RSSI: -56 dBm
18:33:59.928 -> Sending HTTP request to local server...
18:34:04.312 -> [334529][D][HTTPClient.cpp:1112] connect(): connected to 10.0.0.187:80
18:34:09.311 -> [339538][D][HTTPClient.cpp:618] sendRequest(): sendRequest code=-11
18:34:09.344 -> HTTP Response code: -11
18:34:09.344 -> Error code: -11
18:34:09.344 -> HTTPClient Error: read Timeout
Summary:

Removing the esp_heap_caps.h include has improved the situation, making network failures less frequent and more intermittent.

Despite this improvement, the network issues persist, leading to intermittent and eventually complete network failures after a few minutes.

Any further suggestions or insights into resolving this issue would be greatly appreciated.

Im surprised I haven't seen any other complaints of network issues since the latest release surely this effected more people than just me?.

Thanks again for your help.

[Stdorn01]

I forgot to mention it I also returned i2sspeed to HZ_15M.

[j-g00da]

I forgot to mention it I also returned i2sspeed to HZ_15M.

Can you test with only HZ_15M i2sspeed and another test with only esp_heap_caps.h removed? So we can tell which one improved the situation a bit.

[Lukaswnd]

@j-g00da the compare should be something like that:
3.0.10...3.0.11
and the #include "esp_heap_caps.h" is needed in the ESP32-HUB75-MatrixPanel-I2S-DMA.h

But the only differences that could make any differences are related to the i2sspeed. So changing that might help.
Eventhough I haven't and can't imagine any wifi related issues (yet).

Are you sure that you changed the version of the Hub75 lib? Arduino-esp32 has the same version numbers at the moment. And this would explain wifi issues.

I don't think this is a memory related bug, your logs seem fine about the memory. Maybe use the 'void printRunningTasks(Print &printer);' function to log the tasks, maybe a background task is blocking. Or enable dubug logs in Arduinoide to get more information about wifi.

I have had similar problems once. I spend months figuring them out. I also reverted libraries and switched Hardware and tried a lot of stuff. Eventually I figured out It was the combination of minimally too small power supply and too much stuff between the esp antenna and the WiFi AP. Keep in mind the esp32s3-n16r8 has a diode on it's 5V inputs and converts to 3.3 after the diode, maybe check the voltage and current consumption of the esp.

Did you use a chatGPT for this Issue?

[j-g00da]

@j-g00da the compare should be something like that:
3.0.10...3.0.11

That's what I did, diff I linked is of the commit that added this include, I know it's not a release diff between 3.0.10 and 3.0.11.

I too think it's probably change of i2s speed causing that, but it's weird, especially considering the fact that 3.0.11 lowered the frequency, so it shouldn't increase power consumption... Anyway, it's all pure speculation without testing on hardware.

[mrcodetastic]

There has been discussion about a similar issue either here or in the discussions.

The thinking is it's EMF generated from the DMA signal to the board, interfering with the sensitive WiFi radio stuff.

Some esp32 boards have worse grounding than others. If I remember correctly, it seems waveshare boards are not good.

This isn't a software matter. Except for changing the clock speed changes the harmonics and it might interfere with the wifi radio less. Pure luck.

Make sure you have as short a trace lengths as possible.

Perhaps driving a led panel directly from the ESP GPIO is not going to work. You'll need to use a buffer chip or something. That might help.

[mrcodetastic]

Are we saying the default clock speed for the s3 in the previous version of the library was better?

I forgot what it was before, but can you tell me what seems to work better? I'll change the default. Perhaps there's some sweet spot.

[sintrb]

I also encountered a similar problem, but after changing the i2sspeed to HZ_15M, I got a significant improvement.