OVMS für den VW e-Up

[dexter]

Das könnte ein "echter" Crash sein, oder ein gewollter Reboot wegen Event-Queue-Überlastung. Das sieht man am Backtrace.

Da ihr einen anderen Build verwendet kann ich eure Backtraces nicht auflösen. D.h. da bräuchte ich von euch die a2l-Ausgabe von, oder ihr könnt da auch selbst mal schauen wo der Crash passiert ist. Falls ihr a2l noch nicht verwendet habt: liegt im support-Verzeichnis, Aufruf für einen aktuellen Build einfach mit Übergabe des Backtraces. Wenn ihr Builds später noch debuggen wollt, archiviert die Datei "build/ovms.elf" und gebt die beim a2l-Aufruf mit an.

Scripts/Plugins sind vermutlich nicht die Ursache (außer sie enthalten Bugs, die zu Endlosschleifen oder sehr langen Scriptlaufzeiten führen). Ich habe diverse Plugins aktiv und mit der aktuellen Version bislang überhaupt keine Crashes mehr. Aber die Herangehensweise, testweise bestimmte Funktionen zu deaktivieren, ist natürlich korrekt. Aber nur wenn ihr die Crashes mit einer zuverlässigen Häufigkeit habt, denn sonst könnt ihr aus "kein Crash" keinen Rückschluss ziehen.

Wie gesagt, im Log findet ihr ggf. noch wichtige Infos. Wenn die Crashes halbwegs reproduzierbar sind lohnt es sich evtl. den allgemeinen Loglevel mal für die Recherche auf "Debug" oder sogar "Verbose" zu stellen.

[dexter]

Zur Klärung: die Event-Queue darf natürlich auch nicht überlastet werden, das ist zwar dann ein gewollter Reboot, aber auch das darf eigentlich nicht passieren. Meine Vermutung ist, dass ein höher priorisierter Prozess aus irgendeinem Grund zuviel CPU-Zeit in Anspruch nimmt.

[sharkcow]

Ich hab mal das CAN-Logging von OVMS angeworfen, da ich mit der Innentemperatur so meine Probleme habe. Wie man sieht stimmt da wirklich was nicht... die meiste Zeit scheint die Formel (d2-100)/2 so grob zu stimmen, aber am Anfang und Ende der Fahrt gibt es eine ganze Reihe völlig falscher Werte.

IdR deuten solche Peaks darauf hin, dass in den oberen Bits noch eine Statusinfo "versteckt" ist, oder ein anderer Messwert in die Bytes hinein ragt. Der Faktor (/2) kann eine Auflösung bedeuten, oder auch, dass Bit 0 wiederum zum nächsten Wert im Frame gehört.

Den sonstigen Verlauf finde ich plausibel, wenn die Klimaanlage anfangs die Innentemperatur herunterkühlen musste, und sie am Ende durch Öffnen der Tür schnell wieder fast auf die Außentemperatur stieg.

Ich glaube ich habe eine (Teil-)Erklärung gefunden für die komischen Temperaturwerte: gerade eben hat OVMS 39° Innentemperatur angezeigt, obwohl es nur noch 25° draußen hat und das Auto unwesentlich wärmer ist innen. Einmal entriegeln und die OVMS-Temperatur war 28°. Also bleibt der Wert auf dem Komfort-CAN wohl stehen wenn das Auto einschläft. Ist ja nachvollziehbar, aber ich hätte das gerne genutzt um am Handy zu sehen ob ich Vorklimatiseren will oder nicht... also müsste man dafür wohl jedes Mal das Auto aufwecken

[sharkcow]

Das könnte ein "echter" Crash sein, oder ein gewollter Reboot wegen Event-Queue-Überlastung. Das sieht man am Backtrace.

Da ihr einen anderen Build verwendet kann ich eure Backtraces nicht auflösen. D.h. da bräuchte ich von euch die a2l-Ausgabe von, oder ihr könnt da auch selbst mal schauen wo der Crash passiert ist. Falls ihr a2l noch nicht verwendet habt: liegt im support-Verzeichnis, Aufruf für einen aktuellen Build einfach mit Übergabe des Backtraces. Wenn ihr Builds später noch debuggen wollt, archiviert die Datei "build/ovms.elf" und gebt die beim a2l-Aufruf mit an.

Scripts/Plugins sind vermutlich nicht die Ursache (außer sie enthalten Bugs, die zu Endlosschleifen oder sehr langen Scriptlaufzeiten führen). Ich habe diverse Plugins aktiv und mit der aktuellen Version bislang überhaupt keine Crashes mehr. Aber die Herangehensweise, testweise bestimmte Funktionen zu deaktivieren, ist natürlich korrekt. Aber nur wenn ihr die Crashes mit einer zuverlässigen Häufigkeit habt, denn sonst könnt ihr aus "kein Crash" keinen Rückschluss ziehen.

