ATmega64 spinnt

[Hans (Gast)]

Hi!

Dickes Problem:
Mein ATmega64 hängt sich nachdem er eine Weile einwandfrei lief auf 
komische Art und Weise auf. Übers UART kommt kurz Schmarn bis es durch 
eine Ausgabe zeigt dass das Programm wieder von vorne beginnt, ein 
Resetgrund gibt es aber scheinbar nicht (wird ebenfalls am Beginn des 
Programms ausgegeben) also gibt es auch kein Reset - von diesem 
Standpunkt gehe ich jetzt mal aus. Das alles deutet ja darauf hin, dass 
der Programcounter irgendwie wieder zurückgesetzt wird.
Aber WARUM???

Ich wäre froh wenn ich an der Stelle weiterkommen würde.

MfG Hans

[Holger K. (krulli)]

Schaltung? Programm? Sind wir Hellseher?

[Hans (Gast)]

Hellseher nicht aber vielleicht erfahren was solche Probleme angeht.
Da ich nicht die geringste Ahnung habe woran das liegen könnte, kann ich 
auch kaum gezielt Codeausschnitte zeigen. Ein Hinweis - bezogen auf die 
Hardware - wäre, dass ich PEN offengelassen hab. Sonst hängt die 
vielfach bewährte Standardbeschaltung dran, bei der ich (auch wenns 
engstirnig klingt) den Fehler im Moment nicht suchen will.

[Hans (Gast)]

Vielleicht doch noch was: Ich verwende den externen Interrupt INT2, 
könnte der Programcounter irgendwie vom Interrupt negativ beeinflusst 
werden?

[Björn W. (bwieck)]

Hans wrote:
> Vielleicht doch noch was: Ich verwende den externen Interrupt INT2,
> könnte der Programcounter irgendwie vom Interrupt negativ beeinflusst
> werden?

Ja, wenn dein Stack nicht korrekt behandelt wird...
Dann springt der PC irgendwann an eine undefinierte Stelle.


Grüße
Björn

[Peter D. (peda)]

Hans wrote:
> Mein ATmega64 hängt sich nachdem er eine Weile einwandfrei lief auf
> komische Art und Weise auf. Übers UART kommt kurz Schmarn bis es durch
> eine Ausgabe zeigt dass das Programm wieder von vorne beginnt

Klingt nach Stacküberlauf, d.h. Dein Stack läuft in die Daten rein und 
wird zerstört.
Warscheinlich hast Du konstante Daten nicht in den Flash plaziert.


Peter

[Hans (Gast)]

Peter Dannegger wrote:
>Klingt nach Stacküberlauf, d.h. Dein Stack läuft in die Daten rein und
>wird zerstört.
>Warscheinlich hast Du konstante Daten nicht in den Flash plaziert.

konstante Daten kann man doch garnicht anders als in den Flash 
platzieren.
Wie kann ich rausfinden wieviel Stack noch frei is?

Gruß
Hans

[Hans (Gast)]

Die Frage war überflüssig, es hat ja gar keinen Wert sich den 
Stackpointer ausgeben zu lassen weil er ja - vorausgesetzt das Programm 
hat keine Fehler - sich immer an gleicher Stelle befindet zum Zeitpunkt 
der Ausgabe.
Ich glaube das Problem ist ein anderes. Was genau passiert beim Überlauf 
einer Variable außer dass C gesetzt wird? Besteht die Möglichkeit dass 
der uC sich aufhängt auch wenn die Variable in keinem Zusammenhang mit 
anderen Programmfunktionen steht?

[Karl H. (kbuchegg)]

Hans wrote:
> Die Frage war überflüssig, es hat ja gar keinen Wert sich den
> Stackpointer ausgeben zu lassen weil er ja - vorausgesetzt das Programm
> hat keine Fehler - sich immer an gleicher Stelle befindet zum Zeitpunkt
> der Ausgabe.

Kommt drauf an, wo der Aufruf der Ausgabefunktion platziert wird.

> Ich glaube das Problem ist ein anderes. Was genau passiert beim Überlauf
> einer Variable außer dass C gesetzt wird?

Du meinst arithmetischer Überlauf?
C wird gesetzt.
Sont passiert: nichts

> Besteht die Möglichkeit dass
> der uC sich aufhängt auch wenn die Variable in keinem Zusammenhang mit
> anderen Programmfunktionen steht?

Durch einen Überlauf?
Nein. Diese Möglichkeit besteht nicht.

In welcher Sprache programmierst du denn eigentlich?

[Hans (Gast)]

Auch diese Frage hat sich erübrigt...

[Hans (Gast)]

:) da hat aber einer schnell geantwortet
Ich programmiere in C.

[Karl H. (kbuchegg)]

Hans wrote:
> :) da hat aber einer schnell geantwortet
> Ich programmiere in C.

Sporadische, seltsame Fehler in C sind häufig auf
Array-Overflows bzw. Schweinereien mit funktionslokalen
Variablen (auch hier sind Array Overflows ein heisser
Kandidat) zurückzuführen.

[Kai G. (runtimeterror)]

Bei ASM wäre mir noch eingefallen, dass die Interrupttabelle falsch 
initialisiert wurde... INT 2 oder andere Ereignisse springen dann ggf. 
ins Nirvana.

Möglichkeit 2 wäre gewesen, dass der Instruction Pointer über das 
Programmende hinausläuft... 17 Kilometer später kommt der soweit ich 
weiß wieder am Anfang an - sieht dann halt aus wie'n Reset.

Welche Möglichkeiten es da in C gibt sowas zu fabrizieren weiß ich 
nicht. Ich würde das Programm auf jeden Fall mal im Debugger laufen 
lassen.

Ach ja: Was ist mit dem Quellcode? Welches Eval-Board o.ä.? Fuses, 
Clocking, etc.?

[Peter D. (peda)]

Hans wrote:
> Peter Dannegger wrote:
>>Klingt nach Stacküberlauf, d.h. Dein Stack läuft in die Daten rein und
>>wird zerstört.
>>Warscheinlich hast Du konstante Daten nicht in den Flash plaziert.
>
> konstante Daten kann man doch garnicht anders als in den Flash
> platzieren.

Eben nicht!

Der C-Standard kennt keine Harward Architektur und daher landen alle 
Variablen grundsätzlich im SRAM.

