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
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.
Vielleicht doch noch was: Ich verwende den externen Interrupt INT2, könnte der Programcounter irgendwie vom Interrupt negativ beeinflusst werden?
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
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
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
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?
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 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.
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.?
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
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.
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.
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.
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.
> 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
> Ü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...
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.
1 | int main(void) |
2 | {
|
3 | |
4 | InitUART(); |
5 | |
6 | SendStr("Start"); |
7 | |
8 | if(MCUCSR & (1<<WDRF)) {MCUCSR &= ~(1<<WDRF); SendStr("__WDR__");} //Watchdog Reset |
9 | else if (MCUCSR & (1<<PORF)) {MCUCSR &= ~(1<<PORF); SendStr("__POR__");} //Power On Reset |
10 | else if (MCUCSR & (1<<BORF)) {MCUCSR &= ~(1<<BORF); SendStr("__BOR__");} //Brown Out Detection Reset |
11 | else if (MCUCSR & (1<<EXTRF)) {MCUCSR &= ~(1<<EXTRF); SendStr("__EXTR__");} //Extern Reset |
12 | else if (MCUCSR & (1<<JTRF)) {MCUCSR &= ~(1<<JTRF); SendStr("__JTAGR__");} //JTAG Reset |
13 | |
14 | |
15 | DDRC |= 1<<DDC0; |
16 | PORTC |= 1<<PC0; |
17 | |
18 | |
19 | while(1) {} |
20 | |
21 | return 0; |
22 | }
|
Die Initialisierung des UART:
1 | void InitUART(void) |
2 | {
|
3 | unsigned char varTemp; |
4 | UBRR0L = Low(F_CPU / (16UL*BAUD) - 1); |
5 | UCSR0B |= (1<<RXEN0)|(1<<TXEN0); |
6 | varTemp = UDR0; |
7 | |
8 | }
|
9 | |
10 | //Char Ausgabe
|
11 | void SendUART(unsigned char Data) |
12 | {
|
13 | loop_until_bit_is_set(UCSR0A,UDRE0); |
14 | UDR0 = Data; |
15 | }
|
16 | |
17 | //String
|
18 | void SendStr(char *str) |
19 | {
|
20 | int i; |
21 | for(i=0; i<strlen(str); i++) SendUART(*(str+i)); |
22 | }
|
Vielleicht hat Sven Recht und es gibt seltsame äußere Faktoren die man einkalkulieren muss.
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...
>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:
1 | #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!
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.
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.
Kannst Du uns nicht mal eine Schaltplan zeigen ? Wie ist die StromVersorgung aufgebaut bzw Spannungsversorgung ? Gruß Sven
> 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.
Hast du die globalen Interrupts eigentlich mal abgestellt, nachdem du die im Verdacht hattest?
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.
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...
>Äää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...
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
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.
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.
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 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.
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
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?
@Sven Die Doppelbelegung Programmierinterface und UART beim 64er. Von Komplikationen steht aber nix im Datenblatt.
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.
>>- 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.
>>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.
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!
>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)
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.