mikrocontroller.net

Forum: Compiler & IDEs Komischer Avr Reset nach 2h


Autor: Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
weiss nicht ganz genau ob das hier das richtige Unterforum ist, aber 
probiers doch mal.
Mittels des angehängten Programmes lese ich ständig über UART zwei 
Sensoren aus. Die Daten werden über einen FT232r an den Rechner 
gesendet, wo sie dann mittels Script in eine Datenbank geschaufelt 
werden. Das funktioniert auch gut. Nur das sich nach zwei Stunden der 
Avr resetet, erkenne ich daran das der erste String wieder gesendet 
wird.
Fällt vielleicht jmd. ein, woran das liegen könnte? Wäre echt ne super 
Hilfe, bin da leicht am verzweifeln.
Danke für die Hilfe

Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du würdest viel mehr Antworten bekommen, wenn du dein Projekt in ein ZIP 
File verpackst, anstelle eines TAR-GZ, welches dann auch noch nicht 
fehlerfrei entpackt werden kann.

Mach es deinem Helfenden einfach dir zu helfen!
WinZip oder etwas vergleichbares haben die meisten auf der Maschine.

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie die Files aussehen stammen sie von einem MAC.
Welche AVR-gcc Version mit welchen Patches ist da drauf?

Das Problem könnte am Compiler bzw. fehlenden Patches liegen und nicht 
unbedingt am Quellcode.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> WinZip oder etwas vergleichbares haben die meisten auf der Maschine.

Winzip glaube ich nicht dass bei ihm läuft, denn das ist ein Mäc :-) 
Nichtsdestotrotz wäre ein funktionierende(re)s Archiv nett.. mein 
file-roller mags auch nur im zweiten Anlauf.. tar dagegen meckert 
nicht.. sehr komich..

Autor: Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
sorry ich hatte nicht damit gerechnet, das das tar Probleme macht, 
deswegen noch mal als rar. Das sollte hoffentlich überall laufen.
Jo meine Maschine ist ein Mac mit OSX 10.4, bezüglich des avr-gcc kann 
ich nicht mehr genau sagen, welche Patches ich damals installiert hab, 
das schon ne ganze Weile her.
avr-gcc -v bringt jedenfalls:
thron:~$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ./configure --target=avr --disable-libssp
Thread model: single
gcc version 4.2.2
Zur Not muss ich mir mal einen aktuellen bauen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Drüberscrollen ist da jetzt nichts von den 'üblichen Verdächtigen' 
ins Auge gesprungen.

> Nur das sich nach zwei Stunden der
> Avr resetet, erkenne ich daran das der erste String wieder gesendet
> wird.

Welches ist die Ausgabe vor dieser "Reset-Meldung".
Ist das immer dieselbe oder variiiert die?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vor der for(;;)-Schleife, die ja nie verlassen werden soll, steht:
usart_put("\nAusgabe von aktueller Temp. und Feuchte!");
Die wird bei mir im Script am Rechner ausgewertet und die kommt nach 2h 
etwa und das sagt ja das der Avr neugestartet wurde.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geschieht das Neustarten exakt nach der gleichen Zeit?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'immer' bitte noch einfügen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ne das schwankt von 1:45 bis 2:30

Autor: hdd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab das Programm jetzt nicht angeschaut aber könnte es sein, dass dir 
irgendwann der Stack über- oder unterläuft -> falsche Rücksprungadresse 
-> Reset

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CKOPT nicht gesetzt?
Eventuell auch mal MCUCSR auslesen und mit in die Meldung packen.
Vielleich auch sowas wie hier?
Beitrag "Atmega16 resetiert ohne ersichtlichen Grund"

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..so rein aus persönlicher Paranoia: Schick Dir doch mal nach dem 
Startup das MCUCSR mit, nicht dass da alle zwei Stunden der anlaufende 
Heizlüfter einen BOR verursacht.. oder an der Antenne am RESET-Pin 
wackelt.. oder der USB-Hub eine Aussetzer hat (letzteres hat mich schon 
mal erfolgreich einige graue Haare gekostet.. man sollte halt 
$billigschrott nicht aufs Labornetzgerät legen, das wird nämlich 
irgendwann warm..)

