Störungen auf AVRs?

Softwarefehler. In Deinen Routinen fehlt die entsprechende
Fehlertoleranz (z.B. Time-Out Erkennung).

Hallo thkais

Wie meinst Du das denn genau? Welche Fehlertoleranz, die für den Bus
oder die für mein eigenes Programm? Die Routinen sind so geschrieben,
dass sie sich nicht aufhängen, sollte der Bus nicht reagieren - klar,
ist ja auch das Reset-Signal.

Ich vermute deshalb, Du meinst eher letzteres. Da würde natürlich der
Watchdog helfen. Aber ich verstehe nicht, wie es überhaupt zu dem
Fehler kommen kann! Wenn ich den Fehler schon auf meinem
Experimentier-Board hinbekommen kann, wie sieht das denn erst später im
Einsatz aus? Ich kann doch nicht jedes Mal mit dem Watchdog resetten, da
bekomme ich ja Datenchaos!

Gruß,
Steffen

Ok, der Baustein hängt sich tatsächlich auf, und zwar der Empfänger.
Aber wie meinst Du das mit "Softwarefehler"? In meinen Routinen hab
ich keine einzige Schleife drinnen, in denen er sich aufhängen kann!
Nicht eine, die einzige die drin ist, ist im Hauptprogramm und das ist
eine Endlosschleife!

Dann ist der auftretende Fehler ein Hardwarefehler! Aber kann das sein,
kann es am Baustein selbst liegen?

Wenn es ein Hardwarefehler sein sollte, müßte der Controller sich
komplett aufhängen. Am einfachsten ist es in diesem Fall, innerhalb der
Empfangsroutinen ein Pin zu toggeln, dann kannst Du mit Oszi oder LED
sehen, daß sich irgendwas tut - oder eben nicht.
Ich dachte auch schon oft, daß irgendwo etwas mit der Hardware nicht
stimmt - aber zu 90% wars die Software.
Du wirst nicht umhin kommen, genauer zu analysieren, was da los ist.
Ohne genaue Kenntnis der Hard- und Software kann man natürlich nur
allgemeine Hinweise geben. So ein klein wenig habe ich mit meinem
Posting da auch drauf hinweisen wollen ;-)

Ja, genau mit der LED hab ich auch herausgefunden, dass der Empfänger
sich aufhängt. Dass die Hardware nicht stimmt, halte ich selbst auch
für unwahrscheinlich. Aber anders kann ich mir den Fehler (noch) nicht
erklären, außerdem hat der Baustein schon unter meinen Versuchen
"gelitten".

Ich hab den Source-Code für die Empfangsroutinen angehängt (ohne die
erwähnte Test-LED). Es sind zwei Interrupt-Routinen. Der Code
funktioniert so, wie Du, Peter, es auch vorgeschlagen hast. Den
Pegelwechsel messe ich mit einem Input-Capture (obere Routine), bei
einem Reset nehme ich die Reset-Antwort danach bei einem Compare-Match
zurück (untere Routine).

Ich bin schon gespannt, was ihr dazu sagt!

Viele Grüsse,
Steffen

Bingo! Ich hab den Fehler gefunden: Wenn er im State "Senden" war, hat
er jede High->Low Flanke genommen, und es als Sendetrigger
interpretiert. Deshalb hat er dann auch das Reset-Signal als Trigger
gesehen, weil er nur auf die Flanke geachtet hat und das eigentliche
Signal ignoriert hat.

Es war also ein Software-Fehler. Das stimmt aber auch nur zum Teil!!
Denn wenn er nicht im State "Senden" war, hätte er einwandfrei
funktionieren müssen. Und in meinem Test-Programm, habe ich ihn NICHT
in diesen State versetzt. Irgendwie ist er also von selbst (?) dort
hingekommen?

Wie kann das sein?!?

Gruß,
Steffen

@Steffen:

Kleiner Tip: Du musst bei der Fehlersuche davon ausgehen, dass Du den
Fehler gemacht hast, und nicht andere. Die Wahrscheinlichkeit, dass der
Fehler nicht bei Dir liegt, ist weit unter 0,01%.

Das ist ein rein menschlich, psychologisches Problem, dass beim
Programmieren sehr dominant auftritt.

Daher beim Fehlersuchen immer mit der Einstellung: "Ich habe einen
Fehler gemacht, und ich werde ihn nun finden" suchen, niemals mit der
Einstellung "Da kann kein Fehler sein".

Mit der falschen psychologischen Einstellung, kannst Du keine Fehler
finden. Das ist übrigens durch viele Studien zum Thema Softwarequalität
belegt. Nur wenn Du diese menschliche Schwäche kennst, und auch
akzeptierst dass Du sie auch hast, so wie ich sie habe, so wie sie
jeder Mensch auf dieser Erda hat, nur dann schafst Du es, diese
Schwäche auszutricksen.

Was auch immer sehr gut hilft, ist jemanden Fremden, Dein Programm
mündlich zu erklären. Funktion für Funktion, Zeile für Zeile.

Hallo Michael

Du hast vermutlich Recht. Ich bin nur noch nicht so lange dabei, als
dass ich wüsste, wie wahrscheinlich Fehler auf Seiten der Hardware
sind! Es gibt hier ja viele Möglichkeiten, angefangen bei der
Schaltungstechnik (fehlende Abblock-Kondensatoren etc.) über
ESD-/EMV-Probleme bis hin zu Produktionsfehlern.

Trotzdem hast Du mir mit Deiner Einschätzung am Ende noch mehr
weitergeholfen :-) Nachdem ich mir nun zum x-ten Mal das Problem
vorgenommen hatte, ist mir eingefallen, dass meine Test-Unterbrechungen
des Busses vom Empfänger möglicherweise als Empfangsbits interpretiert
werden (Fehler #1). Aus dem Reset wurde so ein Datenbyte
zusammengesetzt und den Rest hat mein Testprogramm geregelt. Dort hatte
ich nämlich programmiert, dass er sein empfangenes Datenbyte sofort
wieder zurücksendet. So hat er seinen State auf "Senden" geschaltet
und konnte nicht mehr auf einen Reset reagieren (Fehler #2)!

Vielen Dank für Deine Antwort, Michael! Natürlich gilt dieser Dank auch
den anderen!!

Gruß,
Steffen