Brauche Tipps zum Eingrenzen eines Fehlers

Bernhard schrieb:

> Ich bin mir ziemlich sicher dass der Fehler bei der Berechnung passiert,

Darauf würde ich nicht wetten.
Seltsame Fehler, die völlig unerklärlich sind, haben meistens ihren 
Ursprung in einem Fehler ganz wo anders.

Arrayüberläufe, für Strings zu klein dimensionierte Arrays sind da die 
klassischen Kandidaten, allerdings sind das beileibe nicht alle 
Möglichkeiten. Eigentlich kann man erst hinterher, wenn man den Fehler 
gefunden hat, genau sagen wie sich dieser Fehler auswirkt, so dass man 
die Symptome sieht, die man sieht. Genau das ist das fiese an der Sache.

Folgendes kann man zum Beispiel machen:

-Auf einem normalen PC kompilieren (vorausgesetzt, die Funktion ist in C 
oder so geschrieben) und dort mal mit entsprechenden Beispielwerten 
diverse Testläufe laufen lassen. Kommt auf der anderen Plattform immer 
das richtige Ergebnis raus, kann es also nicht an der 
Prüfsummen-Funktion an sich liegen, denn man hat dann ja gezeigt dass 
sie korrekt implementiert ist.

-Debugger benutzen, Breakpoint setzen und die Funktion auf der 
Zielplattform Schritt für Schritt durchsteppen, notfalls hier mit 
Testarrays als Eingabe arbeiten weil man die Daten ja dann nicht in 
Echtzeit (über irgendeine Schnittstelle) bekommt

-Laufzeit prüfen: Einen Digitalausgang des Mikrocontrollers auf 1 setzen 
wenn die zu prüfende Funktion startet, und auf 0 setzen wenn sie endet. 
So kann man mit einem Oszilloskop sehr schön sehen, wie groß die 
Bearbeitungszeit für die Funktion ist - eventuell liegt sie nicht mehr 
im passenden Rahmen, je nachdem welchen Zeitbedingungen die Anwendung 
unterliegt.

-Generell prüfen, ob der Defekt nicht in der Hardware vorliegt: Mal den 
Mikrocontroller gegen einen anderen austauschen und die exakt gleiche 
Software aufspielen.

-Generell prüfen, ob einem nicht der (falsch eingestellte) Watchdog 
dazwischenhaut - ein beliebter Fehler, wie ich aus eigener Erfahrung in 
meinem ersten Projekt nach dem Studium erleben durfte :-)

Die Wahrscheinlichkeit, dass der Speicher an irgendeiner Stelle 
korrumpiert wird (z.B. wie von Karl heinz Buchegger beschrieben), halte 
ich für sehr viel größer als dass eine einfache Schleife über ein Array 
von Bytes und deren XOR-Verknüpfung Probleme macht.

Bernhard schrieb:

>> die Symptome sieht, die man sieht. Genau das ist das fiese an der Sache.
> Dass ist mir leider schon zu oft passiert.
> Desswegen hatte ich gefragt welche Herangehensweise es gibt um den
> Fehler eingrenzen zu können.

Den Fehler gar nicht erst entstehen lassen :-)
Klingt jetzt neunmalklug, ist aber so.

In kleinen Abschnitten entwickeln. Jeden Abschnitt für sich auf Herz und 
Nieren testen.

> Denn jeder geht anders an die Fehlersuche
> heran.

Das ist gar nicht so sehr der springende Punkt.
Der springende Punkt ist, dass es unglaublich schwer ist, in ein 
fünf-tausend Zeilen Code die eine zu finden, die für das momentan 
sichtbare Symptom verantwortlich ist, wenn man nicht nachweisen kann, 
dass es 4500 nicht sein können, weil man die ausreichend getestet hat.

> Und dadurch gibt es immer wieder nsätze an die man selbst nie im
> Leben gedacht hätte.

Im Extremfall gehört auch ein Quentchen Glück mit dazu.
Debugger, die man auf Speicherzellen ansetzen kann und die sich melden, 
wenn diese Zelle ihren Wert ändert (egal warum, also Überwachung indem 
nach jeder Anweisung gecheckt wird, ob sich die Zelle verändert hat)


> Was mir aufgefallen ist, ist dass AVR Studio hin und wieder ein 16 Bit
> Array dur ein 8 Bit Array ersetzt.

Ganz sicher nicht.

>> Die Wahrscheinlichkeit, dass der Speicher an irgendeiner Stelle
>> korrumpiert wird (z.B. wie von Karl heinz Buchegger beschrieben), halte
>> ich für sehr viel größer als dass eine einfache Schleife über ein Array
>> von Bytes und deren XOR-Verknüpfung Probleme macht.
>
> Dass habe ich auch schon gemacht.
>
> Dass Problem ist, dass mit Daten-Tabellen und Startwerten alles richtig
> arbeitet.
> Sowol auf dem PC als auch auf dem uC.
> Nur sobald die richtigen Daten kommen, gibt's Fehler.

