Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
elektronik_labor:tipps_fuer_die_fehlersuche [2020/03/25 00:12] – ↷ Page moved from tipps_fuer_die_fehlersuche to elektronik_labor:tipps_fuer_die_fehlersuche tfischerelektronik_labor:tipps_fuer_die_fehlersuche [2023/09/19 23:30] (aktuell) – mexleadmin
Zeile 1: Zeile 1:
-====== Tipps für die Fehlersuche (= Debugging) ======+====== Debugging und Bugfixing - Tipps für die Fehlersuche  ======
  
 ===== Allgemein ===== ===== Allgemein =====
Zeile 33: Zeile 33:
 Gab es weltweit noch keinen, der diese Teilfunktion implementiert hat? Um das zu beantworten hilft ein Blick in Google.  Gab es weltweit noch keinen, der diese Teilfunktion implementiert hat? Um das zu beantworten hilft ein Blick in Google. 
  
-Lernen Sie [[Besser Suchen mit Google]]+Lernen Sie [[:besser_suchen_mit_google]]
  
 Falls es jemanden gab, so war die Funktion an anderer Stelle bereits lauffähig --> Gehe zu 2. .  Falls es jemanden gab, so war die Funktion an anderer Stelle bereits lauffähig --> Gehe zu 2. . 
Zeile 173: Zeile 173:
  
 <-- <--
 +
 +===== Software =====
 +
 +  * Compiliert der Code?
 +    * Ist die richtige Zielhardware (z.B. ATmega328PB) gewählt?
 +    * Sind bei den eingebundenen Bibliotheken die Randbedingungen der Zielhardware berücksichtigt? (z.B. hat der ATmega328PB andere Benamung der I2C und SPI Register, da diese mehrfach vorhanden sind)
 +  * Wichtig ist, dass Sie zunächst eine Ausgabemöglichkeit schaffen. Die kann ein digitaler (oder analoger) Output Pin oder eine LCD-Anzeige sein. Ohne diese ist eine strukturierte Fehlersuche schwer möglich. Versuchen Sie die Ausgabemöglichkeit als erstes zu programmieren und zu testen.
 +  * Wenn Sie zur Fehlersuche Ihr Programm ändern, machen Sie eine Sicherungskopie des Programms. Weiterhin sollten Sie die zur Fehlersuche geänderten Zeilen markieren (z.B. mit dem Kommentar DEBUGGING!)
 +  * Falls das Programm nicht die von Ihnen gewünschte Ergebnisse liefert, dann versuchen Sie zunächst möglichst weiträumig Code auszukommentieren. Falls dann das Programm noch einen sinnvollen Ablauf zeigt, kann Schritt für Schritt die Auskommentierung aufgehoben werden.
 +  * Nutzen Sie die Möglichkeit nach Zwischenschritten eine Wertänderung auszugeben (z.B. Ausgabe am LCD). Damit kann ermittelt werden ab welcher Zeile der tatsächliche Ablauf vom gewünschten abweicht.
 +  * Prüfen Sie mit Hilfe der [[https://www.mikrocontroller.net/articles/AVR_Checkliste|AVR Checkliste]] nach bekannten Fehlerquellen.
 +  * Versuchen Sie den Code so umzuschreiben, dass dieser durch einem Online Compiler (z.B. [[https://www.onlinegdb.com/online_c_compiler|OnlineGDB]]) testbar wird.
 +  * Falls Sie dann immer noch nichts finden: Schreiben Sie eine Frage an den Betreuer. Achten Sie dabei auf das richtige [[https://www.mikrocontroller.net/articles/Forum-Fragenformulierung|Stellen von Fragen]]
 +
 ===== Hardware ===== ===== Hardware =====
  
Zeile 189: Zeile 203:
   * Falls Sie einen Fehler in der Kommunikation vermuten: verbinden Sie RX mit TX und überprüfen Sie, ob am gleichen Bauteil das korrekte Signal ankommt.   * Falls Sie einen Fehler in der Kommunikation vermuten: verbinden Sie RX mit TX und überprüfen Sie, ob am gleichen Bauteil das korrekte Signal ankommt.
  
-===== Software ===== +===== Häufige Fehler =====
- +
-  * Compiliert der Code? +
-    * Ist die richtige Zielhardware (z.B. ATmega328PB) gewählt? +
-    * Sind bei den eingebundenen Bibliotheken die Randbedingungen der Zielhardware berücksichtigt? (z.B. hat der ATmega328PB andere Benamung der I2C und SPI Register, da diese mehrfach vorhanden sind) +
-  * Wichtig ist, dass Sie zunächst eine Ausgabemöglichkeit schaffen. Die kann ein digitaler (oder analoger) Output Pin oder eine LCD-Anzeige sein. Ohne diese ist eine strukturierte Fehlersuche schwer möglich. Versuchen Sie die Ausgabemöglichkeit als erstes zu programmieren und zu testen. +
-  * Wenn Sie zur Fehlersuche Ihr Programm ändern, machen Sie eine Sicherungskopie des Programms. Weiterhin sollten Sie die zur Fehlersuche geänderten Zeilen markieren (z.B. mit dem Kommentar DEBUGGING!) +
-  * Falls das Programm nicht die von Ihnen gewünschte Ergebnisse liefert, dann versuchen Sie zunächst möglichst weiträumig Code auszukommentieren. Falls dann das Programm noch einen sinnvollen Ablauf zeigt, kann Schritt für Schritt die Auskommentierung aufgehoben werden. +
-  * Nutzen Sie die Möglichkeit nach Zwischenschritten eine Wertänderung auszugeben (z.B. Ausgabe am LCD). Damit kann ermittelt werden ab welcher Zeile der tatsächliche Ablauf vom gewünschten abweicht. +
-  * Prüfen Sie mit Hilfe der [[https://www.mikrocontroller.net/articles/AVR_Checkliste|AVR Checkliste]] nach bekannten Fehlerquellen +
-  * Falls Sie dann immer noch nichts finden: Schreiben Sie eine Frage an den Betreuer. Achten Sie dabei auf das richtige [[https://www.mikrocontroller.net/articles/Forum-Fragenformulierung|Stellen von Fragen]] +
- +
-====== Häufige Fehler ====== +
-  * **Bei Tools >> Device Programming finde ich im Tool nur "Simulation", aber kein STK500.** Versuchen Sie zunächst über Tools >> Add tagret... STK500 und den entsprechenden Serial Port zu wählen. Falls Ihr Rechner mehrere USB Ausgänge hat, müssen Sie diese (COM1...COMx) beim Programmieren ausprobieren. +
-  * **"Erasing device failed", "Error status received: Got 0xc9, expected 0x00 (An unknown command was sent)"**.  +
-    * Steht bei Device Programming das Interface auf ISP? Falls nicht kann dies die Ursache sein. Das Programming geschieht immer mittels ISP. +
-    * Hat das USB-Kabel/Progi/Adapterplatine/Kabel ein Problem? Probieren Sie eine andere Variante der Komponenten durch +
-  * ** Mein Chip hat keinen Speicherplatz mehr** bzw ** Ich erhalte ein 'Memory Overflow' Fehler** Falls Sie Daten statt im SRAM im EEPROM speichern wollen, so können Sie das Befehlswort "PROGMEM" nutzen. Details dazu finden Sie z.B. auf der Seite von [[https://www.microchip.com/webdoc/AVRLibcReferenceManual/pgmspace_1pgmspace_strings.html|Microchip]]+
   * **F_CPU not defined for** (z.B. <util/delay.h>) Das beste ist die Frequenz F_CPU im AVR Studio direkt anzugeben:   * **F_CPU not defined for** (z.B. <util/delay.h>) Das beste ist die Frequenz F_CPU im AVR Studio direkt anzugeben:
-    * Gehe zu Menu: Projekt > (ProjektName) Eigenschaften > Toolchain > AVR/GNU C Compiler > Symbols+    * Gehe zu Menu: ''Projekt >> (ProjektName) Eigenschaften >> Toolchain >> AVR/GNU C Compiler >> Symbols''
     * Füge F_CPU=8000000 (bzw. Passende Frequenz) ein      * Füge F_CPU=8000000 (bzw. Passende Frequenz) ein 
   * **Das Programm kompiliert nicht** **TWSR not found** : Falls Sie einen modernen AVR Chip nutzen (z.B. 328PB) so kann dieser mehrere SPI und I2C Schnittstellen haben. Damit haben sich bei diesem Target auch die Register- und Interruptvektornamen geändert. Statt TWSR ist dann TWSR0 oder TSWR1 zu verwenden - je nach gewünschtem Pin. Dies ist am einfachsten über defines der fehlerhaften Namen, also ''%%#define TWSR TWSR0%%'' usw.    * **Das Programm kompiliert nicht** **TWSR not found** : Falls Sie einen modernen AVR Chip nutzen (z.B. 328PB) so kann dieser mehrere SPI und I2C Schnittstellen haben. Damit haben sich bei diesem Target auch die Register- und Interruptvektornamen geändert. Statt TWSR ist dann TWSR0 oder TSWR1 zu verwenden - je nach gewünschtem Pin. Dies ist am einfachsten über defines der fehlerhaften Namen, also ''%%#define TWSR TWSR0%%'' usw. 
 +  * **Beim Flashen der realen Hardware über ''Tools >> Device Programming'' finde ich im Tool nur "Simulation", aber kein STK500.** Versuchen Sie zunächst über Tools >> Add tagret... STK500 und den entsprechenden Serial Port zu wählen. Falls Ihr Rechner mehrere USB Ausgänge hat, müssen Sie diese (COM1...COMx) beim Programmieren ausprobieren.
 +  * **Beim Flashen der realen Hardware erhalte ich "Erasing device failed", "Error status received: Got 0xc9, expected 0x00 (An unknown command was sent)"**. 
 +    * Steht bei Device Programming das Interface auf ISP? Falls nicht kann dies die Ursache sein. Das Programming geschieht immer mittels ISP.
 +    * Hat das USB-Kabel/Progi/Adapterplatine/Kabel ein Problem? Probieren Sie eine andere Variante der Komponenten durch
 +  * ** Mein Chip hat keinen Speicherplatz mehr** bzw ** Ich erhalte ein 'Memory Overflow' Fehler** Falls Sie Daten statt im SRAM im EEPROM speichern wollen, so können Sie das Befehlswort "PROGMEM" nutzen. Details dazu finden Sie z.B. auf der Seite von [[https://www.microchip.com/webdoc/AVRLibcReferenceManual/pgmspace_1pgmspace_strings.html|Microchip]]
 +  * **Mein Programm scheint irgendwo nicht weiter zu kommen**. Dies kann verschiedene Gründe haben:
 +    * Endlosschleife
 +    * Speicherüberlauf im RAM: sobald die Speicherauslastung des RAM über ca 75% steigt, sind Probleme wie spontane Resets bei Bearbeiten von Pointern, Arrays, Strings oder Structs wahrscheinlich. Die kann über Debugging herausgefunden werden (entweder mit Steppen mit Debugger oder Ausgabe von Werten nach jeder Zeile).
 +
 +=== I2C ===
   * **Auf den I2C Leitungen ändert sich nichts, obwohl der IC etwas ausgeben sollte:**    * **Auf den I2C Leitungen ändert sich nichts, obwohl der IC etwas ausgeben sollte:** 
     - Überprüfen Sie die Pullup-Widerstände: Sind welche verbaut? Welche Größe haben diese? (typisch: 10kOhm). Wenn keine Verbaut sind, so wechselt das Signal nur zwischen 0V niederohmig und 0V hochohmig. Dies ist am Oszilloskop nicht zu unterscheiden.     - Überprüfen Sie die Pullup-Widerstände: Sind welche verbaut? Welche Größe haben diese? (typisch: 10kOhm). Wenn keine Verbaut sind, so wechselt das Signal nur zwischen 0V niederohmig und 0V hochohmig. Dies ist am Oszilloskop nicht zu unterscheiden.
     - Ist ein hochohmiger Widerstand $R_L$ entlang der Leitungen verbaut? Falls ja erzeugt dieser einen Spannungsteiler mit dem Pullup-Widerstand. Wenn $R_L$ groß ist, so liegt zwischen $R_L$ und Pull-up fast die Versorgungsspannung an.     - Ist ein hochohmiger Widerstand $R_L$ entlang der Leitungen verbaut? Falls ja erzeugt dieser einen Spannungsteiler mit dem Pullup-Widerstand. Wenn $R_L$ groß ist, so liegt zwischen $R_L$ und Pull-up fast die Versorgungsspannung an.
 +  * **Der Master soll Daten vom Slave empfangen, aber hängt sich manchmal auf** Im "Master Receiver Mode" muss der Master das Ende der Kommunikation dem Slave mitteilen. Dazu muss beim Lesen der Daten TWEA = 0 gesetzt werden. Ansonsten kann es sein, dass der Slave meint er müsse noch Daten senden. Das kann unter Umständen dazu führen, dass der Slave die Datenleitung SDA am Ende der Kommunikation auf Low legt und damit den I2C stört.
  
-====== Tipps für die Fehlerkorrektur (Bugfixing) ======+===== Tipps für die Fehlerkorrektur (Bugfixing) =====
  
   * Bei größeren (Serien)Projekten steht einer einfachen Elektronik-Fehlerkorrektur häufig die komplexe Validierung und Tests der Hardware im Weg. Entsprechend kann es sich anbieten die Fehler über ein Mod-Board - also einem kleinen Zusatzboard - zu korrigieren. Dafür bietet sich beispielsweise ein kompakter Chip, wie der [[https://www.mouser.de/datasheet/2/268/40001239F-890247.pdf|6 Pin SOT PIC10F206]] oder der Attiny10 an.   * Bei größeren (Serien)Projekten steht einer einfachen Elektronik-Fehlerkorrektur häufig die komplexe Validierung und Tests der Hardware im Weg. Entsprechend kann es sich anbieten die Fehler über ein Mod-Board - also einem kleinen Zusatzboard - zu korrigieren. Dafür bietet sich beispielsweise ein kompakter Chip, wie der [[https://www.mouser.de/datasheet/2/268/40001239F-890247.pdf|6 Pin SOT PIC10F206]] oder der Attiny10 an.