I have a larger project that runs an Esp Async Webserver to serve a config interface. All is fine, however sometimes i have to run a timer interrupt that fires every 500ms (this timer runs for about a minute per hour). If a request is sent to the webserver while the timer interrupt is running, there is a conflict that cuases a crash.
Is the easiest way here to just end the webserver and restart it after the timer Interrupt is shut down? Are there other ways?
If so: is a simple server.end(); / server.begin(); going to be enough or do i need to take care of anything else? Unfortunately the documentation on GitHub - me-no-dev/ESPAsyncWebServer: Async Web Server for ESP8266 and ESP32 isn’t exactly verbose in this regard.
As long as it is about the ESP32:
Are you really using a hardware interrupt?
FreeRTOS supports tasks and the ESP32 has two processor cores.
So two things could really be running in parallel here.
It is certainly a simple solution.
Another option would be to research the cause of the conflict and resolve it, which would certainly be more time-consuming.
I have just tested this and it works.
Another solution would be to create and destroy the AsyncWebServer dynamically - and repeat this if necessary.
AsyncWebServer* server = nullptr;
void setupWebServer() {
if (server) return;
server = new AsyncWebServer(SERVER_PORT);
server->on("/", HTTP_GET, [](AsyncWebServerRequest* req){
req->send(200, "text/plain", "Hello world");
});
server->begin();
Serial.println("Server started");
}
void stopWebServer() {
if (!server) return;
delete server;
server = nullptr;
Serial.println("Server deleted");
}
Blockquote
As long as it is about the ESP32:
Are you really using a hardware interrupt?
FreeRTOS supports tasks and the ESP32 has two processor cores.
So two things could really be running in parallel here.
yes, so essentially i’m doing this
void IRAM_ATTR onTimer() {
esp_err_t result = esp_now_send(messageHandler.timerReceiver, (uint8_t *) &messageHandler.timerMessage, sizeof(messageHandler.timerMessage));
}
(it’s actually about 50 lines more code because of a bunch of condition checks, setting variables and stuff but nothing that would screw with any other part of the system)
Either the esp_now_send or the webserver or the timer are the culprit.
Another option would be to research the cause of the conflict and resolve it, which would certainly be more time-consuming.
Yes. I posted the coredump here. Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1). Cor - Pastebin.com The cause of the conflict is “somewhere” but unfortunately not really simple to resolve.
Woooo… If that’s an interrupt routine, you shouldn’t do so much complex stuff in it. Interrupt routines should perform its task and exit the routine as fast as possible. So setting a flag here should be the way to go.
Check that flag in your main loop (or by using a queue) and if that flag is set, perform the necessary actions and clear that flag again.
yes, but this one is extremely time critical. the whole idea is that messages are sent out as exactly as possible every 500ms.
The reasoning is that the esp_now stack has this extremely weird bug where message roundtrips usually are somehow accurately the same, but sometimes messages take 4-6ms longer. Ans if you want to exchange a timer you can’t just say "ok, here’s my timer, deduct the average roundtrip time from that and you’re good, but you need to somehow filter out those glitches.
I mean if you have another great idea how to filter out those glitches i’m all ears 
There is the answer.
The esp_now_send() function is not designed to be called from an ISR.
This starts with the fact that functions that you call from an ISR must also be in located the IRAM. Furthermore, the function is far too complex to be processed within an interrupt.
I think you are placing the required precision on the wrong side here, namely on the transmitter side. But the precision must come from the receiver side.
The transmitter only has to transmit a command, a duration or the number of repetitions and, if necessary, a small delay time (time after the command is to be executed).