Forum: Compiler & IDEs Komischer Avr Reset nach 2h


von Peter (Gast)


Angehängte Dateien:

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

von Karl H. (kbuchegg)


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.

von Werner B. (werner-b)


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.

von g457 (Gast)


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..

von Peter (Gast)


Angehängte Dateien:

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:
1
thron:~$ avr-gcc -v
2
Using built-in specs.
3
Target: avr
4
Configured with: ./configure --target=avr --disable-libssp
5
Thread model: single
6
gcc version 4.2.2
Zur Not muss ich mir mal einen aktuellen bauen.

von Karl H. (kbuchegg)


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?

von Peter (Gast)


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.

von Martin (Gast)


Lesenswert?

Geschieht das Neustarten exakt nach der gleichen Zeit?

von Martin (Gast)


Lesenswert?

'immer' bitte noch einfügen.

von Peter (Gast)


Lesenswert?

ne das schwankt von 1:45 bis 2:30

von hdd (Gast)


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

von ... (Gast)


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"

von g457 (Gast)


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

von Peter (Gast)


Lesenswert?

CKOPT ist gesetzt.
Das mit dem MCUCSR probier ich gleich mal mit aus.

von Karl H. (kbuchegg)


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.

von Matthias (Gast)


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...

von Bernhard R. (barnyhh)


Lesenswert?

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

Bernhard

von Peter (Gast)


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.

von Peter (Gast)


Angehängte Dateien:

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von Peter (Gast)


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.

von g457 (Gast)


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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von g457 (Gast)


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?

von Matthias (Gast)


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!

von Peter (Gast)


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

von Karl H. (kbuchegg)


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
1
  for(;;)
2
  {
3
    
4
    sht11_start_measure();
5
    do
6
    {
7
      flag = sht11_measure_finish();
8
    } while ( flag != 1 );
9
    
10
    usart_put("\n\n Temperatur Raw: ");
11
    usart_put("%i",sht11_get_temp_raw(0));
12
    
13
    usart_put("\n Temperatur: ");
14
    usart_put("%i",sht11_get_temp(0));
15
    
16
    usart_put("\n Feuchte Raw: ");
17
    usart_put("%i",sht11_get_hum_raw(0));
18
    
19
    usart_put("\n Feuchte: ");
20
    usart_put("%i",sht11_get_hum(0));
21
    
22
    usart_put("\n\n Temperatur Raw 1: ");
23
    usart_put("%i",sht11_get_temp_raw(1));
24
    
25
    usart_put("\n Temperatur 1: ");
26
    usart_put("%i",sht11_get_temp(1));
27
    
28
    usart_put("\n Feuchte Raw 1: ");
29
    usart_put("%i",sht11_get_hum_raw(1));
30
    
31
    usart_put("\n Feuchte 1: ");
32
    usart_put("%i",sht11_get_hum(1));
33
    
34
    for(long counter=0 ; counter<500 ; counter++)
35
    {
36
      _delay_ms(10);
37
    }
38
  }
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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?

von Peter (Gast)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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?

von ... ... ... (Gast)


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... ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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).

von ... ... ... (Gast)


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.

von Karl H. (kbuchegg)


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.

von Bernhard R. (barnyhh)


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

von Peter (Gast)


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.

von Falk B. (falk)


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

Bitte 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
Noch kein Account? Hier anmelden.