Kosmetikmeldung aus der Entwickler-Ecke:
Der neue Compiler ist ja sehr penibel geworden und meckert Alles an.
Die Warnmeldungen haben wir jetzt etwas reduziert. Auschecken & evt. ein Clean-All durchführen da auch einige Bibliotheken aktualisiert wurden:
Schönen Abend!
Den Fehler mit ST5G konnte ich auch nicht nachstellen. Bei mir funktioniert die Accesspoint Seite wie erwartet.
Ich habe den crash kurz zurück verfolgt. Der interrupt Handler wird hier in FastLED registriert:
Der Schuldige ist (wahrscheinlich) das Flag ESP_INTR_FLAG_IRAM. Wenn das Flag an esp_intr_alloc übergeben wird, müssen alle Funktionen im IRAM sein. Sonst:
If a function or symbol is not correctly put into IRAM/DRAM, and the interrupt handler reads from the flash cache during a flash operation, it will cause a crash due to Illegal Instruction exception (for code which should be in IRAM) or garbage data to be read (for constant data which should be in DRAM).
Da werden wir wohl beim Booten hinein laufen (da ja in dem Code von @tueddy einige Funktionen nicht im IRAM sind). Wir könnten versuchen den Flag zu löschen (müssten wir testen, ob das mit dem Flash-Cache jitter zusammen spielt).
Aber eine fehlerhafte LED Ausgabe ist sicherlich besser als ein Neustart.
@laszloh Danke für Deine Bug-Analyse!
Die geänderte FastLED-Bibliothek ist ja nur eine temporäre Krücke um weiterhin alle Funktionen compilierbar zu halten. Eine langfristige Lösung wäre Arduino als Komponente, aber das ist noch nicht soweit.
Bislang hat die „Krücke“ funktioniert, aber anscheinend speziell Im AP-Modus kann es zu diesem Fehler kommen.
Aber eine fehlerhafte LED Ausgabe ist sicherlich besser als ein Neustart.
Das sehe ich auch so, zumal der AP-Modus nur einmal ausgeführt wird. Könnte man dort einen Fix anwenden z.B. die LED’s kurzzeitig stummschalten?
Also tatsächlich ist mir unklar, warum das Static-Geraffel (offenbar?) aktiviert war. Mindestens mal absichtlich habe ich das nicht aktiviert. Aber es ändert nix: Ich kann mich weiterhin nicht an meinem WLAN anmelden.
[ 2259 ] WLAN mit SSID ST5G und Signalstärke -45 auf Kanal 11 gefunden.
[ 2260 ] WLAN mit SSID WLAN-375703 und Signalstärke -88 auf Kanal 1 gefunden.
[ 2270 ] WLAN mit SSID FRITZ!Box 7412 und Signalstärke -88 auf Kanal 1 gefunden.
[ 2270 ] WLAN mit SSID ST5G und Signalstärke -88 auf Kanal 1 gefunden.
[ 2319 ] Versuche mit WLAN 'ST5G' zu verbinden...
[ 7448 ] Versuche mit WLAN 'ST5G' zu verbinden...
[ 10003 ] Aktuelle Batteriespannung: 3.23 V
[ 10005 ] Aktuelle Batterieladung: 18.72 %
[ 10007 ] Batterieladung niedrig
[ 12578 ] Versuche mit WLAN 'ST5G' zu verbinden...
[ 17707 ] Versuche mit WLAN 'ST5G' zu verbinden...
[ 22843 ] WLAN-Verbindung fehlgeschlagen.
[ 23353 ] Access-Point geöffnet
[ 23353 ] IP-Adresse: 192.168.4.1
[ 23356 ] HTTP-Server gestartet.
Kannst du folgendes Code-Schnipsel in Wlan.cpp, Zeile 143 (connectToKnownNetwork, vor WiFi.begin()) einfügen und die Ausgabe überprüfen?
Serial.printf("SSID: %s [%d]\n", settings.ssid, strlen(settings.ssid));
Serial.printf("PASS: %s [%d]\n", settings.password, strlen(settings.password));
Serial.printf("STATIC: %d\n", settings.use_static_ip, strlen(settings.use_static_ip));
Achtung, der Code schreibt das WiFi Passwort unverschlüsselt in die Konsole, am Besten die Ausgabe nicht 1:1 kopieren.
Vor allem interessant ist, ob die Länge des SSID & Password den Eingaben entsprechen (es dürft da keine Unterschiede geben; bei mir mit einem 16 Zeichen langen Passwort hatte das problemlos funktioniert).
Blöde Nebenfrage, ist ST5G vielleicht ein 5GHz WiFi?
Ich würde fast den Weg gehen den Flag beim RMT-Treiber direkt raus zu nehmen. Das Problem könnte theoretisch bei jedem Flash Schreibzugriff (also bei jedem Aufruf von NVS write bei uns) auftreten. Es muss nur einmal der Interrupt blöd liegen.
Den Code ohne ESP_INTR_FLAG_IRAM habe ich seit gestern auf meiner Test-Box aktuell am Laufen. Scheint bis jetzt keine Probleme zu machen. Ich kann aber gerne länger laufen lassen und berichten 
Es ist zwar schon ne Weile hier, aber ich habe hier schon „bisschen“ Kram programmiert und mir ist daher schon klar, was der Code macht 
. Aber ja: Vorbeugen ist besser, als auf die Füße zu kotzen, hrhr.
Jut, mache ich später mal.
Nein, ist es nicht. Das hat ein N hinten statt nem G.
@biologist Wir wollen Dich ja eigentlich nicht für’s Testen einspannen 
Aber Dein WLAN ist jetzt das Einzige welches jetzt nicht funktioniert. Ich konnte den Fall auch nicht nachstellen.
Evt. wäre es hilfreich mit -DCORE_DEBUG_LEVEL=5 das Log auszuwerten? Dann hätte man die Ursache.
@laszloh Dann crasht der Code u.a. beim Schreiben von Einstellungen ins NVS? Ich werde das auch mal ohne dieses Flag laufen lassen und schauen das nichts flackert.
Schon gut. Ist für mich mal ne völlig neue Perspektive, hier als User zu agieren und meine Probleme zu posten, die dann Andere lösen sollen
Neue Runde aus dem DEV-Branch:
@laszloh 's Fix für FastLED habe eingebaut und habe keinen Crash mehr, auch die LED’s laufen wie gewünscht. Zudem wurden einige Warnmeldungen beim Compilieren & zur Laufzeit reduziert. Einen „Clean All“ vor dem Build würde ich empfehlen.
Evt. findet sich auch ein iInterressierter Neuling der z.B. diese Warnmeldungen fixen kann? Natürlich mit dem richtigen Code-Style
DEV branch wirkt bis jetzt Prima.
Müßte jedoch 4x Neustarten nach einem 1. Upload damit alles richtig lauft und die Web-oberflach Stabil zu benutzen ist.
Gilt auch beim Main branch.
P.s. Habe Mqtt.cpp geändert. ifdef und endif dazu…
Weiß nicht genau ob das jetzt richtig ist.
Hab noch kein MQTT server eingerichtet zum testen.
Kein Zeit am moment.
// MQTT
static bool Mqtt_Enabled = true;
#ifdef MQTT_ENABLE
static void Mqtt_ClientCallback(const char *topic, const byte *payload, uint32_t length);
static bool Mqtt_Reconnect(void);
static void Mqtt_PostWiFiRssi(void);
#endif
Tatsächlich kann ich das Problem gerade nicht nachstellen. Ich muss das nochmal testen, wenn ich einen komplett jungfräulichen ESP32 habe. Ich hatte beim Upload allerdings das Problem (auch nach einen Neustart), dass die Uploadraten zweistellig waren. Ich kann mir das iwie nur so erklären, als dass sich die Möhre in einen anderen AP einbucht. Schlauer wär’s gewesen, den Router zu nehmen, weil der steht auf dem gleichen Tisch nur 0,5 m entfernt.
Warnmeldungen sind damit gefixt, manchmal kann das Leben auch ganz einfach sein!
Stabil bei mir:
platformio.ini
platform = espressif32@^6.3.1
Last error is from a dependend Lib.
MFRC522Extended.cpp
Error message:
.pio/libdeps/lolin_d32_pro_sdmmc_pe/MFRC522/src/MFRC522Extended.cpp:824:29: warning: ordered comparison of pointer with integer zero [-Wextra]
if (backData && (backLen > 0)) {
^
.pio/libdeps/lolin_d32_pro_sdmmc_pe/MFRC522/src/MFRC522Extended.cpp:847:30: warning: ordered comparison of pointer with integer zero [-Wextra]
if (backData && (backLen > 0) {
Problem here is that the formula is incomplete. backData is not defined.
Would be an error I´d make… 
I suspect it should be: backData > 0
And we can safely assume it will not be a negative value…then option 2 is a better choice
Option 1:
if ((backData > 0) && (backLen > 0)) {
Option 2:
if ((backData != 0) && (backLen != 0)) {
@SZenglein Alle Boards, die ich hier rausschicke, teste ich vorher. Vor ner Weile habe ich immer ein Flash Erase im Anschluss gemacht, da ich meine WLAN-Zugangsdaten ja nicht weitergeben will. Inzwischen spare ich mir das und überschreibe die WLAN-Zugangsdaten mit Nonsense und speichere das dann ab. Im DEV-Branch ist mir da Folgendes aufgefallen wenn man auf den WLAN-Tab klickt:
a) Als WLAN steht ganz oben „-1“. Ist das so beabsichtigt?
b) Das letzte WLAN zu löschen hat irgendwie nicht funktioniert. D.h. der ESPuino hat sich nach dem Löschen erneut im WLAN angemeldet.
Kann man jetzt drüber diskutieren, ob das ein Anwendungsfall ist, den man wirklich braucht. Aber fiel mir auf jeden Fall auf.
Ich finde jetzt nicht, dass das ein diskutabler Anwendungsfall ist. Dass ist für mich schlichtweg ein Bug, der so nicht auftreten sollte.
Alle Netze zu löschen ging eigentlich in meinen Tests, ggf. hat sich hier etwas verändert, als @tueddy das memcopy durch ein std::copy ersetzt hat.
Du machst aber hier auf etwas aufmerksam, was eine gute Idee ist: sicheres Löschen von Passwörtern. Ich schätze die Daten im NVS werden nicht gelöscht, wenn ein kleineres Array geschrieben wird; vielleicht sollte erst mit Nullen überschrieben werden…
Ich würde mir das anschauen, bin aber die nächsten zwei Wochen zeitlich gebunden…
Nonsense ist auch eine Prima lösung.
Ich mache nach dem Testen (DEV branch) auch.
Da sollte es nach Neustart beim anmelden im WLAN ein Anmeldungs Fehler geben.
Und danach Flash ´erase´ bevor ich wieder zu ´Main´ wechsel.
Der ´-1´ hab ich auch gesehen. Stört irgendwo nicht mit den Funktionalität. Und ist zu ´korrigieren´ im Webconsole.
Also das „-1“ tritt im dev-branch oder master auf? Weil im master kann ich das ja schlecht beheben 
.
Das tritt nur bei dev auf.
Meint Ihr diese Einstellung?
Das Problem war mir auch aufgefallen & @SZenglein hat das wohl bereits gefixt:
Sieht auf den ersten Blick gut aus, werde das die nächsten Tage testen. Schaut doch auch einmal drüber.
P.S.: Beim Löschen eines WLAN’s das im NVS gespeicherte Kennwort zu überschreiben halte ich für eine gute Idee!