Wie gesagt, im Log findet ihr ggf. noch wichtige Infos. Wenn die Crashes halbwegs reproduzierbar sind lohnt es sich evtl. den allgemeinen Loglevel mal für die Recherche auf "Debug" oder sogar "Verbose" zu stellen.

Danke für die ausführliche Erklärung, das hilft mir enorm weiter im Verständnis mit dem Umgang mit dem ESP32!

Allerdings bin ich inzwischen ziemlich sicher, dass doch meine Skripte schuld sind: so wie ich das jetzt verstanden habe ist DukTape ja der JS-Interpreter und genau der wird ja vom watchdog gemeldet. Außerdem hatte ich jetzt länger die Skripte deaktiviert und keinen crash mehr (ja, wahrscheinlich sollte ich ein paar Tage warten, aber dazu bin ich zu ungeduldig). Ich habe ja drei Skripte und frage die recht schnell hintereinander ab. Habe die Abfolge der Abfrage jetzt länger gemacht als den timeout in der Hoffnung dass das als workaround erst mal funktioniert.

[sharkcow]

Ich glaube ich habe eine (Teil-)Erklärung gefunden für die komischen Temperaturwerte: gerade eben hat OVMS 39° Innentemperatur angezeigt, obwohl es nur noch 25° draußen hat und das Auto unwesentlich wärmer ist innen. Einmal entriegeln und die OVMS-Temperatur war 28°. Also bleibt der Wert auf dem Komfort-CAN wohl stehen wenn das Auto einschläft. Ist ja nachvollziehbar, aber ich hätte das gerne genutzt um am Handy zu sehen ob ich Vorklimatiseren will oder nicht... also müsste man dafür wohl jedes Mal das Auto aufwecken

Sorry, das war natürlich doof. Selbstverständlich gibt es gar keine aktuellen Messwerte wenn das Auto schläft. Ich war nur so gewöhnt daran, dass der SoC natürlich noch stimmt auch wenn das Auto schläft da er sich ja ändert. Das gilt für die Temperatur halt nicht
Also alles gut, ich werde in meiner App wahrscheinlich einen zusätzlichen Taster einbauen um das Auto zu wecken wenn man die aktuelle Temperatur sehen will. Bis jetzt auch seit fast einem Tag keine Abstürze!

[dexter]

Allerdings bin ich inzwischen ziemlich sicher, dass doch meine Skripte schuld sind

Schick mir bitte mal die Scripte und wie Du die abfragst.

[sharkcow]

Jetzt leider doch wieder ein crash:

Code: Alles auswählen

Detected boot reason: Crash (12/12)
  Reset reason: Task watchdog (6)
  Crash counters: 1 total, 0 early

Last crash: abort() was called on core 0
  Backtrace:
  0x4008e627 0x4008e8c1 0x400e6f1c 0x40083f6a
  Event: ticker.1@EventScript 60 secs
  WDT tasks: OVMS Events|IDLE1|OVMS DukTape
  Version: 3.2.013-369-g63a8a9ef/ota_1/main (build idf v3.3.2-881-g22d636b7b Jul 26 2020 19:55:50)

Wenn ich "./a2l 0x4008e627 0x4008e8c1 0x400e6f1c 0x40083f6a" aufrufe, kommt aber nichts außer die Angabe welche elf-Datei er benutzt...? Ich habe seither auch nicht neu kompiliert.

Danke,

sharkcow

[dexter]

OK, da ist jetzt klar der Event-Task verhungert. Erkennbar daran, dass der Sekundenticker 60 Sekunden im Scriptsystem fest hing.

Stimmt denn die elf-Datei? a2l enthält den Defaultpfad für eine typische Installation mit Standardpfaden. Wenn Du andere hast, musst Du das ggf. anpassen, oder den Pfad zur elf-Datei immer mit angeben. Der Defaultpfad steht im Script direkt am Anfang.

[sharkcow]

Ich habe (bewusst) keine Pfade verändert... die .elf-Datei liegt neben der .bin die ich geflasht habe unter build wie es a2l auch angibt. Zeitstempel der Dateien passt auch...

[sharkcow]

Den sonstigen Verlauf finde ich plausibel, wenn die Klimaanlage anfangs die Innentemperatur herunterkühlen musste, und sie am Ende durch Öffnen der Tür schnell wieder fast auf die Außentemperatur stieg.

Das würde bedeuten wir hätten den Rowert der innentemperatur. Und nicht T_innen_corr. Geregelt wird eigentlich nie nach dem rohwert. (Possition messtelle VS auseneinflüsse +- Filter usw.) Dann müsste noch irgendwo ein weiterer innentemperatur Wert rumpurzeln.
Grüße Nik

Ich denke auch, dass der Wert immer noch komisch ist. Heute hat OVMS deutlich über 50°C angezeigt, ein in die Konsole gelegtes Thermometer aber nur knapp 40°...