Dann bleibt dir nichts mehr anderes übrig als:
Programm mit printf (bzw dem Äquivalent) spicken und alle auch nur 
irgendwie interessant scheinenden
  * Eingangswerte
  * Zwischenwerte
  * Ergebnisse
ausgeben (UART ist da besser als LCD, weil ein Termialprogramm 
normalerweise eine längere Sitzung protokollieren kann)
Dieses Protokoll mitlesen, Werte auf Plausibilität prüfen und hoffen das 
man dort den Bereich in etwa eingrenzen kann.

Du musst die Black Box öffnen. Momentan weißt du nur, dass hinten was 
falsches raus kommt, wenn du vorne etwas reinsteckts (die Eingangswerte 
hast du hoffentlich schon geprüft. Es kommt gar nicht so selten vor, 
dass eine Funktion gar nicht die Werte vorgesetzt bekommt, die sich der 
Entwickler vorstellt und mit denen er Debugging betreibt).

Also bleibt dir nichts anderes übrig als dir ein 'Fenster' in den µC zu 
schaffen, durch welches du deinem µC möglichst gut bei der Arbeit 
zusehen kannst.

> Ohne Quellcode kann ich auch nur raten...


Dito.

Was bei mir immer gerne passiert ;-)  :

Bei einem Rotierbefehl RLC/RRC ist vorher das Carry nicht richtig 
gesetzt....und je nach Aktivitaeten  im Interrupt kann's auch mal falsch 
sitzen ;-)



Generell stimuliert es die Motivation von Mitlesern mehr, eine sinnvolle 
Antwort zu suchen, wenn der Fragesteller mehr Informationen gibt.
Angefangen vom tollen (?) Titel "Brauche Hilfe", "Tipps gesucht", "Was 
ist der Fehler" bis zur Beschreibung der Randbedingungen:
Du schreibst nur, was nicht geht, und fragst was Du machen sollst, 
schreibst  aber nicht was Du ueberhaupt machen KANNST!
Keine Info ob ein SW-Simulator vorliegt, ob Du einen Emulator hast......

Im Simulator wuerde ich alle moeglichen Eingangswerte von 0 bis FFFF (?) 
mal stimulieren und sehen, ob Werteabhaengig was passiert,
Wenn's das nicht ist, im Emulator mal die Uebertragungen freischalten, 
aber als Werte immernoch die Defaultdaten benutzen um zu sehen, obdurch 
die Kommunikation selber etwas passiert.....



vielleicht liegt der Fehler also wirklich in Zeile 42!


gruss

Michael

Bernhard schrieb:
> Der Fehler war übrigens fieserweise nicht im eigentlichen Projekt,
> sondern im Programm das die Ausgaben des Projekts auf Richtigkeit
> überprüft.

Wie gesagt -

Mark Brandis schrieb:
> -Debugger benutzen, Breakpoint setzen und die Funktion auf der
> Zielplattform Schritt für Schritt durchsteppen, notfalls hier mit
> Testarrays als Eingabe arbeiten weil man die Daten ja dann nicht in
> Echtzeit (über irgendeine Schnittstelle) bekommt

Für einen einzelnen Zyklus (oder wenige Zyklen) kann/soll man das 
durchaus mal von Hand prüfen. Und dann sieht man ja, dass auf dem 
Zielsystem das richtige Ergebnis herauskommt, und kann bei einer 
Diskrepanz zur Prüfsoftware diese sogleich in Gewahrsam nehmen.

Bernhard schrieb:

> Der Fehler war übrigens fieserweise nicht im eigentlichen Projekt,
> sondern im Programm das die Ausgaben des Projekts auf Richtigkeit
> überprüft.

Dann ist dieses Programmnichts wert, wenn es dir im Fehlerfall nicht 
gestattet den (seiner Meinung) nach fehlerhaften Fall nachzuvollziehen. 
Soweit nachzuvollziehen, dass du aus diesem Prüfprogramm die notwendigen 
Input Daten erhältst, mit denen du die Berechnung kontrollieren kannst.

Michael Roek-ramirez schrieb:
> Bei einem Rotierbefehl RLC/RRC ist vorher das Carry nicht richtig
> gesetzt....und je nach Aktivitaeten  im Interrupt kann's auch mal falsch
> sitzen ;-)

Dann ist aber der Interrupthandler auch noch defekt. Wenn der Handler 
das flag verändert, muss er dafür sorgen, dass es wieder zurückgesetzt 
wird.
Oder was passiert hier:

CLC
<-- Interrupt
RLC
RRC
...