Und wenn es Ausgabetexte sind und diese mit Returnadressen überschrieben 
werden, sendet die UART eben Müll.

Erst, wenn Du compilerspezifische Syntaxerweiterungen benutzt, kannst Du 
das verhindern.
Schau mal im Manual Deines Compilers nach, wie das geht.


Peter

[Hans (Gast)]

Kai Giebeler wrote:
>Möglichkeit 2 wäre gewesen, dass der Instruction Pointer über das
>Programmende hinausläuft... 17 Kilometer später kommt der soweit ich
>weiß wieder am Anfang an - sieht dann halt aus wie'n Reset.
Das war auch mein erster Gedanke, aber wie kann das passieren?

>Ich würde das Programm auf jeden Fall mal im Debugger laufen
>lassen.
Das wärs! Einen Debugger bräuchte man! Aber selbst wenn ich einen hätte, 
könnte ich dann den Fehler herausfinden, wenn das Problem erst 
IRGENDWANN willkürlich auftritt?

Hier die Abweichungen von den Standard fusesettings:
-ATmega103 Compatibility Mode Disabled
-On-Chip Debug Disabled
-JTAG Interface Disabled
-Boot Reset vector Enabled
-Brown-Out detection level at VCC=4.0 V
-Brown-Out detection enabled
-Ext. Crystal/Resonator High Freq.; Start-up time: 16K CK + 64 ms

Ich verwende einen 16MHz Quarz.

Compiler: WinAVR GCC 4.1.1.

Was ich noch nicht genannt habe, ist dass oftmals nach dem Auftreten des 
Problems der uC gar nicht zu starten scheint. Erst nach einer Weile oder 
mehreren Versuchen startet das Programm wieder ordnungsgemäß nach 
Anlegen der Betriebsspannung.

[Hans (Gast)]

Folgendes:
Kann es sein, dass wenn global interrupt immer enabled ist, es zu 
Fehlern kommen kann beispielsweise beim Zurückspringen aus Funktionen 
oder bei SPI Übertragung etc.?
Denn Fakt ist, dass in meinem Programm immer GI enabled ist.

[Kai G. (runtimeterror)]

Wenn du dir sicher bist, dass es nicht am Quelltext liegt, dann lass den 
Debugger halt.

Such dir aus, wo du den Fehler suchen willst:
- Software: schick den Quelltext
- Hardware: schick den Schaltplan
- AVR: setz nen frischen ein

ich halte übrigens 16 MHz für UART für ungünstig... zumindest wenn du 
Standard-Baudraten verwendest. 14,7456 MHz kann ich empfehlen, dann 
kannst du bessere Teiler verwenden.

Welche Kondensatoren hängen an den Quarzen?
Stabilisierst du die Spannung ausreichend um den Brown-out-Wert nicht zu 
unterschreiten?
Sind die Leiterbahnen korrodiert?
Kalte Lötstellen?
Zu viel Strom aus den I/Os bezogen?
Kaffee über die Platine gekippt?
Mega64 evtl. beim Einlöten verbrannt?
Spannungsspitze beim Einschalten?

Ich wette jeder hier im Forum kann endlos so weiter machen - zum Raten 
hat hier aber keiner Lust. Bitte ein paar Infos, ich wette, dann gibt's 
auch ein paar Antworten.

[Hans (Gast)]

Kai Giebeler wrote:
>Such dir aus, wo du den Fehler suchen willst:
>- Software: schick den Quelltext
hmm 2000 Zeilen halt ich jetz n bisschen viel für kurz mal drüberschauen
>- Hardware: schick den Schaltplan
>- AVR: setz nen frischen ein
such ich bei beidem den Fehler nicht

>ich halte übrigens 16 MHz für UART für ungünstig... zumindest wenn du
>Standard-Baudraten verwendest.
Das UART funktioniert problemlos, darum gehts auch garnicht.

>Welche Kondensatoren hängen an den Quarzen?
22pF
>Stabilisierst du die Spannung ausreichend um den Brown-out-Wert nicht zu
>unterschreiten?
Darum hab ich ja die BOD eingeschaltet. Sollte es einen BOR geben, 
erfahre ich es übers UART.
>Sind die Leiterbahnen korrodiert?
Ich hoffe nein, ist eine relativ frische Platine von PCB-Pool.
>Kalte Lötstellen?
Dann würden vermutlich ganz andere Fehler auftreten, nicht aber dass das 
Programm nach einer Weile erst rumspackt.
>Zu viel Strom aus den I/Os bezogen?
Siehe vorige Antwort
>Kaffee über die Platine gekippt?
Nein, auch nicht ähnliches
>Mega64 evtl. beim Einlöten verbrannt?
siehe >>"Kalte Lötstellen?"
>Spannungsspitze beim Einschalten?
Möglicherweise. Aber dürfte das nicht auch andere Resultate geben?

Ich versteh ja das Verlangen nach Details aber ich freu mich auch schon 
über allgemeine Hinweise, Erfahrungswerte sozusagen.

[Sven (Gast)]

> Ich versteh ja das Verlangen nach Details aber ich freu mich auch schon
> über allgemeine Hinweise, Erfahrungswerte sozusagen.

Ich würde daraus folgendes schliessen und vorschlagen:

1. Debugger an den Start
2. Genau kontrollieren ob Variablen überlaufen
   (zb: unsigned char o.ä.)

Wenn das noch nicht hilft:

EMV Problem:

1. dicke Batterie anklemmen zB. Bleiakku
2. möglichst alle Telefone und Handys weit weg
3. PC zur Kontrolle möglichst über OPTO-Koppler anschliessen
4. Netzleitungen weit weg
5. Leitungen nach aussen so kurz wie möglich
6. Schirmung durch Gehäuse

Und jetzt kann man auch daraus schliessen wie die Leser hier im 
Heuhaufen stochern, da einfach Details zu Anbindung; Kommunikation mit 
anderen Bausteinen; etc. fehlen.

Und dazu wäre ein Schaltplan ungemein hilfreich. (und oder Darstellung 
der Modulbauweise, etc.)

Gruß Sven

[Kai G. (runtimeterror)]

> Übers UART kommt kurz Schmarn
Da hatte ich einfach mal unterstellt, dass das nicht korrekt 
funktioniert...

