ESP32-Wroom32 und Arduino / C-Code verursacht reset

[Alexander W. (Firma: AW-Elektronik) (alexanderwalter)]

Guten Morgen!

Ich versuche gerade mittels ESP32 auf einen Server zuzugreifen und 
diesem über JSON Status zu senden und dabei auch Befehle zu empfangen.

Ich verwende hierfür Arduino IDE v2 und den ESP32-Core 3.3.10 (aktuell).
Getestet habe ich aber auch den Core 2.0.17 sowie 2.0.9

Die Verbindung baue ich über SSL auf. Ich habe einen merkwürdigen 
Fehler, den ich nur durch Falschinitialisierung meines Codes erklären 
kann, diesen Fehler aber nicht finde:

Der ESP resetet sich dabei selbst, wenn er die Funktion:

http.addHeader("Content-Type", "application/json");

aufruft. Kommentiere ich das aus (z.B.: durch ein return; davor), läuft 
der ESP32 stabil. Wichtig: der Reset tritt erst Minuten oder Stunden 
später auf. Die Abfrage erfolgt aber alle 10 Sekunden. Der Heap wird 
auch nicht fortlaufend kleiner sondern stabilisiert sich.

Der Resetcode für CPU0/1 sowie den ESP selbst sind dann 12/12 und 4

Der Server liefert die JSON nur als SSL aus und die json.php loggt mir 
auch die JSON-Frames vom ESP32. Bedeutet für mich, die Verbindung 
funktioniert.

Dabei spielt es keine Rolle ob ich

WiFiClientSecure server_client;
server_client.setInsecure();

setze oder nicht! Hier müsste eigentlich dann keine Daten ausgetauscht 
werden?


Frage:
Könnte jemand über den Code drüber schauen und eventuell einen groben 
Schnitzer sehen der das Verhalten des ESP32 erklärt?

[Harald K. (kirnbichler)]

Das ist kein C, das ist C++.

Abgesehen davon ist es beeindruckend schlechter Stil, sowas in einer 
*.h-Datei unterzubringen.

[Alexander W. (Firma: AW-Elektronik) (alexanderwalter)]

Harald K. schrieb:
> Das ist kein C, das ist C++.
>
> Abgesehen davon ist es beeindruckend schlechter Stil, sowas in einer
> *.h-Datei unterzubringen.

Kannst du mir einen Lösungsweg zeigen?

[N. M. (mani)]

Alexander W. schrieb:
> Harald K. schrieb:
>> Das ist kein C, das ist C++.
>>
>> Abgesehen davon ist es beeindruckend schlechter Stil, sowas in einer
>> *.h-Datei unterzubringen.
>
> Kannst du mir einen Lösungsweg zeigen?

Aufsplitten nach .h/.cpp.
Statische Objekte anlegen. Zumindest für die großen Dinge wie den 
Client, die JSONs usw.
Dann mit init der Objekte arbeiten.

Die Variablen haben im Header auch nichts zu suchen. Beim Intervall 
könnte man drüber streiten wenn es const wäre. Beim 
AskServerpreviousMillis nicht.

Die ganzen If sind auch unnötig. Wenn das erste If schon zuschlägt, 
warum sollte man alle anderen noch prüfen. Beispiel:

if (ChargingType == Solar_Charging)    { requestDoc["Modus"] = "Solar"; }
        if (ChargingType == Night_Charging)    { requestDoc["Modus"] = "Full";  }
        if (ChargingType == Charging_Disabled) { requestDoc["Modus"] = "Off";   }

[N. M. (mani)]

Alexander W. schrieb:
> Der Resetcode für CPU0/1 sowie den ESP selbst sind dann 12/12 und 4

4 ist ne Panic, oder?
Dann wäre Speicher schon ein heißer Kandidat.

Include guards fehlen auch...

[Uwe (uhi)]

Ich hatte ein sehr ähnliches Phänomen neulich. ESP32 mit Arduino, 
schickt alle 10s ein http an einen Server. Das geht ein paar Minuten 
gut, und dann resettet er.
Bei mir ist offenbar die Ursache, dass die Internetverbindung zwischen 
Router und Anbieter ab und zu kurz aussetzt. Das WLAN bleibt stabil 
verbunden.
Die "Standard-Implementierung" der Arduino/ESP-Bibliotheken läuft dann 
offenbar in einen Taskwatchdog.

Wie kann man das lösen? Ich hab die Problembeschreibung in ein Textfile 
gepackt, und dann Claude Opus machen lassen. Der hat dann etwas 
spekuliert, den Code und das serielle Log analysiert, Änderungen 
gemacht, und damit funktioniert es bei mir.

Details hier:
https://github.com/uhi22/accucheck2/blob/main/doc/issues/issue1_resets_after_10_to_15_minutes.md

[Alexander W. (Firma: AW-Elektronik) (alexanderwalter)]

Uwe schrieb:
> Ich hatte ein sehr ähnliches Phänomen neulich

genau deine Beschreibung kommt mir sehr bekannt vor! Wir haben in der 
Tat sporadisch eine "lange Leitung". Aber der ESP-Core sollte doch so 
etwas abfangen können!

N. M. schrieb:
> Aufsplitten nach .h/.cpp.
> Statische Objekte anlegen. Zumindest für die großen Dinge wie den
> Client, die JSONs usw.
> Dann mit init der Objekte arbeiten.

ok, das werde ich dann umsetzen! Der Code ist hier sehr alt (Core 2.0.9) 
und ich baue nun die weiteren Funktionen ein.

N. M. schrieb:
> Die ganzen If sind auch unnötig. Wenn das erste If schon zuschlägt,
> warum sollte man alle anderen noch prüfen. Beispiel:

        if (ChargingType == Solar_Charging)    { requestDoc["Modus"] = "Solar"; }
        if (ChargingType == Night_Charging)    { requestDoc["Modus"] = "Full";  }
        if (ChargingType == Charging_Disabled) { requestDoc["Modus"] = "Off";   }
        if (Timer_Charging == true)            { requestDoc["Timer_Charging"] = "Enabled";  }
        else                                   { requestDoc["Timer_Charging"] = "Disabled

Das habe ich nicht verstanden? Eines der Modi vom Server soll halt 
übernommen werden, damit ich auch aus "der Ferne" die Box schalten kann. 
Nicht nur lokal!

oder meinst du diese Art:

requestDoc["Modus"] =
    (ChargingType == Solar_Charging)    ? "Solar" :
    (ChargingType == Night_Charging)    ? "Full"  :
    (ChargingType == Charging_Disabled) ? "Off"   :
                                          "";

requestDoc["Timer_Charging"] = Timer_Charging ? "Enabled" : "Disabled";

?

[N. M. (mani)]

Alexander W. schrieb:
> Das habe ich nicht verstanden?

Na wenn Modus "Solar" ist, dann kann es nicht mehr "Full" sein, oder?
Also könnte man ein else if draus machen. Dann prüft er die weiteren 
Bedingungen nicht mehr wenn eine true ist.

[Jens K. (jensky)]

N. M. schrieb:
> Alexander W. schrieb:
>> Das habe ich nicht verstanden?
>
> Na wenn Modus "Solar" ist, dann kann es nicht mehr "Full" sein, oder?
> Also könnte man ein else if draus machen. Dann prüft er die weiteren
> Bedingungen nicht mehr wenn eine true ist.

Aber Full oder Off! Lies sein Code noch einmal!