HTH

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CKOPT ist gesetzt.
Das mit dem MCUCSR probier ich gleich mal mit aus.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Vor der for(;;)-Schleife, die ja nie verlassen werden soll, steht:
> usart_put("\nAusgabe von aktueller Temp. und Feuchte!");
> Die wird bei mir im Script am Rechner ausgewertet und die kommt nach 2h
> etwa und das sagt ja das der Avr neugestartet wurde.

Das ist mir schon klar.
Aber was wurde unmittelbar davor gesendet?
Ist das immer das gleiche oder variiert das?

Worauf ich hinaus will: Passiert der Absturz an immer der gleichen 
Stelle im Programm oder verteilt sich das gleichmässig.

Ersteres wäre ein Hinweis auf ein Softwareproblem, letzteres ein Hinweis 
auf ein Hardwareproblem. Das muss nicht 100% das jeweilige Problem sein, 
aber es wäre zumindest mal ein Hinweis.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das eine kpmplette Marke Eigenbau Schaltung mit FT232R?

Wenn ja, dann wäre es vielleicht hilfreich ein Schaltbild zu haben.
Dann kann man evtl. ein paar HW Bugs ausschließen...

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke ebenfalls, daß hier durchaus ein Hardware-Problem vorliegen 
kann; daher sind Schaltplan und Foto des Aufbaus zur Analyse durchaus 
hilfreich.

Bernhard

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so gerade wieder ausgestiegen, also MCUCSR zeigt nach dem Reset den 
selben Wert wie vorher: 0x1
So wie es scheint steigt er immer an der selben Stelle aus. Das letzte 
was angezeigt wird ist Feuchte 1 plus Wert, bzw hab ich danach jetzt die 
Anzeige des MCUCSR eingefügt, also scheint er in der delay-Schleife 
hängenzubleiben.

Autor: Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry letzten beiden Beiträge übersehen. Das ganze ist zur Zeit auf 
einem Steckbrett realisiert. Standartbeschaltung des Atmega, Reset mit 
100nF gegen Masse, 10k gegen 5V, Quartz mit 22pF gegen Masse, AVCC an 
5V, AREF offen, 5V mit 5V verbunden und GND mit GND. Der FT232 sitzt auf 
der Platine siehe Anhang.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Du würdest viel mehr Antworten bekommen, wenn du dein Projekt in ein ZIP
> File verpackst, anstelle eines TAR-GZ, welches dann auch noch nicht
> fehlerfrei entpackt werden kann.

Nanu, kann Winzip neuerdings keine .tar.gz-Archive mehr auspacken?
Kann natürlich sein, dass Windows Dateien wie "prog/._.DS_Store"
nicht so toll mag, aber der Entpacker sollte doch damit klar kommen.

Irgendwas offensichltich Schräges finde ich darin aber auch nicht,
sind ja nicht einmal Interrupts aktiv.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> so gerade wieder ausgestiegen, also MCUCSR zeigt nach dem Reset den
> selben Wert wie vorher: 0x1

PORF, das ist natürlich immer erstmal zu sehen (irgendwann gab es
ja auf jeden Fall mal einen power-on reset).  Die Flags musst du
nach dem Auswerten löschen, wenn du sie später nicht nochmal sehen
willst, die werden nie automatisch gelöscht.

Wenn das PORF aber trotz des Löschens später wieder auftaucht,
dann ist es wohl dein Steckbrett, was dir einen Streich spielt.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn es am Steckbrett liegen würde, wäre das nicht schlimm, da das noch 
ne ordentliche Platine bekommt. Gut werd das mit dem löschen noch mal 
probieren.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> CKOPT ist gesetzt.

Nur der Vollständigkeit halber: Heisst das 'Häkchen in Ponyprog' oder 
'programmed (0)' (Atmel-Speak) oder 'unprogrammed (1)' (Atmel-Speak). 
Und nimmst du einen externen Quarz/.. oder den internen RC? Das Phänomen 
mit unerklärlichen Interrupts (die ohne BAD_ISR-Handler zu einem Reset 
führen) hatte ich auch schon mal wegen eines vergessenen CKOPT.

> MCUCSR zeigt nach dem Reset den selben Wert wie vorher: 0x1

Hast Du hast die Flags zwischenzeitlich zurückgesetzt?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
g457 schrieb:
> Das Phänomen
> mit unerklärlichen Interrupts (die ohne BAD_ISR-Handler zu einem Reset
> führen) hatte ich auch schon mal wegen eines vergessenen CKOPT.

