ESP32 Fehlercodeanalyse

Hallo zusammen,

ich habe versucht einen bestehendes Sketch, welcher sich noch im Aufbau befand aber bislang funktionell war, auf den ESP32 umzuschreiben. Bei der Überprüfung und beim Übertragen hat alles letztendlich geklappt. Jedoch erhalte ich folgenden Dump im seriellen Monitor:

Adafruit finger detect test
23:31:27.293 -> Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
23:31:27.293 -> Memory dump at 0x400d13f0: ffffffff ffffffff ffffffff
23:31:27.293 -> Core 1 register dump:
23:31:27.293 -> PC      : 0x400d13f4  PS      : 0x00060530  A0      : 0x800d2701  A1      : 0x3ffb1f80  
23:31:27.293 -> A2      : 0x3ffc014c  A3      : 0x3ffbfe54  A4      : 0x00000020  A5      : 0x80000020  
23:31:27.293 -> A6      : 0x00000008  A7      : 0x00000001  A8      : 0x800d0f30  A9      : 0x3ffb1f60  
23:31:27.293 -> A10     : 0x3ffbfe54  A11     : 0x00002580  A12     : 0x0800001c  A13     : 0x00000003  
23:31:27.293 -> A14     : 0x00000003  A15     : 0x00000000  SAR     : 0x00000016  EXCCAUSE: 0x00000000  
23:31:27.293 -> EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xffffffff  
23:31:27.293 -> 
23:31:27.293 -> ELF file SHA256: 0000000000000000
23:31:27.293 -> 
23:31:27.293 -> Backtrace: 0x400d13f4:0x3ffb1f80 0x400d26fe:0x3ffb1fb0 0x40086205:0x3ffb1fd0
23:31:27.293 -> 
23:31:27.293 -> Rebooting...
23:31:27.340 -> ets Jun  8 2016 00:22:57
23:31:27.340 -> 
23:31:27.340 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
23:31:27.340 -> configsip: 0, SPIWP:0xee
23:31:27.340 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
23:31:27.340 -> mode:DIO, clock div:1
23:31:27.340 -> load:0x3fff0018,len:4
23:31:27.340 -> load:0x3fff001c,len:1216
23:31:27.340 -> ho 0 tail 12 room 4
23:31:27.340 -> load:0x40078000,len:10944
23:31:27.340 -> load:0x40080400,len:6388
23:31:27.340 -> entry 0x400806b4

Kann jemand damit schon etwas anfangen? Ich glaub es ist fast sinnvoller das Projekt nochmal komplett von vorne zu starten.

Guru Meditation Error deutet auf einen WatchDog-Reset hin
Das bedeutet dein Code hat irgendwo eine Schleife oder ein delay() das zu lange braucht
und dann beißt der software-reset-watchdog zu.

vgs

Nee, einen WDT Würde es melden können.
Oder?

Wenn der Exception Decoder auch nichts genaueres sagt.....

Oft ist es so, dass die Stromversorgung solche Probleme verursacht.
Also Prüfen, ob das immer an der selben Stelle stattfindet, dann dürfte die Stromversorgung schuldlos sein..

Bei einem funktionierenden Projekt habe ich das auch schon gehabt. Ich tippe auch auf die Stromversorgung, weshalb ich USB abgezogen habe, Versorgung durch 5V-Netzteil, Debugausgaben auf OLED und Programmübertragung "over the air" (OTA).

Weitere scheinbar erfolgreiche Versuche:

  • USB abziehen und wieder draufstecken.
  • Debugausgaben rausnehmen, geht bei mir mit einem #define
  • zwischenzeitlich mal den Blinksketch draufspielen
  • WiFi und delay() oder blockierende Schleifen vertragen sich nicht, danach solltest Du in Deinem Projekt fahnden.

Immerhin laufen Arduino und das Wifi in unterschiedlichen Tasks auf je einem eigenen Core.
Von Hause aus.

Du kennst es vermutlich auch, man sucht nach einem Fehler, macht verschiedene Dinge und am Ende funktioniert das Projekt. Bei der Fehlersuche ist man nicht jeder Spur konsequent gefolgt, weshalb manche erfolgreiche Maßnahmen auch nur scheinbar erfolgreich waren.

In diese Kategorie fällt mein Beitrag #4, daher habe ich "scheinbar" auch extra unterstrichen. Jetzt habe ich auch "WiFi und delay()" zu der Aufzählung genommen.

Mein derzeitiges Projekt macht mir mehr Spaß als eine Fehlersuche, daher lasse ich den Spaßfaktor gewinnen, sorry! "Ich kann die Säge nicht schärfen, ich muß sägen!"

Du meinst, man fummelt ein bisschen rum, und Plupp tuts das auf einmal...
Keiner weiß warum, oder was vorher schief gelaufen ist, aber man hat das breite Grinsen im Gesicht.