Ich unterstelle dir jetzt mal, dass du die 2000 Zeilen nicht blind 
getippt und dann auf den Microcontroller losgelassen hast. Einfach mal 
den Code soweit zurückspulen, bis der Fehler wieder verschwindet.

Falls du doch alles auf einmal angeworfen hast: reduzier mal den Code 
auf das Problem. So lange auskommentieren, bis das Problem 
verschwindet...

[Hans (Gast)]

Kai Giebeler wrote:
>> Übers UART kommt kurz Schmarn
>Da hatte ich einfach mal unterstellt, dass das nicht korrekt
>funktioniert...
Naja bis der Schmarn kommt, is erstmal alles zu 100% korrekt.
Natürlich hast du Recht, das bedeutet nicht dass der Fehler in keinem 
Zusammenhang damit stehen kann.

>Ich unterstelle dir jetzt mal, dass du die 2000 Zeilen nicht blind
>getippt und dann auf den Microcontroller losgelassen hast.
Das ist richtig;)

>Einfach mal
>den Code soweit zurückspulen, bis der Fehler wieder verschwindet.
Die Idee hatte ich in jüngster Zeit auch und siehe ich konnte soweit 
reduzieren dass der Fehler tatsächlich...
NICHT VERSCHWINDET!
Immerhin brauch ich ja irgendwelche äußeren Anzeichen die mir das 
Auftreten des Fehlers nachweisen.
Also habe ich die UART Ausgabe als einziges Element im Programm 
gelassen.
Vielleicht ist der Fehler tatsächlich dort zu suchen.

int main(void)
{
  
  InitUART();

  SendStr("Start");

  if(MCUCSR & (1<<WDRF)) {MCUCSR &= ~(1<<WDRF); SendStr("__WDR__");}    //Watchdog Reset
  else if (MCUCSR & (1<<PORF)) {MCUCSR &= ~(1<<PORF); SendStr("__POR__");}  //Power On Reset
  else if (MCUCSR & (1<<BORF)) {MCUCSR &= ~(1<<BORF); SendStr("__BOR__");}  //Brown Out Detection Reset
  else if  (MCUCSR & (1<<EXTRF)) {MCUCSR &= ~(1<<EXTRF); SendStr("__EXTR__");}  //Extern Reset
  else if  (MCUCSR & (1<<JTRF)) {MCUCSR &= ~(1<<JTRF); SendStr("__JTAGR__");}  //JTAG Reset


  DDRC |= 1<<DDC0;
  PORTC |= 1<<PC0;

  
  while(1) {}

  return 0;
}

Die Initialisierung des UART:

void InitUART(void)
{
  unsigned char varTemp;
  UBRR0L = Low(F_CPU / (16UL*BAUD) - 1);
  UCSR0B |= (1<<RXEN0)|(1<<TXEN0);
  varTemp = UDR0;

}

//Char Ausgabe
void SendUART(unsigned char Data)
{
  loop_until_bit_is_set(UCSR0A,UDRE0);
  UDR0 = Data;
}

//String
void SendStr(char *str)
{  
  int i;
  for(i=0; i<strlen(str); i++) SendUART(*(str+i));
}

[Hans (Gast)]

Vielleicht hat Sven Recht und es gibt seltsame äußere Faktoren die man 
einkalkulieren muss.

[Kai G. (runtimeterror)]

Spontan fällt mir nichts auf...

Ok ich stocher einfach mal im Dunkeln:
- Auf was ist BAUD und F_CPU gesetzt?
- stimmt der für UBRR0L ausgerechnete Wert mit dem empfohlenen Wert im 
Datenblatt überein? (am besten mit dem Debugger prüfen)
- hast du mal eine deutlich langsamere BAUD-rate versucht?
- Bis wohin funktionieren die Ausgaben?
- Hast du mal geprüft, oder der wirklich auf 16 MHz läuft?
- Muss man in C den Stack initialisieren?
- Was macht loop_until_bit_is_set()? Bzw. wie macht es das?
- Funktioniert die Reset-Erkennung? Ggf. mal explizit Brown-Out, Power 
on, Extern überprüfen (die sind noch recht leicht herbeizuführen)

Ich empfehle immer auch den High-Wert zu setzen, wenn du den Low-Wert 
setzt, also:
UBRR0L = Low(F_CPU / (16UL*BAUD) - 1);
UBRR0H = High(F_CPU / (16UL*BAUD) - 1);
(Ich kann gerade nicht prüfen, ob das so stimmt, die Atmel Seite ist 
nicht verfügbar :( )
Je nach Baud-Rate fliegt dir das sonst um die Ohren - ist einfach 'ne 
gute Angewohnheit, auch wenn's um Konstanten geht ;) Wird aber an deinem 
Problem wahrscheinlich nichts ändern.

Einige Sachen könnt ich selbst noch nachschlagen, aber die Atmel-Seite 
ist down und ich habe vom Mega64 gerade kein Datenblatt da.

Vielleicht fällt mir noch was ein...

[Hans (Gast)]

>Ok ich stocher einfach mal im Dunkeln:
>- Auf was ist BAUD und F_CPU gesetzt?
F_CPU=16000000UL
BAUD=9600UL
>- Bis wohin funktionieren die Ausgaben?
Die funktionieren zunächst überall, aber irgendwann kackt das komplette 
Teil ab.
>- Hast du mal geprüft, oder der wirklich auf 16 MHz läuft?
Das wäre noch höchst interessant, tatsächlich isses so dass die 
"Timertimings" nie und nimmer stimmen können, aber das ist glaub ich 
wieder was anderes, mit dem Problem hab ich mich noch nicht ausführlich 
befasst; ein Indiz für 16MHz wäre jedoch, dass ich (fast) immer 
problemlos mit 4MHz, also mit 1/4 Systemspeed programmieren kann.
>- Muss man in C den Stack initialisieren?
Nein.
>- Was macht loop_until_bit_is_set()? Bzw. wie macht es das?
Ist beim Compiler dabei:

#define loop_until_bit_is_set(sfr, bit) do { } while (bit_is_clear(sfr, bit))

>- Funktioniert die Reset-Erkennung? Ggf. mal explizit Brown-Out, Power
>on, Extern überprüfen (die sind noch recht leicht herbeizuführen)
Ja, alles schonmal ausgegeben worden (außer JTAG Reset:))
>Ich empfehle immer auch den High-Wert zu setzen, wenn du den Low-Wert
>setzt, also:
>UBRR0L = Low(F_CPU / (16UL*BAUD) - 1);
>UBRR0H = High(F_CPU / (16UL*BAUD) - 1);
>(Ich kann gerade nicht prüfen, ob das so stimmt, die Atmel Seite ist
>nicht verfügbar :( )
>Je nach Baud-Rate fliegt dir das sonst um die Ohren - ist einfach 'ne
>gute Angewohnheit, auch wenn's um Konstanten geht ;) Wird aber an deinem
>Problem wahrscheinlich nichts ändern.
Es gibt beim 64er nur das low-Register, sonst bin ich sehr für gute 
Angewohnheiten;)

