My ESP32 async web server sketch works fine with 2-3 placeholders. As I add a few more placeholders on the webpage, it causes the esp to restart when loading the webpage from time to time. The more placeholders that I add, the worse the problem gets. At 24 placeholders, loading the webpage will cause the esp to restart more than half the time.
When the webpage doesn't fully load and the ESP32 restarts, the serial monitor shows the following error:
So as far as I can tell, the large number of placeholders that the string processor is handling is causing a watch dog error. But I am not clear about what that is and how to avoid it.
If I comment out most of the lines of the string processor, everything works perfectly except, of course, the placeholders on the webpage don’t get replaced with their respective SPIFFS data.
Any suggestion how to solve this? (Sorry if this is a dumb question; I'm a beginner at this stuff)
The problem is not the number of placeholders. I have apps with hundreds. You are doing something wrong, most likely in string handling, and causing a memory exception.
You need to use the ESP32 exception decoder and see WHAT, and WHERE the EXACT failure is, rather than making random guesses.
The error message I’m getting is shown in my post. If I paste that error into the error decoder, nothing happens, i.e. no decoding. This error message seems different than the typical backtrace kind of error which can be decoded.
I thought it might be that SPIFFS was too small, so I changed the partition to 2MB app/2MB Spiffs, and recompiled the sketch. But the restarting problem got even worse.
So my guess is that larger spiffs is increasing the time needed to access it and return values for the placeholders. This extra time is somehow triggering the watchdog and causing a restart.
No, no, and no. As I said, you can have hundreds of placeholders, so your problem is elsewhere. For one thing, you seem to be using very long filenames. AFAIK, SPIFFS supports ONLY 8.3 filenames. That could well be your problem.
Firstly, it was not SPIFF file names being too long. I did some tests with 30 character long file names in a clean new web server sketch, and there were not problems. Good to know though that I should keep an eye on these things in the future. I may go through and shorten them all after I have this current problem sorted out.
So, here's the half answer: My sketch is also running a BLE scan at the same time as the web server is running. If I comment out the BLE scan code, then the web server behaves perfectly. No restarts at all, even reloading the page 20 times in a row.
Actually, I don't really mind if the BLE scan stops while the web server is being used. I just don't know how to make this happen in the sketch. Is there some way to shut down other processes when the web server is accessed? Maybe a different type of "blocking web server"?
I suspect if you try two filenames where the first 8 characters of the name are the same, you will find one of them disappears. I believe the names get truncated to 8.3 by the SPIFFS code.
I've never used the bluetooth on ESP32, so I don't know what could be causing that problem. But likely something is simply tying up the processor too long. What is YOUR code doing with the bluetooth?
How long does it run before surrendering control back to the OS? You MUST NOT tie up the ESP32 processor for long periods of time. EVER! That is precisely what causes watchdog errors. If you must execute a long process, and I would question that you "must", then you MUST periodically surrender control with a yield() or delay(1).
In my sketch, the BLEScan() gets called in the void loop(). I temporarily added a "scanning" serial print to see how fast this is looping and it looks to be about 1 second:
