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?
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
Evtl. könnts sich auch um thermische Probleme handeln, die ENC wird doch recht heiß, wenn ich mich recht entsinne.
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....
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
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
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.
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?
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
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. :)
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...
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
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!
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.
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.
>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
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 .)
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
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.