ESP32-S3, wifi disconnects during downloading

[devesp32]

I am experiencing an issue with the ESP32-S3 while downloading a file using the following code:

Code: Select all

WiFiClient* stream = http.getStreamPtr();
stream->readBytes();

The download starts off well, with the first few MB being downloaded quickly and efficiently. However, as the download progresses, the speed drops significantly and eventually, the Wi-Fi disconnects. Initially, the disconnection occurs with the error WIFI_REASON_BEACON_TIMEOUT. The device then attempts to reconnect but immediately disconnects again with the error WIFI_REASON_ASSOC_COMEBACK_TIME_TOO_LONG. At this point, I have to reboot the device to restore normal Wi-Fi functionality.

Parameters:

Code: Select all

WiFi.mode(WIFI_STA);
WiFi.setSleep(false);

esp32 v2.0.14

What could be causing this issue, and how can it be resolved?
Thank you!

[aliarifat794]

Check your router's settings, specifically the DTIM (Delivery Traffic Indication Message) interval. A lower DTIM interval can improve connectivity for IoT devices.

[devesp32]

Check your router's settings, specifically the DTIM (Delivery Traffic Indication Message) interval. A lower DTIM interval can improve connectivity for IoT devices.

aliarifat794, thank you for your involvement!
Unfortunately, my router (Huawei B311-221) doesn't have DTIM or any similar setting. And this problem also happened with other routers I tried in a similar way.
In normal mode (rare exchange of small data) the connection holds up well. But when I start downloading (1-2 Mbps, in two streams), then after a few megabytes Wi-Fi connection drops out.

[MicroController]

The download starts off well, with the first few MB being downloaded quickly and efficiently.

The question is what is different at the start.
Where do those megabytes go? Could you be exhausting some resource (RAM or CPU) by accumulating some stuff over the transfer?

[devesp32]

The question is what is different at the start.
Where do those megabytes go? Could you be exhausting some resource (RAM or CPU) by accumulating some stuff over the transfer?

Thank you for the reasonable question. The data is immediately written to the file, the buffer is in static memory, i.e. the allocation occurs only once. The available memory of the task stack is monitored, its amount is sufficient. The size of the total free heap is also monitored and OK. Subjectively, the CPU is not overloaded, because I do not see any signs indicating this, everything else is performed without lags.

[MicroController]

What file system are you using? Where is it stored? Internal flash?
Do you close and re-open the file repeatedly for appending?

[devesp32]

What file system are you using? Where is it stored? Internal flash?
Do you close and re-open the file repeatedly for appending?

File system is FAT32.
It uses SD NAND as a storage:

SD NAND consists of NAND flash and a high-performance controller. 3.3V supply voltage is required for the NAND area (VCC). SD NAND is fully compliant with SD2.0 interface. Designed in a LGA8 package form. Supports up to 50Mhz.

It opens the file once and then closes it at the end of downloading.
Shortened code version:

Code: [Select all] [Expand/Collapse]

1. HTTPClient httpDl[DL_THREADS];
2. httpDl[threadId].begin(url);
3. int httpCode = httpDl[threadId].GET();
4. static constexpr size_t DL_BUFFER_SIZE = 2760;
5. FsFile filePart;
6. filePart.open(filepartPath.c_str(), O_WRONLY | O_CREAT | O_TRUNC);
7. filePart.preAllocate(filePartSize);
8. WiFiClient* stream = httpDl[threadId].getStreamPtr();
9. while (bytesRecd < filePartSize) {
10.     size_t size = stream->available();
11.     int bytesRead = stream->readBytes(buff, min(size, DL_BUFFER_SIZE));
12.     written = filePart.write(buff, bytesRead);
13. }
14. filePart.sync();
15. filePart.close();
16. httpDl[threadId].end();

GeSHi © Codebox Plus Extension

[MicroController]

Hmm.

Code: Select all

while (bytesRecd < filePartSize) {

Are you sure filePartSize has the correct value?
Do you check for premature end-of-stream?
As I understand it, stream->available() may also intermittently return 0, which may be worth explicitly dealing with, e.g. by a short delay before retrying.

[devesp32]

Are you sure filePartSize has the correct value?

Yes, for now I test on files only that I know the exact size of.

Do you check for premature end-of-stream?
As I understand it, stream->available() may also intermittently return 0, which may be worth explicitly dealing with, e.g. by a short delay before retrying.

It's true, in my full version of this code I do exactly this checking: it retries after some short delay.

I would also like to note that I check the connection status using WiFiEvent_t::ARDUINO_EVENT_WIFI_STA_DISCONNECTED event.