Naja....
Ich verfolge meist einen anderen Ansatz.

z.B. würde ich hier mit dem lesen der Meldung anfangen.

Das ist schon ein Hammer!
Der Prozessor soll einen Maschinencode Befehl ausführen, welchen er nicht kennt, oder an der Stelle verboten ist.

Die Auswahl an Ursachen ist eigentlich nicht besonders groß.

  1. Der ESP ist kaputt
  2. Alle diese ESP haben den Fehler im Design
  3. Das Ram oder Flash ist korrupt - wild überschrieben, oder defekt
  4. Störungen haben ein oder mehrere Bit getoggelt.
  5. Der Compiler ist kaputt
  6. Die interne Statemaschine baut Mist beim holen des Codes aus dem Flash oder beim Transport ins RAM

Der einzige Punkt, wo man einigermaßen ran kommt ist die 4.
Evtl. auch Punkt 1, durch austauschen
.
Ein Programmierfehler, taucht in meiner Liste überhaupt nicht auf.
Der Grund:
Für einen Programmierer sollte es unmöglich sein eine illegale Anweisung zu erzeugen.

Buffer overflow, Sprung in den Heap, Code überschreiben beim EEPROM-Schreiben - da geht einiges.

Das glaube ich nicht, dass das beim ESP32 so möglich ist. Klar Overflows gibt es, aber so eine illegale Anweisung hin zu bekommen, das sehe ich erstmal nicht.

Das müsste ja mit dem Teufel zugehen, wenn dann noch die Prüfsumme im Flash stimmen würde.

Der Ram Bereich, aus dem Code ausgeführt wird, ist geschützt und würde somit eine andere Exception werfen.
InstrFetchProhibited oder LoadProhibited, StoreProhibited

Espressiv sagt dazu:

IllegalInstruction

This CPU exception indicates that the instruction which was executed was not a valid instruction. Most common reasons for this error include:

  • FreeRTOS task function has returned. In FreeRTOS, if task function needs to terminate, it should call vTaskDelete() function and delete itself, instead of returning.
  • Failure to load next instruction from SPI flash. This usually happens if:
    • Application has reconfigured SPI flash pins as some other function (GPIO, UART, etc.). Consult Hardware Design Guidelines and the Datasheet for the chip or module for details about SPI flash pins.
    • Some external device was accidentally connected to SPI flash pins, and has interfered with communication between ESP32 and SPI flash.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/fatal-errors.html

Ich bin in so einer Gelegenheit beunruhigt, weil wenn ich nicht weiß, wieso etwas wieder zufällig funktioniert der Fehler nicht ausgemerzt ist und darum die Fehlerquelle wieder aktiv werden kann und man ist wieder am Punkt vor der Aufgabe der Fehlersuche.
Auch weiß ich daß bestimmte sporadische Fehler Zeit brauchen, bis sie nicht mehr so sporadisch auftreten und man die Möglichkeit hat, sie zu finden, weil die meisten Fehler findet man nur wenn sie aktuell da sind.

Grüße Uwe

Fehler verstecken sich.
Fehler sind schlau.
Fehler verbünden sich um einen ganz anderen Fehler vorzuspielen
Fehler wirken gerne im Team, ergänzen sich.
Fehler beherrschen die Techniken der Tarnung und des Mimikry perfekt.
z.B. tarnen sich sich mit dem Mäntelchen "Das ist aber mal ein guter Trick, oder Idee"
Fehler genießen ihre Maximierung

Sie wohnen im Schatten.
Gerne warten sie genau auf die Sekunde in der maximaler Schaden angerichtet werden kann.
z.B. der Augenblick der Produktpräsentation
Oder wenn alle Daten eingegeben sind, aber die Datensicherung noch nicht gemacht.

Wenn der Techniker gerade das Haus verlassen hat.
Einen Tag, nach der Installation.
In der Mittagspause.
Und nach der Pause macht erstmal der Bagger die Telefonleitung vorm Haus kaputt.

2 Likes

:rofl: :+1: :+1:

Nunja. Entweder stimmt etwas mit einer Lib nicht, welche ich ersetzen musste, oder ich habe ggf. etwas an einen falschen Pin angeschlossen, der dann ggf. doch nicht benutzt werden sollte...

Ich denke es ist am einfachsten, das Projekt nochmal neu Stück für Stück aufzubauen und dann Abschnittsweise zu immer testen. Wenn DIESER Fehler dann auftaucht kann ich zumindest nachvollziehen, wodurch das passiert.

Ja, der Satz "Application has reconfigured SPI flash pins as some other function (GPIO, UART, etc.)." könnte möglicherweise zutreffen. Wenn Du beispielsweise UART1 verwendest, ohne die Pins zu verlegen, könnte von der Softwareseite Ungemach drohen. Möglicherweise passiert dies auch in einer Bibliothek, die den ESP32 nicht kennt.