Und jetzt das beste: ich hab die Ausgaben komplett weggelassen und der 
Controller spackt nach einer Weile trotzdem rum!

[Condi (Gast)]

Da du das ja per Uart ausgibst, kommt immer der gleiche Müll?
Kommt der Müll immer nach der selben Zeit?
Zähl doch mal in der Whileschleife hoch und gib das Ergebnis aus.

[Hans (Gast)]

Nein es kommt weder der gleiche Müll noch zur gleichen Zeit mittlerweile 
bezweifle ich ja auch die Beteiligung des UART am Problem, da ich sogar 
schon das Übertragungsmodul komplett abgehängt hab und der uC immer noch 
Probleme macht.

[Sven (Gast)]

Kannst Du uns nicht mal eine Schaltplan zeigen ?
Wie ist die StromVersorgung aufgebaut bzw Spannungsversorgung ?

Gruß Sven

[Kai G. (runtimeterror)]

> Es gibt beim 64er nur das low-Register...
Ups... wie gesagt, hatte kein Datenblatt zur Hand :)

Was für Probleme macht der denn? Bzw. wie siehst du das überhaupt, wenn 
UART abgeschaltet ist?

Vielleicht mal das Parity-Bit und zwei stop-bits in der UART-Übertragung 
setzen um zu sehen, ob der die falschen Daten unwissend oder mit voller 
Überzeugung absetzt.

Wenn deine Rate nicht stimmt, ist's ein Wunder, dass du überhaupt was 
über's UART empfängst - ich würde das auf jeden Fall mal checken.

Wenn die Leitungen zum Quarz eine zu große Kapazität haben, kann das aus 
dem Takt kommen - passiert schonmal auf Breadboards, oder wenn die 
Zuleitungen zu lang sind, z.B. weil der µC auf eine Adapterkarte gelötet 
wurde.

Sind alle Ground-Leitungen mit Ground und alle Vcc-Leitungen auf Vcc 
aufgeschaltet?

Und ich wäre dir sehr verbunden, wenn du alle Fragen beantworten würdest 
und dir nicht nur die einfachen rauspickst, die man ohne Zutun 
beantworten kann, danke.

[Kai G. (runtimeterror)]

Hast du die globalen Interrupts eigentlich mal abgestellt, nachdem du 
die im Verdacht hattest?

[Hans (Gast)]

Kai Giebeler wrote:
>Was für Probleme macht der denn? Bzw. wie siehst du das überhaupt, wenn
>UART abgeschaltet ist?
Problem siehe Eröffnungsbeitrag von mir. Naja die gleichen Symptome vom 
UART abgesehen gibts auch ohne UART. Und auch NUR diese Symptome. Soll 
heißen es gibt nur eine Art von Absturz deshalb kann man davon ausgehen 
dass es auch nur ein Problem gibt. Dafür aber ein gravierendes.

>Vielleicht mal das Parity-Bit und zwei stop-bits in der UART-Übertragung
>setzen um zu sehen, ob der die falschen Daten unwissend oder mit voller
>Überzeugung absetzt.
Stimmt alles hundertprozentig von den Einstellungen her, da ja solang 
das Programm läuft auch das UART korrekt bedient wird.

>Wenn deine Rate nicht stimmt, ist's ein Wunder, dass du überhaupt was
>über's UART empfängst - ich würde das auf jeden Fall mal checken.
Siehe letzte Antwort.

>Wenn die Leitungen zum Quarz eine zu große Kapazität haben, kann das aus
>dem Takt kommen - passiert schonmal auf Breadboards, oder wenn die
>Zuleitungen zu lang sind, z.B. weil der µC auf eine Adapterkarte gelötet
>wurde.
Gehe ich nicht davon aus, die Leitungen (Out und In) gehen jeweils ca. 
2cm vom uC weg.

>Sind alle Ground-Leitungen mit Ground und alle Vcc-Leitungen auf Vcc
>aufgeschaltet?
Ja is in Eagle erstellt mit ERC und DRC.

>Und ich wäre dir sehr verbunden, wenn du alle Fragen beantworten würdest
>und dir nicht nur die einfachen rauspickst, die man ohne Zutun
>beantworten kann, danke.
Äääh welche hab ich denn bitte letztes Mal nicht beantwortet?

>Hast du die globalen Interrupts eigentlich mal abgestellt, nachdem du
>die im Verdacht hattest?
Ja. Keine Besserung.

[Hans (Gast)]

Achso, C15 und C17 sind 100nF, R11 und R13 270 Ohm, R12 und R14 Potis 
zum Einstellen der Betriebsspannung, C16 und C18 1uF Tantal und bei 
Letzterem bin ich mir sehr unsicher bzw. ob C15 und C17 für die 
Eingangsspannung reichen.
Bei älteren Schaltungen habe ich immer (größere) Elkos genommen, und 
zwar für die den Eingang. Vielleicht liegt da echt der Hund begraben. 
Aber bevor jetzt jemand fragt, NEIN es gibt keinen BOR. Trotzdem könnte 
das die Fehlerquelle sein... hmm...

[Kai G. (runtimeterror)]

>Äääh welche hab ich denn bitte letztes Mal nicht beantwortet?
Korrigier mich, wenn ich die Antworten überlesen haben sollte:
- stimmt der für UBRR0L ausgerechnete Wert mit dem empfohlenen Wert im
Datenblatt überein? (am besten mit dem Debugger prüfen)
- hast du mal eine deutlich langsamere BAUD-rate versucht?
- Bis wohin funktionieren die Ausgaben?

