Hallo. Ich habe für den ATMEGA16 ein kleines Programm geschrieben das es mir ermöglichen soll 10 Ein- und 10 Ausgänge durch ein Byte das ich dem ATMEGA über die USART schicke zu setzten bzw auszulesen(Quelltext hängt an). Dabei passiert es in unregelmäßigen Abständen immer wieder das der ATMEAG16 einen RESET macht dessen Ursache ich nicht finden kann. Ich betreiben den ATMEAG mit einem 16MHz Quarz mit 22pF Cs und wie hier auf den Seiten beschrieben ist mit 100nF Cs an VCC und GND an allen Versorgungspins des ATMEAG. Zusätzlich hab ich einen 10k von VCC an den Reset PIN gehängt. Meine 5V VCC ist lt. Oszi stabil un glatt. Ein Byte wird von einem PC über die RS232 über einen MAX232 an die USART mit 115.2kb gesendet, der ATMEGA reagiert darauf und senden 2 byte als Antwort zurück, und das bis etwa 100 mal in der Sekunde. Kann mal bitte bitte bitte einer der Experten hier im Forum über meinen Quelltext schauen und mir Tips und Hinweise geben wie ich die Sache stabiler, besser machen könnte? Gibt es eine Möglichkeit den Zustand der Ports vor einem RESET zu sichern und diese nach dem RESET wieder herzustellen? Für Antworten und Hinweisse schon mal vielen Dank! MfG DG1LEO
Mal die Fuses kontrolliert, ob da vielleicht der Watchdog-timer eingeschaltet ist? /Ernst
Angehängte Dateien:
-
fusses.gif
11 KB
mhh - weiss nicht, fusses sind siehe Anhang gesetzt. merci für die super schnelle Antwort. Dg1LEO
Schau Dir nach dem Reset mal da Register MCUCSR an. Wenn Du nicht debuggen kannst, dann gib es über die RS232 aus oder leg den Wert auf einen unbenutzten, auf Output geschalteten Port. Viele Grüße, Stefan
Vielleicht noch mal kurz zur Erläuterung... Das ganze funktioniert eigentlich genau so wie ich mir das vorstelle, d.h. ich schick dem ATMEGA den Befehl, der setzt mir die Ausgänge, schickt mit in 2 bytes den status der eingänge zurück, und das ganze etwa 100 mal in der sekunde. Allerdings macht er nach etwa 10, 15 oder 20 sekunden einen reset, d.h. die leds an den ausgänge laufen durch -> meine initroutine, und dann macht er ganz normal weiter bis zum nächsten reset nach xx sekunden. :( Leo
10uF zwischen VCC und GND ist immer eine gute Idee (reimt sich sogar :)) Die fuses sind richtig würde ich sagen. Was genau schalten die ports?
Sind die LEDs denn direkt am AVR? Das würde natürlich nicht gehen. Also ich glaube mit einen 10uF c sollte das Problem gelöst sein, hatte ich auch schon mal...
100uF sind drann...
Ich glaub aber ich hab irgendein anderes problem. Ich hab meine
INTi_PORTS routine abgeänder in:
void INIT_PORTS(void) {
//Ausgänge setzen: PC0-PC7+PA6+PA7
DDRC = 0xff;
DDRD |= (1 << DDD6) | (1 << DDD7);
PORTC= MCUCSR;
/*
//alle Ausgänge auf low...
PORTC= 0x00; */
PORTD |= (1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD &= ~(1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD |= (1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD &= ~(1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD |= (1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD &= ~(1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD |= (1 << PD6) | (1 << PD7);
_delay_ms(1000);
PORTD &= ~(1 << PD6) | (1 << PD7);
//Eingänge setzen
DDRB = 0x00;
DDRD &= ~(1 << DDD2) | (1 << DDD3);
//no pull-ups...
PORTB = 0x00;
PORTD &= ~(1 << PD2) | (1 << PD3);
//AD-Port als eingänge...
DDRA = 0x00;
}
.. um zu sehen wie das MCUCSR nach dem reset aussieht - hier sind immer
PC0 und PC1 high, alle anderen low. ABER...
Nachdem die routine durch ist leuchtet nur PD7, PD6 ist aus und die
beiden ldes blinken auch nicht, was sie doch aber tun müssten - das
versteh ich nun wieder überhaupt nicht, da stimmt doch was nicht...
Die leds an PORTC und PORTD sind über 330Ohm auf masse.
thx für eure antworten
mixblick Leo
Wiso rätselt ihr noch rum, ich habe es doch schon geschrieben woran es liegt: CKOPT Fuse setzen !
CKOPT schaltet den Oszillator bei Verwendung eines Quarzes vom Stromsparmodus auf volle Amplitude. Ab etwa 8MHz aufwärts soll CKOPT gesetzt werden. Tut man es nicht, interpretiert der AVR manche Takte anscheinend doppelt und läuft so ab und zu mal mit doppelter Frequenz. Das ist natürlich viel zu schnell -> AVR hängt sich auf. Das ist zumindest meine Interpretation des Verhaltens. Was man merkt: Der AVR hängt sich ohne Grund auf, und zwar meist an bestimmten stellen: Bei meinem Spektrumanalyser war es ab einer bestimmten Lautstärke, bei meinem Displaycontroller immer dann wenn ein bestimmtes Bitmuster geschrieben wurde.
Das mit der CKOPT werd ich gleich mal probieren. Irgendwie steh ich mit den fusses auf kriegsfuss. Nach dem ATMEGA16 Datenblatt ist ckopt für: "For resonators, the maximum frequenzy is 8Mhz with CKOPT unprogrammed and 16MHz with CKOPT programmed" - sollte dann doch heissen "kein hacken" bei CKOP und ich kann das 16MHz quarz richtig nutzen... Genau so bei der JTAGEN fusse - JTAG Enabled -> kein Hacken==programmiert==JTAG Enabled, ABER nur wenn dort kein Hacken drinn ist kann ich PC3, PC4, PC5, PC6 usw. setzten, also JTAG aus, wenn ich nen hacken setzte dann kann ich die pins nicht setzten - müsste meiner menung nach genau anders herum sein - muss ich aber wohl nicht verstehen. Bei mir scheint auch die funktion _delay_ms(); aus der neuen util/delay.h nicht richtig zu funktionieren. Wenn ich _delay_ms(1000) (sollte doch 1 sekunde sein) aufrufe werden da max. ein paar mikrosekunden verzögert... merkwürdig. MfG und noch nen schönen Abend DG1LEO
Der läuft und läuft und läuft - zumindest seit 5 min ohne reset - ich bin hin und weg und völlig begeister. Vielen Dank an alle die sich so rege mit meinem Problem auseinandergesetzt haben. (+big thx to benedikt!!) Vielleicht sollte man wirklich mal ein richtiges tutorial für die fusses schreiben, oder gibts sowas schon? DG1LEO
Mario schrieb ... Genau so bei der JTAGEN fusse - JTAG Enabled -> kein Hacken==programmiert==JTAG Enabled, ABER nur wenn dort kein Hacken drinn ist kann ich PC3, PC4, PC5, PC6 usw. setzten, also JTAG aus, wenn ich nen hacken setzte dann kann ich die pins nicht setzten - müsste meiner menung nach genau anders herum sein - muss ich aber wohl nicht verstehen. ... ein gesetzter Haken bedeutet programmiert, Bit = 0 nicht gesetzter Haken bedeutet nicht programmiert, Bit = 1 Ist also schon alles so wie es sein soll. Volker
Es gibt für beide Arten der Häckchen einen Sinn: Für Häckchen = 1: bit gesetzt Für Häckchen = 0: Fuse programmiert. Daher steht in einem ordentlichen Programm auch dabei ob ein Häckchen jetzt sich auf eine programmierte Fuse oder auf ein gesetzes Bit bezieht. Am besten ist es aber so wie im AVR Studio: Man wählt z.B. "externern Quarz>1MHz, BOD aus" aus, und das Programm stellt die Fuse Bits automatisch ein.
Ich wundere mich die ganze Zeit schon - noch kein Frühling, und alle sind schon im Garten am Hacken... @Benedikt: Interessanter Tipp mit der CKOPT-Fuse... Ich hatte zwar (3x auf Holz klopf) noch nie derartige Probleme, aber nun hat man schonmal einen Ansatz, wenn sich etwas seltsam verhält. Also, fröhliches Hacken und nicht vergessen, die Haken richtig zu setzen ;)
Danke. Ich hab das wohl wirklich einfach falsch asoziiert - hatte bisher immer gedacht bit gesetzt= fuse programmiert - nun gut, jetzt hab ichs glaub ich begriffen :). Noch mal zu der Frage ob man die den Status von pPrts vor einem rRset sichern kann und diesen nach dem Reset wieder herstellen kann. Ich kann nicht den Status jeweils in das EEProm schreiben weil es erstens zu lange dauern würde und zweitens ich zu viele werte ständig sichern müsste und wohl auch in absehbarer Zeit die max 100.000 Schreib/Lesezyklen des EEProm erreichen würde. Was bbleibt nach einem Reset alles erhalten und gibt es sowas wie einen Reset-Interrupt? schönes we @ all. MfG Leo
...und noch mal zu der CKOPT-Fuse - der Tip war echt klasse - der ATMEAGA macht wohl keine RESETS mehr - ist aber schon sehr gemein die Fuse, so läuft alles normal bis der ATMEGA aus unerfindlichen Gründen einen RESET macht - böse böse... Ich glaub ich geh mal nen Kaffee trinken, irgendetwas stimmt mit meinen Fingern oder meiner Tastatur nicht (Böse Buchstabendreher ;( ) Leo
Thread beobachten
Seitenaufteilung abschalten
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.