mikrocontroller.net

Forum: Compiler & IDEs Langzeittest der Software


Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich versuche gerade meine Software mittels einer 
Daten-Bombardement-Software zu testen. Prinzipiell ist mein Programm 
eine Platine mit vielen verchiedenen Schnittstellen, unter denen auch 
ein ENC28J60 ist.

Leider hat meine Software nur 37h stand gehalten und ich habe einfach 
keine Ahnung wo ich anfangen soll zu suchen. Das Programm hat alle 
Aufgaben richtig erledigt bzw alle Anfragen richtig abgearbeite und 
geantwortet, bis es einfach nicht mehr ging.
Das ganze sieht nach Fragmentiereten Speicher aus, oder?

Ich habe keine Ahnung wie man da den Fehler finden kann. Hat da jemand 
von euch gute Tipps?

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

meiner Erfahrung nach ist meistens die Fehlerbehandlung fehlerhaft oder 
wird nicht gemacht. Gerade in Verbindung mit dem ENC28j60 und den 
TCP/IP-Stack kommt es zu fehler. Ich selber habe eine ganze weile 
gebraucht bis mein Stack relativ Stabil war. Häufigster Grund war 
Fehlerbehandlung und das vor der Abfrage eines Bytes aus einer einer 
Netzwerkverbindung nicht gecheckt wurde ob noch Bytes im Buffer sind und 
dann wenn keine Daten mehr da waren nur miste zurück geliefert wurde. 
Aber das ist nur ein Ansatz war sein kann. Hast du denn eine Vermutung 
wo der Fehler liegen könnte ?

CA Dirk

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. könnts sich auch um thermische Probleme handeln, die ENC wird doch 
recht heiß, wenn ich mich recht entsinne.

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe absolut keine Ahnung. Ich schau mir das jetzt schon ne Weile an 
und habe nebenher bemerkt, dass, sobald ich meine Debugmeldungen nicht 
mehr über RS232 schicken lasse, arge Probleme bekomme. Nichts 
funktioniert mehr so wie es soll.
Da ich die Strings nicht ins Flash ausgelagert habe, glaube ohne diesen 
String-Wust irgendwo eine Zugriffsverlezung zu haben, die sich aufs 
System auswirkt. Vorher könnte das von den Debugstrings "abgefanggen" 
worden sein. Sprich, ich schreib irgendwo hin, wo ich nicht soll. Ich 
kann den Fehler aber einfach nicht lokalisieren. Das nervt mich schon 
den ganzen Tag. Das Programm ist leider scon zu umfangreich um es hier 
sinnvoll posten zu können....

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke es sind eher Timingprobleme. Durch das Deaktivieren der 
Debugausgabe ändert sich das komplette Timing in deiner App, sowohl 
Software wie auch HW-IQRs.

Gruß Hagen

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JA, bei solchen Projekten macht sich es bemerkbar wenn man Treiber und 
App nicht sauber trennen tut. Deshalb habe ich mein Projekt auch zweimal 
angefangen, weil ich gemerkt habe das genau sowas die meisten Probleme 
verursacht. Kann ich nur empfehlen.

CA Dirk

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Wort "Timing" denkt man auch gleich an Race-Conditions, die bspw.
dann eintreten, wenn im Hauptprogramm und in Interrupthandlern auf
gleiche Variablen zugegriffen wird, die größer als die Wortbreite des
Prozessors sind. Um überlappende Zugriffe zu vermeiden, müssen
geeignete Vorkehrungen (bspw. Sperren des Interrupts) getroffen
werden.

Die Wahrscheinlichkeit, dass solche Konflikte tatsächlich eintreten,
sind oft sehr gering, so dass ein Programm trotzdem viele Stunden
fehlerfrei arbeiten kann.

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als TCP/IP Stack nutze ich den uIP Stack, wie so viele. Ich dachte 
immer, dass dort alles ziemlich linear abläuft. Sobald also eine 
Nachricht eintrifft gerate ich in meine Statemachine und empfange auch 
nichts mehr solange ich nicht dort wieder raus komme. Lediglich alle 
100ms wird ein Interrupt ausgelöst. Was der genau macht weiß ich 
garnicht wirklich :) Irgendwas refreschen.
Kann es wirklich daran liegen?
Ansonsten nutze ich keine Interrupts. Ich ging immer vom einem 
Speicherproblem aus, aber wenn so viele hier posten, dass es mit dem 
Timing entwas zu tun haben kann...
Worauf muss ich bei dem Stack noch achten, also timingtechnisch?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem kann alles durch alles mögliche hervorgerufen werden. 
Hardwareprobleme, EMV, Stackoverflow, Timing, ungültige Pointer, ...