>>Was für Probleme macht der denn? Bzw. wie siehst du das überhaupt, wenn
>>UART abgeschaltet ist?
>Problem siehe Eröffnungsbeitrag von mir. Naja die gleichen Symptome vom
>UART abgesehen gibts auch ohne UART. Und auch NUR diese Symptome. Soll
>heißen es gibt nur eine Art von Absturz deshalb kann man davon ausgehen
>dass es auch nur ein Problem gibt. Dafür aber ein gravierendes.
Das von dir beschriebene Problem im Eröffnungsbeitrag lautet:
- Mein ATmega64 hängt sich ... auf komische Art und Weise auf.
- ATmega64 spinnt
Jetzt mal von dieser nutzlosen Information abgesehen - wie zum Geier 
bekommst du mit, dass der sich aufhängt bzw. spinnt??? Der 
InstructionPointer ist nicht sichtbar, JTAG ist aus, I/Os veränderst du 
keine und UART verwendest du ja in deinem letzten Test auch nicht!!

>>Vielleicht mal das Parity-Bit und zwei stop-bits in der UART-Übertragung
>>setzen um zu sehen, ob der die falschen Daten unwissend oder mit voller
>>Überzeugung absetzt.
>Stimmt alles hundertprozentig von den Einstellungen her, da ja solang
>das Programm läuft auch das UART korrekt bedient wird.
Weiß ich, aber stellt doch bitte mal die komplette Kommunikation auf 8 
bit, Parity, 2 Stop-bits um - auch beim Empfänger! und prüf mal, ob sich 
da was ändert.
Wenn dann trotz Parity immer noch so viel Müll heil am anderen Ende 
ankommt wird's wohl an der Software liegen, da der UART "bewusst" 
falsche Bytes absendet.
Wenn deutlich weniger Fehler ankommen (wg. ungültigem Parity), dann 
liegt's wohl eher an der Beschaltung, der AVR hat 'nen Schaden im UART 
oder die Rate stimmt aus irgendeinem Grund auf einmal nicht mehr.
Auf jeden Fall grenzt das den Fehler meiner Meinung nach deutlich ein

>>Wenn deine Rate nicht stimmt, ist's ein Wunder, dass du überhaupt was
>>über's UART empfängst - ich würde das auf jeden Fall mal checken.
>Siehe letzte Antwort.
Erst sagst du
>Das wäre noch höchst interessant, tatsächlich isses so dass die
>"Timertimings" nie und nimmer stimmen können, ...
und dann sagst du die müssen korrekt sein, wei UART zwischendurch geht.
Was für Timertimings überhaupt?
Ist dein UART-Empfänger eigentlich korrekt als Slave eingestellt oder 
auch als Master (oder ist dein Controller Slave und auf das externe 
Signal angewiesen?) Habe die Einstellungsmöglichkeiten derzeit nicht im 
Kopf. Wenn beide versuchen zu mastern geht das am Anfang ggf. gut, 
nachher laufen aber die Clocks auseinander - wegen Rundungsfehlern 
(16,000 MHz sind halt nicht sauber auf 9600 Baud zu verteilen) und 
allgemeiner Toleranzen. Bin zwar der Meinung, dass der Start dann 
regelmäßig auch daneben gehen müsste aber ich mach hier ja auch nur 
Fernwartung.

Was übrigens auch ein einfacher effektiver Test ist, ist permanent 
dasselbe Byte inner Schleife über UART rauszuschieben und das Ganze auf 
dem Oszi zu beobachten. Damit kann man gut sehen, ob sich das Signal 
verändert, ob das Format stimmt, ob die Rate gleich bleibt und stimmt 
(idealer Weise nicht triggern oder einen anderen Port zum Triggern 
verwenden).

Das bisschen Schaltung sieht für mich ok aus - denke mal die Spannungen 
hast du geprüft. C16 und C18 würde ich auf mindestens 10 µF setzen, da 
du aber im Moment keine wirklichen Lasten in der Schaltung zu haben 
scheinst, sollte 1 µF dicke reichen.

Die Beschaltung des UART wäre noch interessant.

AVCC ist auch angeklemmt? Wird nicht wichtig sein, ist aber empfohlen.

Wenn BOR das Problem ist, sollten die Fehler zumindest weniger werden 
wenn du das BOD-Limit runterdrehst. Tun sie das?

Bitte beim Testen den Programmer immer abziehen - wird öfters mal über 
Probleme berichtet... insbesondere bei Eigenbauten.

Hat der UART-Empfänger gemeinsame Masse mit deiner Schaltung?

So, gehe jetzt ins Bett...

[Sven (Gast)]

So, sehe jetzt Deine Spannungsversorgung und gehe davon aus das sie 
komplett ist:

1.

Wo ist der  oder die Abblockkondensatoren von 100nF Keramik !
für Deinen Controller oder andere Bausteine ?
Bedenke, für jeden Baustein ein eigener 100nF Keramik ! Kondensator.

Diese sind unbedingt nötig um den Controller dauerhaft zu betreiben.
Ebenso wäre es nützlich zu erfahren was für ein Steckernetzteil Du 
verwendest, dann solltest Du mal so > 500µF Elko hinter der Diode
zum Puffern anbringen.

2.

Die Bemerkung von Kai

> Bitte beim Testen den Programmer immer abziehen - wird öfters mal über
> Probleme berichtet... insbesondere bei Eigenbauten.

halte ich für sehr wichtig, da es oft vorkommt, das der Kontroller
in einem Reset gehalten wird, wenn man zb. ein Standard STK200 Dongle
verwendet und der PC abgeschaltet ist oder der LPT Port nicht gesteckt 
ist,
aber die Verbindung zum Controller besteht.
Bitte mal darauf achten..

Bitte mal zu 1. und 2. etwas schreiben. Danke.

Gruß Sven

[Hans (Gast)]

Kai Giebeler wrote:
>>Äääh welche hab ich denn bitte letztes Mal nicht beantwortet?
>Korrigier mich, wenn ich die Antworten überlesen haben sollte:
>- stimmt der für UBRR0L ausgerechnete Wert mit dem empfohlenen Wert im
>Datenblatt überein? (am besten mit dem Debugger prüfen)
Ja der errechnete Wert stimmt immer überein, es ist nur eine Frage des 
Systemtaktes, 16MHz lassen sich eben schwer aufteilen.
>- hast du mal eine deutlich langsamere BAUD-rate versucht?
Ja. 0 Baud ;)
>- Bis wohin funktionieren die Ausgaben?
Frage bitte präzisieren.