Das ist auf jeden Fall eine gute Idee :slightly_smiling_face:

Das ist einer dieser "guten Ideen", von denen ich in #11 sprach.

Auch wenn ich mir wie ein Papagei vorkomme.....

  1. Was sagt der ESP Exception Decoder?
  2. Was ist mit der Stromversorgung?

Aber egal, mach was du für richtig hältst.
Egal wie du dich entscheidest, es besteht die Hoffnung, dass du etwas lernst.

Der hilfsbereite @combie schreibt gerne in Rätseln, weshalb seine Hilfe leider häufig nicht auf fruchtbaren Boden fällt. Ich versuche mich mal als Nikolaus und an einer Übersetzung:

Der ESP Exception Decoder ist eine Erweiterung der Arduino-IDE. Aha, muß man drauf kommen. EspExceptionDecoder-1.1.0.zip und Arduino ESP8266/ESP32 Exception Stack Trace Decoder mit Ziel bei mir c:\Program Files (x86)\arduino-1.8.13\tools\EspExceptionDecoder\tool\EspExceptionDecoder.jar

@combie: Bei mir (Win10) möchte dieses Werkzeug eine *.elf-Datei im Bereich Dokumente öffnen, was will mir das sagen? Oder benötige ich erst einen Fehler?

Du benötigst die Dateien, welcher der Compiler für dich erstellt hat.
Denn nur darin findet sich die korrekte Zuordnung von Adresse zu Funktions/Methoden Name.

Also:

  1. Programm übersetzen
  2. Auftretenden Fehler in den Decoder übertragen
  3. Sich an den Klartextmeldungen erfreuen.

Nein!
Ein Irrtum.
Ich schreibe nicht gerne in Rätseln.
Ich schreibe gerne Klartext.

Es gibt allerdings viele unterschiedliche Besucher hier. Typen/Charaktere und das auch noch in den lustigsten Tagesformen.

Ein Landwirt kann, muss sogar, den Boden kontrolliert vorbereiten, bevor er seine Saat ausbringt. Ich kann und will nicht fremde Hirne pflügen.
Bin ich meistens zu faul zu, ist auch manchmal echt nervig, das Versagen droht.

Immerhin habe ich das Stichwort "Exception Decoder" geliefert.

Hier findet man dann zwei diametral gegenüberliegende Reaktionsmöglichkeiten:

  1. Was nicht verstanden wird, wird ausgeblendet.
  2. Es fällt auf, und man macht sich kundig.

Bei 1 ist der Boden nicht bereit, die gegebene Information/Saat aufzunehmen. Total menschlich. Nix schlimmes dran. Machen wir alle so.

Bei 2 ist ein Früchte tragender Dialog möglich.

Als Auffrischung wiederhole ich solche Schlüsselworte auch gerne nochmal.
Manchmal überwindet das dann die Wahrnehmungsschwelle.

Nachdem der Compiler tätig war, gibt es auch eine *.ino.elf-Datei im temporären Projektverzeichnis.

Jetzt warte ich auf die nächste Ausnahme :slightly_smiling_face:

Danke!

Mach dir eine!

z.B. beim generic ESP8266 kann man die C++ Exceptions im Board Menü aktivieren

void setup() 
{
}

void werfer()
{
   throw "Meine beabsichtigte Ausnahme.";
}

void loop() 
{
  delay(10000);
  werfer();
}

Ich muss euch mal kurz unterbrechen. xD

Zwischenstand:

Anbindung vom Rotary funktioniert.
Anbindung Servo auch.

Habe mir jetzt einen Touchpin belegt, um das Verhalten des Servos nochmal genauer zu testen. Und ich bekomm hier in den IF Bereich die zweite Bedingung nicht hin.

Nicht wundern. Der komplette Code ist etwas größer. Dennoch funktioniert der IF Teil, sobald ich && doormode ==0 weglasse... So wie er aktuell ist, steigt er dort aber überhaupt nicht ein. Was mache ich falsch?

Wie deklariere ich int variablen als byte? Notwendig? Empfehlenswert? Oder so wie es grade ist ok?

const int touchpin = 4;
int touchvalue;
const int touchschwelle = 30;
int doormode = 0;


void loop() {
  touchvalue = touchRead(touchpin);
  Serial.println(touchvalue);
  if(touchvalue < touchschwelle && doormode == 0)
  {
    doormode=1;
    Serial.println("doormode=");
    Serial.print(doormode);
    delay(1000);
  }
  
  if(touchvalue < touchschwelle && doormode == 1)
  {
    doormode=0;
    Serial.println("doormode=");
    Serial.print(doormode);
    delay(1000);
  }
  }