Wenn dazu das Programm so groß ist, das man es nicht mehr posten kann, 
und dazu Programmteile verwendet, deren Funktion du weder kennst noch 
verstehst, stehen die Chancen schlecht.

Es nutzt nichts, du musst versuchen, das Problem einzukreisen. Wenn es 
ohne debug-Meldungen nicht mehr funktioniert, nimm die einzeln raus, und 
schau nach, was passiert. Hilfreich ist auch ein Port mit LEDs dran, die 
du zur Kontrolle des Programmablaufes verweden kannst. Das Setzen eines 
Ausgangs ist weit weniger zeitkritisch, als die Ausgabe einer 
debug-Meldung über die uart. Wenn du ganze Programmteile rausnehmen 
kannst, und der Fehler bleibt, um so besser. Dann wird das alles 
übersichtlicher.

Stundenlanges starren auf den Code löst das Problem nicht.

Oliver

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. Das habe ich auch schon gemerkt, aber das Problem einzugrenzen ist 
mir noch nicht gelungen. Momentan habe ich das Problem, dass sobald ich 
Teile bzw. Funktionen auskommentiere, z.B. auf die SD-Karte nicht 
zugreifen kann. Die Funktionenn für die SD-Karte habe ich nicht sleber 
geschrieben, aber an denen wirds wohl auch nicht liegen. Naja. Ich schau 
mir mal den Code nochmal an wenn ich Nerven dafür habe.  :)

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaub den Fehler lokalisiert zu haben.
Es scheint an folgendem Code zu liegen:
Beitrag "PGM_P Array - darf ich das so?"

Was genau der Fehler ist weiß ich aber noch nicht...

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch nicht. Es ist wirklich faszinierend. Sobald ich ein paar 
Debugmeldungen aus dem Code lösche, funktioniert nichts mehr, nicht mal 
die Initialisierung der Bausteine.
Wenn ich die Debugmeldungen aber wieder einfüge ist es nicht sicher, ob 
dann auch wieder alles funktioniert. Ich weiß echt nicht wo zu Suchen 
ist.

Meine Vermutung ist immer noch ein falscher Schreibzugriff auf das SRAM. 
Aber warum wenn die Debugtexte (einfach als String im Programm 
definiert) dafür verantwortlich sind, dass diese falschen 
Schreibzugriffe keine Auswirkungen tragen, warum sind die Debugtexte 
dann richtig. Sprich, kein fehlerhaftes Char, oder ähnliches.

Was kann es also noch sein? Timingprobleme? Der uIP Stack ist eigentlich 
eine große Statemachine. Sobald ich Daten erhalte und diese verarbeiten 
will, kommt in meinen Stack nichts mehr rein an Daten. Erst wenn ich die 
"Statemachine" wieder verlasse, empfange ich wieder daten vom ENC. Daher 
scheiden doppelte Zugirffe auf irgendeinen Speicher aufgrund von 
Timingproblemen für mich aus.

Stackoverflow und falsche Pointer können, meiner Meinung nach, das 
Phänomen auch nicht erklären.

Die Hardware läuft auch problemlos, solange ich keine Debugmeldung 
rausnehme.

Einzelne Programmteile rausnehmen ist auch keine Lösung. Wenns mal nicht 
mehr funktioniert, dann funktioniert das Programm auch nicht mehr wenn 
ich z.B. den SD-Karte-Parser entferne, bei dessen Rückkehr in main der 
Controller dann anfangs immer abschmiert. Das Problem verlagert sich 
dann nur auf andere Codeteile. Das ganze wird dann eine endlose Kette an 
Problemen...


Bin ratlos und mir ist schlecht

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was dir evtl. weiterhelfen könnte.

Wenn du noch ein paar I/Os frei hast:
Schnapp dir ein paar wichtige Routinen/Interrupts und setze beim 
Betreten einen I/O auf High und beim Verlassen wieder auf Low (jeder 
Routine bekommt einen eigenen I/O zugewiesen).

Damit kann man zum Einen die Aufrufreihenfolge der Routinen mit einem 
Logic-Analyzer beobachten/protokollieren und im Falle eines Absturzes 
ungefähr feststellen, wo man sich der Controller gerade befindet. Das 
Ganze sollte dein Timing nur geringfügig verändern. Rekursionen kann man 
damit nicht ohne Weiteres beobachten.