>Das von dir beschriebene Problem im Eröffnungsbeitrag lautet:
>- Mein ATmega64 hängt sich ... auf komische Art und Weise auf.
>- ATmega64 spinnt
>Jetzt mal von dieser nutzlosen Information abgesehen - wie zum Geier
>bekommst du mit, dass der sich aufhängt bzw. spinnt??? Der
>InstructionPointer ist nicht sichtbar, JTAG ist aus, I/Os veränderst du
>keine und UART verwendest du ja in deinem letzten Test auch nicht!!
Du hast drei Punkte gesetzt an einer wichtigen Stelle, scheinbar hast du 
diese überlesen, sie lautet:
"nachdem er eine Weile einwandfrei lief"
und mit einwandfrei meine ich einwandfrei. Ohne Fehler.
Ich würde auch gerne diese "Weile" genauer defninieren, aber da sie 
->zeitlich immer variiert ist mir das nicht möglich. Bitte erst lesen, 
nachdenken und dann erst beurteilen.
Ich hatte beim Schreiben dieses Beitrags gehofft jemand fühlt sich 
erinnert an eben GENAU dieses Problem, aber nun sind wir hier am raten. 
Und manche meinen auch (oder tun zumindest so) als würde ich sie 
verarschen wollen. Aber leider bin ich ja selber am raten. Nicht dass 
ich das Problem nicht eingegrenzt hätte, aber dass das Programm aufhört 
anständig zu sein ist immer der Fall. Auch ohne UART. Wie gesagt ich 
habs mal alles auskommentiert und sogar das Modul mit dem MAX232 
abgehängt. Das mag auch nach Stochern klingen, aber ich gehe zu 99.9 
Prozent davon aus (und wie sollte es auch anders sein, mal ehrlich), 
dass die Ursache des Programmabsturzes auch in diesem Fall die gleiche 
ist. Hier nochmal ein Zitat von mir:
"Und jetzt das beste: ich hab die Ausgaben komplett weggelassen und der
Controller spackt nach einer Weile trotzdem rum!"
Das war nachdem ich alles andere im Programm auch auskommentiert habe, 
sodass am Ende nur noch der mainloop blieb.

>Weiß ich, aber stellt doch bitte mal die komplette Kommunikation auf 8
>bit, Parity, 2 Stop-bits um - auch beim Empfänger! und prüf mal, ob sich
>da was ändert.
>Wenn dann trotz Parity immer noch so viel Müll heil am anderen Ende
>ankommt wird's wohl an der Software liegen, da der UART "bewusst"
>falsche Bytes absendet.
>Wenn deutlich weniger Fehler ankommen (wg. ungültigem Parity), dann
>liegt's wohl eher an der Beschaltung, der AVR hat 'nen Schaden im UART
>oder die Rate stimmt aus irgendeinem Grund auf einmal nicht mehr.
>Auf jeden Fall grenzt das den Fehler meiner Meinung nach deutlich ein
"Wenn deutlich weniger Fehler ankommen"
-> auch hier verweise ich nochmal auf das Zitat
"nachdem er eine Weile einwandfrei lief"
einwandfrei meint ohne Fehler, da gibts dann auch nicht "weniger" 
Fehler.
Die Fehler kommen erst irgendwann ganz plötzlich, dann aber digge und 
ohne sinnvolle Ausgaben zwischendrin.
Und nochmal ein Zitat:
"Übers UART kommt kurz Schmarn bis es durch
eine Ausgabe zeigt dass das Programm wieder von vorne beginnt"
Ok ich hatte vergessen hinzuzufügen, dass diese Ausgabe mit "Start" 
(Programmstart) korrekt ankommt und dass dies schleifenartig gesendet 
wird - also iterativer Programmstart - ohne Reset <-letzteres habe ich 
aber erwähnt. Ich hatte auch vergessen hinzuzufügen, dass dieser Ablauf 
nicht immer exakt der gleiche ist. Aber er ist einer von wenigen die auf 
das gleiche hindeuten. Ich finde in meinem Eröffnungsbeitrag ist 
genügend Präzision.


>...
>Erst sagst du
>>Das wäre noch höchst interessant, tatsächlich isses so dass die
>>"Timertimings" nie und nimmer stimmen können, ...
>und dann sagst du die müssen korrekt sein, wei UART zwischendurch geht.
>Was für Timertimings überhaupt?
>Ist dein UART-Empfänger eigentlich korrekt als Slave eingestellt oder
>auch als Master (oder ist dein Controller Slave und auf das externe
>Signal angewiesen?) Habe die Einstellungsmöglichkeiten derzeit nicht im
>Kopf. Wenn beide versuchen zu mastern geht das am Anfang ggf. gut,
>nachher laufen aber die Clocks auseinander - wegen Rundungsfehlern
>(16,000 MHz sind halt nicht sauber auf 9600 Baud zu verteilen) und
Jap leider.
>allgemeiner Toleranzen. Bin zwar der Meinung, dass der Start dann
>regelmäßig auch daneben gehen müsste aber ich mach hier ja auch nur
>Fernwartung.
Welcher Start? Der Übertragungsstart? Oder der Programmstart? Die Frage 
ist doch, stört ein fehlerhaftes UART das restliche Programm? oder suckt 
es nur in aller Ruhe vor sich hin?

>Was übrigens auch ein einfacher effektiver Test ist, ist permanent
>dasselbe Byte inner Schleife über UART rauszuschieben und das Ganze auf
>dem Oszi zu beobachten. Damit kann man gut sehen, ob sich das Signal
>verändert, ob das Format stimmt, ob die Rate gleich bleibt und stimmt
>(idealer Weise nicht triggern oder einen anderen Port zum Triggern
>verwenden).
Das wäre in der Tat mal eine interessante Sache.

Das bisschen Schaltung sieht für mich ok aus - denke mal die Spannungen
hast du geprüft. C16 und C18 würde ich auf mindestens 10 µF setzen, da
du aber im Moment keine wirklichen Lasten in der Schaltung zu haben
scheinst, sollte 1 µF dicke reichen.
Dachte ich mir auch. BORs gibts ja auch kaum, nur beim rumnoddeln am 
Kabel.

>Die Beschaltung des UART wäre noch interessant.
Normale Adapterschaltung kennst du? sonst RX TX VCC GND alles direkt.