Aber er hat ja die Interrupts nicht einmal freigeschaltet.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dl8dtl schrub:
> Aber er hat ja die Interrupts nicht einmal freigeschaltet.

Das ist richtig :-) Und es gibt mir die Gelegenheit einen 
vervollständigenden korrigierenden Nachtrag zu liefern, ohne einen auf 
ingrid zu machen ;-) : Bei mir (m32 auf Steckbrett, schlauerweise liegt 
der UART genau nebem den Quarz, sonst hätt ich wahrscheinlich noch lange 
gesucht) hat besagtes fehlendes CKOPT bei Datenübertragungen vom PC 
(mindestens) zu folgenden Problemen geführt: sporadische Resets (hab 
MCUCSR nicht geprüft wer da zugeschlagen hat) und gelegentlich Sprung in 
den BAD_ISR. Und gelegentlich hats zu Flimmern auf dem 
(Pixelclocking-)Display geführt - den genauen Wirkzusammenhang dafür 
konnte ich nicht ausfindig machen, möglicherweise wegen verfrühter 
Timer-Interrupts..

So, ich hoffe ich konnte das jetzt korrigieren .

Zu des TOs Schaltplänchen hab ich noch eine Frage: Bekommt der µC den 
Strom (nur) vom USB oder hat der eine eigene Energieversorgung?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich würde mal rein prophylaktisch am USB zwischen
+5V, A, B jeweils einen 47pF Kondensator gegen GND
hinzufügen. Da deine Schaltung "Bus powered" ist (wenn ich jetzt keinen
Knick in der Optik habe), dann würde ein Reset am USB-Hub auch deine 
Schaltung zurücksetzen.

Manche USB-Hubs sind sehr empfindlich was EMV betrifft!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus, also CKOPT ist programmed. Am FT232r-Board sollte es nicht 
liegen, da das auch an anderer Stelle ohne Probleme eingesetzt wird, das 
MCUCSR meldet nun 0x2, was external Reset Flag bedeuten sollte.
Ist auch wieder an der gleichen Stelle abgebrochen nach der letzten 
Ausgabe vor der delay-Schleife. Also Abbruch immer an der selben Stelle.
Gute Nacht erstmal und danke für die vielen Überlegungen.

Gruß Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:

> Ist auch wieder an der gleichen Stelle abgebrochen nach der letzten
> Ausgabe vor der delay-Schleife.

Ist der letzte Ausgabetext vollständig?

Gut das sagt jetzt erst mal nicht viel
In
  for(;;)
  {
    
    sht11_start_measure();
    do
    {
      flag = sht11_measure_finish();
    } while ( flag != 1 );
    
    usart_put("\n\n Temperatur Raw: ");
    usart_put("%i",sht11_get_temp_raw(0));
    
    usart_put("\n Temperatur: ");
    usart_put("%i",sht11_get_temp(0));
    
    usart_put("\n Feuchte Raw: ");
    usart_put("%i",sht11_get_hum_raw(0));
    
    usart_put("\n Feuchte: ");
    usart_put("%i",sht11_get_hum(0));
    
    usart_put("\n\n Temperatur Raw 1: ");
    usart_put("%i",sht11_get_temp_raw(1));
    
    usart_put("\n Temperatur 1: ");
    usart_put("%i",sht11_get_temp(1));
    
    usart_put("\n Feuchte Raw 1: ");
    usart_put("%i",sht11_get_hum_raw(1));
    
    usart_put("\n Feuchte 1: ");
    usart_put("%i",sht11_get_hum(1));
    
    for(long counter=0 ; counter<500 ; counter++)
    {
      _delay_ms(10);
    }
  }  
kann der Absturz irgendwo zwischen dem letzten usart_put in der Schleife 
und dem ersten sein. Da liegt die Warteschleife dazwischen aber auch 
deine komplette State-Maschine.
Man müsste sich da jetzt weitere Ausgaben einbauen, um den Ort genauer 
eingrenzen zu können. Insbesondere in die State-Maschine

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> das
> MCUCSR meldet nun 0x2, was external Reset Flag bedeuten sollte.

Dann wäre das Problem aber immer noch in der Hardware.