Evtl. hilft auf der Einsatz eines Watchdogs um den Übeltäter 
auszumachen.

Viel Glück noch bei der Suche!

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef Kaeufl wrote:
> Meine Vermutung ist immer noch ein falscher Schreibzugriff auf das SRAM.
> Aber warum wenn die Debugtexte (einfach als String im Programm
> definiert) dafür verantwortlich sind, dass diese falschen
> Schreibzugriffe keine Auswirkungen tragen, warum sind die Debugtexte
> dann richtig. Sprich, kein fehlerhaftes Char, oder ähnliches.

Du gibst doch nicht ständig alle Debugtexte aus, oder? Vielleicht sind 
da ja auch Texte dabei, die nur einmal ausgegeben werden, zum Beispiel 
beim Start des Ganzen.
Möglich ist auch noch was anderes. Durch die Debugtexte ändert sich ja 
auch die Anordnung und Platzierung der anderen Variablen. Mit den Texten 
zeigt der Pointer vielleicht in einen weniger kritischen Bereich, z.B. 
in den hinteren Bereich eines Puffers, der meist nur wenig gefüllt ist.
Denkbar sind da so einige Szenarien.

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai Giebeler wrote:
>
> Damit kann man zum Einen die Aufrufreihenfolge der Routinen mit einem
> Logic-Analyzer beobachten/protokollieren und im Falle eines Absturzes
> ungefähr feststellen, wo man sich der Controller gerade befindet. Das
> Ganze sollte dein Timing nur geringfügig verändern. Rekursionen kann man
> damit nicht ohne Weiteres beobachten.

Tja, wenn ich nur sowas tolles hätte. Ich hab ein Multimeter :)


>
> Viel Glück noch bei der Suche!

Danke.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ganze wird dann eine endlose Kette an Problemen...

Wie isst man einen Elefanten? Stück für Stück...

Wenn du Code rausnehmen kannst, und immer noch Probleme auftreten, dann 
nimm Code raus. Verkleiner das Programm soweit, bis entweder der/die 
Fehler nicht mehr auftreten, du was findest, oder nichts mehr übrig ist. 
Im letzten Fall liegt es dann wohl nicht an der Software :-)

Und auch wenn das Programm groß ist, zip alles zusammen, und poste das 
hier als Anhang. Vielleicht sehen ja ein paar Augen doch mehr, als nur 
ein Paar.

Oliver

Autor: Josef Kaeufl (josefk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das ganze soll mein Diplomarbeit darstellen, die zwar nicht von 
programmamiertechnischer Größe zeugt, aber für mich schon nicht von 
Pappe war.
Soll ich das ganze hier wirklich posten? Evtl bekomme ich da Ärger mit 
der Frima, bei der ich arbeite .)

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, für ein Diplom musst du da schon selber durch.

Falls du doch irgendwann mal eine Kurzversion hinbekommst, die nicht 
allzuviel verrät, aber den Fehler hervorbringt, kannst du dich ja 
nochmal melden.

Oliver

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef Kaeufl wrote:
> Leider hat meine Software nur 37h stand gehalten und ich habe einfach
> keine Ahnung wo ich anfangen soll zu suchen.

Mit dieser Aussage kann man nichts anfangen.

Macht es einen Neustart, bleibt es irgendwo hängen, gehen Interrupts 
noch oder wie genau äußert sich das "nur 37h stand gehalten"?

Wenn es stehen bleibt, kann man nach einem Neustart oder externen 
Interrupt einen RAM- und Register-Dump auf die UART machen.

Interrupt ist schöner, da dann auch wichtige Register (SP, SREG) und der 
letzte PC ausgegeben werden kann.

So und dann sich da durchwühlen, ob man rauskriegt, was die letzte 
Aktion war.


Peter

Autor: Thomas Finke (thomas-hn) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef Kaeufl wrote:
> Hallo zusammen,
>
> ich versuche gerade meine Software mittels einer
> Daten-Bombardement-Software zu testen. Prinzipiell ist mein Programm
> eine Platine mit vielen verchiedenen Schnittstellen, unter denen auch
> ein ENC28J60 ist.

Etwas off-topic bei dem Problem hier, aber:
Mit welcher "Daten-Bombardement-Software" testest Du das denn?

Viele Grüße,

Thomas

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.