>AVCC ist auch angeklemmt? Wird nicht wichtig sein, ist aber empfohlen.
Ist dran.

>Wenn BOR das Problem ist, sollten die Fehler zumindest weniger werden
>wenn du das BOD-Limit runterdrehst. Tun sie das?
Siehe vorvorletzte Antwort. Sicher kann man die wenigen manuell 
verursachten BORs vermeiden, das will ich aber auch gar nicht. Sonst 
treten vielleicht wieder unerwartete Phänomene auf.

>Bitte beim Testen den Programmer immer abziehen - wird öfters mal über
>Probleme berichtet... insbesondere bei Eigenbauten.
Ist in meinem Fall kein Problem. Beide Varianten laufen gleich gut und 
bei beiden Varianten tritt das gleiche Problem auf.

>Hat der UART-Empfänger gemeinsame Masse mit deiner Schaltung?
Ja


Sven wrote:
>1.

>Wo ist der  oder die Abblockkondensatoren von 100nF Keramik !
>für Deinen Controller oder andere Bausteine ?
>Bedenke, für jeden Baustein ein eigener 100nF Keramik ! Kondensator.
Sind genug dran. An jedem Versorgungseingang.
-> War ja auch nur die Spannungsversorgung, der Schaltplan.

>Diese sind unbedingt nötig um den Controller dauerhaft zu betreiben.
>Ebenso wäre es nützlich zu erfahren was für ein Steckernetzteil Du
>verwendest, dann solltest Du mal so > 500µF Elko hinter der Diode
>zum Puffern anbringen.
Das werde ich ausprobieren. Hat mir auch schon Sorgen gemacht.

"Bei älteren Schaltungen habe ich immer (größere) Elkos genommen, und
zwar für die den Eingang. Vielleicht liegt da echt der Hund begraben.
[...] könnte das die Fehlerquelle sein... hmm..."
->Ich werde mal einen dranhängen.

Zu deinem 2. Punkt:
Siehe vorletzte Antwort an Kai. Du hast Recht, wenn der PC aus ist, geht 
nix. Aber solange er läuft kann auch den uC laufen.

[Hans (Gast)]

Ich hab doch glatt vergessen etwas zu kommentieren:

>Erst sagst du
>>Das wäre noch höchst interessant, tatsächlich isses so dass die
>>"Timertimings" nie und nimmer stimmen können, ...
>und dann sagst du die müssen korrekt sein, wei UART zwischendurch geht.
>Was für Timertimings überhaupt?
Die errechneten Zeiten für den 8-Bit Timer stimmen nicht mit den 
tatsächlichen überein.
>Ist dein UART-Empfänger eigentlich korrekt als Slave eingestellt oder
>auch als Master (oder ist dein Controller Slave und auf das externe
>Signal angewiesen?)
Beim UART gibts weder Slave und Master noch einen externen Takt.

[Hans (Gast)]

22uF am Spannungseingang - keine Besserung.

[Tim (Gast)]

Nur mal so eine Idee...
Was mach dein Compiler eigentlich aus dem "while(1) {}"?
Wenn das wegoptimiert wird, läuft der permanent im kreis.
Ein "asm volatile ("nop");" in den {} sollte dann helfen.

[Hans (Gast)]

Ja sowas kann durchaus zum Verhängnis werden je nach Compiler. Ich glaub 
aber ich weis jetzt was das Problem war... aber mal sehen, nur die 
Praxis bestätigt die Theorie.

[Sven (Gast)]

Was denn ? Jetzt bin ich aber neugierig....

Ich war gerade schon auf dem Weg ein einfaches Programm für den
UART mit einfacher Ausgabe für den M64 zu compilieren,
welches bei mir ohne Probleme läuft.

Gruß Sven

[Simon K. (simon)]

Tim wrote:
> Nur mal so eine Idee...
> Was mach dein Compiler eigentlich aus dem "while(1) {}"?
> Wenn das wegoptimiert wird, läuft der permanent im kreis.
> Ein "asm volatile ("nop");" in den {} sollte dann helfen.

Ja, das ist mir auch anfangs durch den Kopf geschossen.

Das mit dem Watchdog ist eher unrealistisch, wenn man diesen nicht 
aktiviert hat. Der Watchdog ist standardmäßig nämlich ausgeschaltet und 
das steht auch so im Datenblatt.

PS: Sind Falks Beiträge gelöscht?

[Hans (Gast)]

@Sven
Die Doppelbelegung Programmierinterface und UART beim 64er.
Von Komplikationen steht aber nix im Datenblatt.

[Simon K. (simon)]

Hans wrote:
> @Sven
> Die Doppelbelegung Programmierinterface und UART beim 64er.
> Von Komplikationen steht aber nix im Datenblatt.

Hängt auch von deinem Programmiergerät ab.

[Kai G. (runtimeterror)]

>>- hast du mal eine deutlich langsamere BAUD-rate versucht?
>Ja. 0 Baud ;)
Meinst du nicht ernst, oder??

>>- Bis wohin funktionieren die Ausgaben?
>Frage bitte präzisieren.
Jo, mach ich: Du sagst, dass die Fehler erst nach einer Weile auftreten. 
Dein Testprogramm besteht aus gerade mal zwei UART-Ausgaben ("Start" und 
Reset-Grund) - danach kommt die Endlosschleife und es wird nichts mehr 
ausgegeben. Die paar ms in denen deine Ausgabe erfolgt würde ich nicht 
als "Weile" bezeichnen.

>Bitte erst lesen, nachdenken und dann erst beurteilen.
Das sagst du mir? da denn...

>Ich hatte beim Schreiben dieses Beitrags gehofft jemand fühlt sich
>erinnert an eben GENAU dieses Problem, aber nun sind wir hier am raten.
Ich hatte ziemlich genau dieses Problem, welches ich erfolgreich mit den 
von mir genannten Ansätzen gelöst habe. Was bleibt uns anderes übrig als 
zu raten, wenn wir dir jede Information aus der Nase ziehen müssen?
>Ich versteh ja das Verlangen nach Details aber ich freu mich auch schon
>über allgemeine Hinweise, Erfahrungswerte sozusagen.
Mein Erfahrungswert ist, dass sich Probleme mit deutlich weniger Aufwand 
und schneller lösen lassen, wenn man angemessene informationen bekommt.
...und allgemeine Hinweise hast du mittlerweile jede Menge bekommen.

