ESP32 Forum

Posted: **Wed Jun 30, 2021 9:44 am**

I have observed that downloading of files >150k crashes my ESP32-WROOM-32E at about every 2nd(!) attempt triggered by a Watch-Dog-Timer firing. After a lot of struggle and tests with other ESP32s, I found that this happens when Flash from one specific manufacturer is used in the ESP device. This final result is shown here https://github.com/me-no-dev/ESPAsyncWe ... -869516169

This manufacturer's ID is 0x68. Looking though ESP-IDF source code files I found this is Boya/Bohong Microelectronics https://github.com/me-no-dev/ESPAsyncWe ... -870580168

Other manufacturers, whose Flash behaved perfectly or at least almost perfectly had ID 0xc8 (GigaDevice) and 0x20 (Unknown).

The code for handling flash in the idf is in folder esp-idf/components/spi_flash. This folder is not present under Arduino framework - I guess the code is in its pre-compiled libs.

What I am wondering are two things:

are the WDT crashes due to a bug in the code, or does the hardware of Boya/Bohong Microelectronics have a principle defect?

how can I make sure to buy only devices with flash from manufacturer with IDs 0xc8 or 0x20, since I do not see the type of flash used listed anywhere?

Posted: **Wed Jun 30, 2021 10:15 am**

What hardware are you using? If you are making your custom boards, you can use the same flash chips used with WROOM-32 series.
Also, make sure that the flash voltage levels are correct, you get a lot of chips acting weird if you run them at 1.8V instead of 3.3V.

It would be a good idea to just use flash that is known to work. This seems like a case of an incompatible flash chip if different versions of Arduino still give you same error.

Posted: **Thu Jul 01, 2021 1:32 am**

Interesting. I see that this is using spiffs, do you also get this error if you use other filesystems (e.g. fatfs)? Asking because as far as I remember, reading flash should happen with the same latency on all devices; it's erasing and writing flash that can take a variable amount of time, and that could theoretically trigger the wdt depending on the type of flash installed. Spiffs might or might not write to flash when you do a read, I don't know, but I'm pretty sure fatfs doesn't.

Posted: **Thu Jul 01, 2021 8:55 am**

I used only assembled ESP32 DevKits. The worst of the pack, as you see in the linked-to table was an "Original", "Espressif" labelled device with the latest ESP32-WROMM-32E (revision 3)!

Actually, the data in the table were all created with the FFat file system. However, I have also tested SPIFFS and LittleFS. With respect to the WDT triggered crashing the result was the same for all devices!

But since you mention speed, I found something strange. In the setup of the ESPAsyncWebserver I use this command:

Code: Select all

gWebServer.on("/download/uc1/*", HTTP_GET, [](AsyncWebServerRequest* request){
    auto t0 = micros();
    cSF(path, 100);
    path.printf("%s/%s", DATA_PATH, (request->url().substring(request->url().lastIndexOf("/") + 1U)).c_str());

    countOfDownloads++;
    if (request != nullptr) request->send(*myFS, path.c_str(), String(), TREATMENT);  // TREATMENT: Download or Display
    else                    log_e("uc1 -- #%u - %s  REQUEST is NULLPTR!", countOfDownloads, path.c_str());               
    auto t1 = micros();

    float dur = (t1 - t0)/1000.0f;
    log_i("uc1 -- #%u - %s  dur: %0.2f ms  core: %i  countOfBoots: %i", countOfDownloads, path.c_str(), dur, xPortGetCoreID(), countOfBoots);        
});

It allows me to determine the duration of the time needed to execute the 'request->send(...)' command. It results in:

SPIFFS: 11 ms
FFat: 26 ms
LittleFS: 44 ms

Why is there a 2fold or even 4fold difference for this command in the webserver? It has nothing to do with the duration of the download, which is a minimum of 800 ms and can be several 10000 ms, i.e. much, much longer than this command.

I am puzzled, but this is only an aside to the WDT crashing problem.

ESP32 Forum

Bad Flash or bad code responsible for big-file-download crashes?

Bad Flash or bad code responsible for big-file-download crashes?

Re: Bad Flash or bad code responsible for big-file-download crashes?

Re: Bad Flash or bad code responsible for big-file-download crashes?

Re: Bad Flash or bad code responsible for big-file-download crashes?