Ich denke, du solltest dir erstmal eine sauberere Hardwareplattform
bauen, vielleicht ja die, auf der das Ganze am Ende dann laufen soll?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo noch mal,
also ich kann jetzt mit Gewissheit sagen, dass er in der delay-Schleife 
aussteigt.
Die Platine kommt erst in 2 Wochen, ich werd mal nen anderes Steckbrett 
probieren.
Danke für die ganzen Überlegungen

Gruß
Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Die Platine kommt erst in 2 Wochen, ich werd mal nen anderes Steckbrett
> probieren.

Steckbretter mit ihren riesigen Kapazitäten sind einfach Mist.

Kannst du nicht irgendwie was auf Lochraster zusammenpappen?

Autor: ... ... ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Karl heinz Buchegger schrieb:
>> Du würdest viel mehr Antworten bekommen, wenn du dein Projekt in ein ZIP
>> File verpackst, anstelle eines TAR-GZ, welches dann auch noch nicht
>> fehlerfrei entpackt werden kann.
> Nanu, kann Winzip neuerdings keine .tar.gz-Archive mehr auspacken?
> Kann natürlich sein, dass Windows Dateien wie "prog/._.DS_Store"
> nicht so toll mag, aber der Entpacker sollte doch damit klar kommen.
Ich persönlich find ja gut, dass er auf die Aufforderung ZIP zu 
verwenden, mit einer RAR-Datei kontert... ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... ... ... schrieb:

> Ich persönlich find ja gut, dass er auf die Aufforderung ZIP zu
> verwenden, mit einer RAR-Datei kontert... ;-)

Wobei's mich als Benutzer unixoider Betriebssysteme eigentlich
überhaupt nicht interessiert. ;-)  Ob ich nun tar, unzip oder unrar
eintippe, ist mir mittelmäßig wurscht (hab' mir das rar-Archiv
allerdings dann nicht nochmal angeguckt).

Autor: ... ... ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> ... ... ... schrieb:
>> Ich persönlich find ja gut, dass er auf die Aufforderung ZIP zu
>> verwenden, mit einer RAR-Datei kontert... ;-)
> Wobei's mich als Benutzer unixoider Betriebssysteme eigentlich
> überhaupt nicht interessiert. ;-)  Ob ich nun tar, unzip oder unrar
> eintippe, ist mir mittelmäßig wurscht (hab' mir das rar-Archiv
> allerdings dann nicht nochmal angeguckt).
Hier ist es ähnlich (Linux), aber auf dem einen, letzten Windows fault 
ein 7zip vor sich hin, der öffnet sie (rar, zip, tar.gz/tgz) auch alle.
Wobei ab Win XP man zumindest für ZIP keinen extra Entpacker mehr 
braucht, daher würde ich immer ZIP nehmen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem RAR hatte ich auch keine Problem.

Nur im Original.
Klick im Forum auf die Datei. WinZip geht auf.
Ich seh das TAR Archiv, klicke es an und krieg eine Fehlermeldung.

OK. SO wie es aussieht ist das irgendein Problem bei mir lokal 
(wahrscheinlich irgendwas mit temporären Dateien)
Ich werds trotzdem nicht richten :-) Normale Zip-File, RAR Files, ... 
alles kein Problem.

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist überhaupt nicht überraschend, daß der Prozessor in der 
Delay-Routine "aussteigt", denn er befindet sich den weitaus 
überwiegenden Teil der Zeit genau in dieser Verzögerungsschleife. Zum 
einfacheren Test sollte die Verzögerung möglichst ganz eliminiert 
werden. Ich denke, daß der Programmabsturz dann heftigst durch den 
gesamten Code wandern wird.

Bernhard

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich wollt noch mal eine krze Rückmeldung geben. Also ich hab jetzt 
die delay Schleife durch nen Timer ersetzt und seitdem laeuft der 
Controller seit mehr als 12h am Stück ohne Probleme.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Peter (Gast)

>Hi, ich wollt noch mal eine krze Rückmeldung geben. Also ich hab jetzt
>die delay Schleife durch nen Timer ersetzt und seitdem laeuft der
>Controller seit mehr als 12h am Stück ohne Probleme.

Klingt nach einem Zugriffsproblem mit Interruptvariablen, siehe Artikel 
Interrupt, Stichwort volatile und atomar.

MFG
Falk

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.