Ich raff einfach nicht, wie man bei einem Programm, welches nach der 
Initialisierung in einer Enlosschleife rennt ohne einen Mucks von sich 
zu geben, feststellen kann, dass der Controller "spinnt".

Von den fehlerhaften Timing habe ich noch keinen Code gesehen, noch weiß 
ich, was "fehlerhaft" bei dir bedeutet... zu hoch, zu niedrig, 
schwankend, bei jedem Start was anderes?

@Tim und so
Was soll das NOP in der Schleife bringen? Wenn die Endlosschleife 
wegoptimiert werden würde wäre das ein semantischer Fehler im Compiler 
und man hätte es auch längst mit einem Debugger rausbekommen.

Ich klink mir hier mal aus... irgendwie reden wir voll aneinander 
vorbei. Ich warte jetzt einfach mal das Ergebnis ab... hoffe, du kriegst 
das hin.

[Hans (Gast)]

>>Ja. 0 Baud ;)
>Meinst du nicht ernst, oder??
Nein, nicht wirklich. Aber so ähnlich - nämlich ganz ohne Ausgaben.

>Jo, mach ich: Du sagst, dass die Fehler erst nach einer Weile auftreten.
>Dein Testprogramm besteht aus gerade mal zwei UART-Ausgaben ("Start" und
>Reset-Grund) - danach kommt die Endlosschleife und es wird nichts mehr
>ausgegeben. Die paar ms in denen deine Ausgabe erfolgt würde ich nicht
>als "Weile" bezeichnen.
Dann war das ein Missverständnis. Ich dachte es sei klar dass öfters was 
über die Leitung geht. Das habe ich vorausgesetzt, als ich sagte es 
kommt eine Weile alles korrekt an.

>>Bitte erst lesen, nachdenken und dann erst beurteilen.
>Das sagst du mir? da denn...
In diesem Thread bin's nicht ich der beurteilt.

>Was bleibt uns anderes übrig als
>zu raten, wenn wir dir jede Information aus der Nase ziehen müssen?
Ich kann ja nicht gleich alles herklatschen so nach dem Motto 
"bitteschön jetzt löst mir den Fehler". Ich grenze ja auch selber ein, 
bin ja aber auch auf nahezu alle Fragen eingegangen.

>Mein Erfahrungswert ist, dass sich Probleme mit deutlich weniger Aufwand
>und schneller lösen lassen, wenn man angemessene informationen bekommt.
>...und allgemeine Hinweise hast du mittlerweile jede Menge bekommen.
Natürlich, aber wie du wahrscheinlich nachvollziehen wirst - wie schon 
gesagt - grenzt man ein, wenn man schon einiges an Erfahrung angesammelt 
hat. Trotzdem ist noch die Hoffnung da, dass es jemand gibt, der 
schonmal irgendwann genau die selbe Erfahrung gemacht hat. War ja auch 
gut, dein Hinweis mit der Baudrate. Hab ich mir ehrlichgesagt zuvor noch 
nicht so wirklich den Kopf zerbrochen darüber. Mittlerweile ist aber 
auch höchstwahrscheinlich die Lösung des Problems da, was Dauerlauftests 
aber noch hoffentlich bestätigen werden.

>Ich raff einfach nicht, wie man bei einem Programm, welches nach der
>Initialisierung in einer Enlosschleife rennt ohne einen Mucks von sich
>zu geben, feststellen kann, dass der Controller "spinnt".
Es sind ja nicht nur die Ausgaben übers UART. Die 2000 Zeilen machen 
auch noch andere Dinge. Ich hab das jetzt einfach mal als Voraussetzung 
hingestellt. Der Rest funktionierte einfach nicht mehr. Und UART auch 
nicht, aber da wurde der Kontrast zum funktionierenden Programm 
deutlich.

>Von den fehlerhaften Timing habe ich noch keinen Code gesehen, noch weiß
>ich, was "fehlerhaft" bei dir bedeutet... zu hoch, zu niedrig,
>schwankend, bei jedem Start was anderes?
Die timings sind konstant, aber falsch. Da stimmt was mit dem Verhältnis 
Timertakt/Bezugszeit nicht. Werde ggf. neuen Thread eröffnen.

>@Tim und so
>Was soll das NOP in der Schleife bringen? Wenn die Endlosschleife
>wegoptimiert werden würde wäre das ein semantischer Fehler im Compiler
>und man hätte es auch längst mit einem Debugger rausbekommen.
Der Compiler optimiert tatsächlich manches unerwartet weg, je nach 
Optimierungsgrad. Ob man das als Fehler bezeichnen kann, sei 
dahingestellt.

Und jetzt zur Lösung:
Es hat tatsächlich etwas mit dem UART zutun gehabt. Ich hab nun mal die 
Initialisierung komplett weggelassen, jetzt läuft das Programm 
fehlerlos, mal abgesehen vom Timer. Die Programmierschnittstelle 
verträgt sich irgendwie mit dem UART nicht, davon steht aber nix im 
Datenblatt.
Ich hoffe nur dass weiterhin alles gutgeht.

[Simon K. (simon)]

Hans wrote:
> Die Programmierschnittstelle
> verträgt sich irgendwie mit dem UART nicht, davon steht aber nix im
> Datenblatt.

Das liegt daran, dass sich seit 19:51 nichts an der Tatsache geändert 
hat, dass es immernoch von deinem Programmiergerät abhängt.

Ein AVRISP-MKII beispielsweise schaltet die Programmierleitungen nach 
dem Programmieren hochohmig.

PS: Aber Hauptsache
> Bitte erst lesen, nachdenken und dann erst beurteilen.
Mein Held!

[Hans (Gast)]

>Ein AVRISP-MKII beispielsweise schaltet die Programmierleitungen nach
>dem Programmieren hochohmig.

Hauptsache ich habe kein AVRISP-MKII mein HELD! lol (für die 
Nicht-Mitdenker Ironieee)

[Hans (Gast)]

Achja wer hat eigentlich gesagt dass ich deinen Beitrag nicht mitgelesen 
hab. Die Lösung des Problems habe ich nochmal zusammengefasst für Leute 
die keinen Bock haben nochmal alles vorherige zu lesen, nicht für 
Nörgler.