-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: Programmabstürze

  1. #1
    Erfahrener Benutzer Begeisterter Techniker Avatar von PCMan
    Registriert seit
    05.08.2006
    Ort
    Munich
    Beiträge
    311

    Programmabstürze

    Anzeige

    Hallo Leute, ich bin mal wieder am Ende meiner Ideen.
    Ich habe ein Programm, dass in festen Intervallen (sagen wir mal 15 min) eine Aktion ausgeführt. Genauergesagt soll alle 15 min eine Pumpe in betrieb genommen werden, eine ADC-Messung durchgeführt werden und fertig. ein einfaches Messystem also. Das System funktioniert auch vom Prinzip, nur stürzt es irgendwann ab. Wie macht sich das bemerkbar? Nun das System reagiert auf keine UART Signale mehr oder auch nicht auf Tastendrücke. Ich bin meinen Code schon einige male durchgegangen, aber ich kann den Fehler einfach nicht finden. Daher nun meine Frage: kann man irgendwie herausfinden, wieso ein Programm stehen bleibt?
    Dann wollte ich euch noch fragen, wie kritisch globale structs sind: ich habe da eine globale struct variable, die sich system nennt. Sie vereint verschiedene Typen, z.b. einen Pointer, ein paar Bitfelder, uint8_ts oder uint16_ts aber auch eine float. Müssen diese Structs eigentlich immer ein ganzzahliges von einem Byte an Größe haben?
    Grüße Simon

  2. #2
    Erfahrener Benutzer Begeisterter Techniker Avatar von PCMan
    Registriert seit
    05.08.2006
    Ort
    Munich
    Beiträge
    311
    Nachtrag: ich würde gerne feststellen, ob es sich um ein Speicherproblem handelt. Gibt es eine Möglichkeit das festzustellen?
    Die Ausgabe erhalte ich nach dem Compilieren:
    avr-size -C --mcu=atmega32 main.elf

    AVR Memory Usage
    ----------------
    Device: atmega32

    Program: 21518 bytes (65.7% Full)
    (.text + .data + .bootloader)

    Data: 330 bytes (16.1% Full)
    (.data + .bss + .noinit)
    Das sagt aber noch nicht aus, ob mein Speicher zur Laufzeit voll wird oder?

    Grüße Simon

  3. #3
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.186
    Solche Abstürze können auch von aussen kommen, ein Hacker in der Stromversorgung, ein Gerät, Leuchstoffröhre und dergleichen das schaltet.
    Eventuell den Watchdog aktivieren.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  4. #4
    Erfahrener Benutzer Begeisterter Techniker Avatar von PCMan
    Registriert seit
    05.08.2006
    Ort
    Munich
    Beiträge
    311
    Hi,
    hm ja an soetwas habe ich auch gedacht, weil wie gesagt, das Programm funktioniert und stürzt völlig willkürlich ab - nicht immer an der gleichen stelle.
    Watchdog ist gut, kann ich aber dann das Programm in den Zustand vor dem Absturz zurücksetzen?

    Grüße Simon

  5. #5
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.186
    Ich habe den Watchdog bisher nur so genutzt das das Programm einen Reset ausgeführt hat, vielleicht gibt es noch andere Möglichkeiten, aber zurückversetzen wird sicher nicht gehen.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  6. #6
    Erfahrener Benutzer Roboter Experte Avatar von BurningWave
    Registriert seit
    22.12.2007
    Ort
    nahe Stuttgart
    Alter
    23
    Beiträge
    656
    vielleicht gibt es noch andere Möglichkeiten, aber zurückversetzen wird sicher nicht gehen.
    Vielleicht mit einem externen RAM, auf dem man immer den jeweiligen Zustand speichert und ihn das Programm bei einem Reset ausliest und zur entsprechenden Stelle springt. Das dürfte aber kompliziert werden.

    mfg

  7. #7
    Erfahrener Benutzer Begeisterter Techniker Avatar von PCMan
    Registriert seit
    05.08.2006
    Ort
    Munich
    Beiträge
    311
    Hm okay danke schonmal für eure anreize. Ich hatte früher eine andere "Firmware" auf dem AVR und mir ist das teil nicht abgestürzt. Mein Bauch sagt mir irgendwie, dass es sich eher um ein Softwareproblem handelt. Das dumme ist nur, ich kann einfach nicht herausfinden *wo* sich der Feler befindet. Ich lasse das gerät jetzt ein paar mal den gleichen Lauf machen und dann schaue ich, ob es immer zur gleichen Zeit abstürzt.

    Ich habe auch die ganzen ISRs soweit geleert, dass da nur Flags gesetzt werden. Es gibt jedoch einen Unterschied zur vorherigen Version, nämlich das der UART permanent überwacht wird. Eine Frage ist auch noch unbeantwortet, nämlich wie das mit globalen structs ist, die sich aus verschiedenen Typen zusammensetzen. Mag das z.B. der Controller nicht, wenn das Struct eine Feldgröße von sagen wir mal 29 Bytes hat oder so?

    Viele Grüße und Danke für's Helfen,
    Simon

  8. #8
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Dem Controller ist es egal welche größe die Struct elemente habe. Es könnte aber sein das der Compiler bei einigen größen weniger effectiven Code erzeugt.

    Software-Fehler sind manchmal schwer zu finden, besonders sowas wie Bufferoverflows oder ein Heap-overflow. Bei gut 20 K code kann man da nur viel Spass beim suchen wünschen. Dabei frage ich mich wo der ganze Code herkommt für so eine einfache Aufgabe.

  9. #9
    Erfahrener Benutzer Begeisterter Techniker Avatar von PCMan
    Registriert seit
    05.08.2006
    Ort
    Munich
    Beiträge
    311
    Na du bist lustig, aus meiner Beschreibung kann man doch garnicht wissen wie umfangreich das Ganze ist
    Naja immerhin ist eine UART schnittstelle und entsprechende Befehlsabarbeitung implementiert, ein Menü mit Navigation (dazu halt eben das Klimbim für's Display), eine kleine Sammlung zum ablegen von Daten auf externe EEPROMS, Ansteuerung zweier Schrittmotoren, bissl ADC-Krams für die Messung. Naja da kommt halt mit der Zeit einiges zusammen. KLAR: man kann den Code sicherlich noch viel weiter optimieren und verkleinern, deswegen bin ich ja auch kein "Robotk Einstein" wie Besserwessi. Der Punkt ist jedenfalls, dass ein Großteil der Routinen auf anderen Systemen von mir im Einsatz waren und keine Instabilitäten verursacht haben und noch viel weniger sehe ich garkeinen logischen Zusammenhang, wann das Programm "stehen" bleibt. Mal passiert das nach 10min, dann mal nach 500min, das ist total unterschiedlich. Deswegen dachte ich es gäbe da evtl ein paar Tipps, wo man mit der Fehlersuche anfangen könnte - zB Spannungsversorgung.
    Daher versuche ich jetzt mal nach und nach eine Fehlerquelle nach der anderen auszuschließen, bevor ich wirklich zuletzt wohl die ganze Software ummodeln darf ohne wirklich den Fehler gefunden zu haben.
    Es scheint auch tatsächlich so zu sein, dass die ISRs auch nicht mehr ausgeführt werden - also eine art DeadLock.

  10. #10
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die Fehler Suche ist wirklich nicht einfach. Ein erster Test wäre eventuell mal eine relativ einfaches Programm wo hoffentlich dann kein Fehler mehr drin ist laufen zu lassen, um Hardwarefehler weitgehend auszuschsließen. Das Programm muß da eigentlich nur feststellen ob der Controller sauber druchläuft ohne Aussetzer.

    Bei der Hardware ist die Spannungsversorgung sicher eine Fehlerquelle. Eventuell gibt es auch Störungen auf Externen Interrupt pins, die wieder erwarten doch aktiv sind ? Gefährich ist auch immer eine Rückwirkung der Motoren auf die Spannungsversorgung des µC. Hardware Fehler zu finden, die nur sehr selten auftreten ist aber wirklich schwer. Das ist die unangenehmste Sorte.
    Hänger durch Hardware Fehler sind aber eher schwer vorstellbar. Meistens geht dann gar nichts mehr, oder das Programm startet einfach wieder von vorne.

    Bei Software-problemen sollte man mal mit einer Version vergleichen, die noch ohne Hänger lief.

    Kann es bei mehreren ISRs eventuell dazu kommen, das eine ISR gar nicht mehr ausgeführt wird, oder ist die ISR belastung eher gering ?
    So tückische Sachen wie ISRs die den Interrupt wieder freigeben sind doch hoffentlich nicht drin oder ? Die sind nämlich sehr Fehleranfällig. Zu debugzwecken kann es Hilfreich sein wenn man den Anfang einer ISR von Außen erkennen kann (z.B. LED aufblinken). Mit der UART könnte man auch an makanten Punkten im Programm jeweils einen Buchstaben schicken und das dann in ein File Speichern. So kann man eventeulle grob einkreisen was zuletzt gemacht wurde. Man braicht sich von dem möglicherweise riesigen File ja in der Regel nur das Ende ansehen. Ist aber auch eine Menge Aufwand, wenn man das nicht sowieso noch drin hat.

    Wie sieht es denn mit dem dynamischen Speicherverbrauch aus ? Besteht die Gefahr, das das RAM voll wird ?

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •