Hallo ! Ich habe ein Problem beim Takten eines Atmega16 auf 16MHz. Ich habe einen externen 16MHz Quarz an die Xtal-Pins gelegt, mit den 2 22pF Kondensatoren gegen Masse... wie es halt üblich ist. Meine Ponyprog-Einstellungen seht ihr auf dem Bild im Anhang. Das merkwürdige an der Sache ist nun, dass ich den AVR mit 16MHz Quarz nicht mehr programmieren kann, sondern nur wenn ich einen 3,6864MHz Quarz verwende. Wenn ich nach dem Programmieren wieder den 16MHz Quarz einsetze, läuft der AVR mit dem neuen Programm problemlos. Sind meine Konfigurationsbits falsch? Vielen Dank ! MfG
Hi Bei 16MHz muß der Oszillator mit der kompletten Amplitude schwingen. -> CKOPT=0 (also mit Häckchen) und es sollte funktionieren. BTW: Du solltest dir die aktuelle Version von PonyProg besorgen. Matthias
Hallo ! Das habe ich auch schon probiert. Das Ergebnis ist genau das gleiche. Was ich noch vergessen habe zu erwähnen: Die Konfigurationsbits kann ich nur mit dem langsamen Quarz lesen und schreiben. Mit dem 16MHz Quarz liesst er grundsätzlich die Bits falsch, oder manchmal kommt nur eine Fehlermeldung. Trotzdem vielen Dank für die Antwort. MfG
Hallo! Mit was programmierst du? Mit einem selbstgebauten Parallelportprogrammer? Ich glaub ich hab irgendwo gelesen, dass wenn man über den Parallelport programmiert, man dann den AVR nur mit 4 MHz betreiben darf, da es sonst nicht funktioniert. Ich weiss leider nicht mehr warum genau. Danach kann man ihn natürlich auch mit 16 MHz betreiben. mfg Fasti
dass wenn man über den Parallelport programmiert, man dann den AVR nur mit 4 MHz betreiben darf, da es sonst nicht funktioniert. Das ist ein Märchen !
Ich verwende einen seriellen ISP. Weiss nicht ob es da Limitationen gibt. Vielleicht ist die Baudrate für den ISP bei einem 16MHz Quarz etwas instabil... Ich habe mich damit noch nicht so sehr beschäftigt, daher ist das nur eine Vermutung.
Hi der AVR muß mit einer Mindestfrequenz getacktet werden um programmiert werden zu können. Eine Maximalfrequenz gibt es nicht. CKOPT muß auf jeden Fall programmed sein sonst gehts nicht (steht im Datenblatt Seite 24) SUT sollte so passen. Evtl. mal noch den BOD aktivieren. Matthias
@Michael, "Das ist ein Märchen !" nur weil es bei Dir nicht auftritt, muß es noch lange kein Märchen sein. Wenn er es gelesen hat, sollte ja auch was dran sein. Z.B. wird der SPI-Takt mit dem Quarztakt abgetastet. Daher kann es durchaus so sein, daß bei höherer Frequenz das Signal zu langsame Flanken hat bzw. Störungen oder Reflexionen auf der Leitung zu Fehltaktungen führen. @MyCo, ich würde Dir raten, einen Bootloader reinzubrennen. Über die UART ist das Programmieren nicht nur wesentlich sicherer, sondern auch erheblich schneller (2,8s bei 115200Baud). Peter
Hallo ! Ich habe zwei 16MHz Quarze zum testen. Es müsste schon wirklich arg zugehen, das beide dein gleichen Fehler erleiden :-) Die Quarze gehen, denn nach dem Programmieren kann ich einen 16MHz Quarz einsetzen, und das Programm läuft auf anhieb richtig, mit vollen 16MHz. Und das sogar mit CKOPT unprogrammiert. Ich weiss da echt nicht weiter, das ist ein sehr "mysteriöser" Fehler...
Hallo ! @Peter: Mit dieser Technik habe ich mich noch nicht befasst. Aber dass hört sich nach einem grossen Aufwand an, weil ich ja immerhin die Schaltung komplett neu aufbauen muss. Im Moment ist es ja nur so, dass ich mit einem langsameren Quarz programmieren muss, und später kann ich den schnelleren draufsetzen.
Märchen bleiben Märchen, auch wenn sie immer wieder erzählt werden. Der Hinweis von Matthias ist hingegen sehr wichtig und richtig. Das subtile an der Geschichte ist, daß der Controller durchaus funktionieren kann, wenn das Bit nicht aktiv ist. Aber ab und zu kann es zu unerklärlichen Fehlfunktionen kommen, die kaum zu ergründen sind, außer man setzt dieses Bit und hat dann Ruhe.
Hallo MyCo, wie lang ist das Kabel vom Programmer zum ATmega? Eventuell das Kabel so kurz wie möglich machen. Gruß, Arno
Hi! Das Kabel ist etwa 1 Meter...bisher lief damit eigentlich alles problemlos. Auch mit dem schnellerem Quarz müsste die Übertragungsrate zwischen PC und Atmega die gleiche sein. Daher glaub ich nicht, dass das Kabel daran schuld ist.
Nicht das Kabel unterschätzen, den Fehler machte ich auch! Habe einen STK200/300 kompatiblen Programmer am LPT hängen. Jaja, ich weiß ;) Das (Flachband)Kabel vom Adapter zum Board ist ca. 1m lang. Funktionierte mit 90S8515, 90S1200, 90S4434 und anderen bei jeweils verschiedenen Taktraten einwandfrei. Dann kam der Tiny26, hat sich nicht programmieren lassen, und beim lesen der Fusebits kamm immer was anderes raus. Einmal wurden sogar die LOCK Bits gesetzt, so das ich erst einen Parallel Programmer bauen musste um den Chip überhaupt seriell bearbeiten zu können. War kurz davor das Teil in den Müll zu befördern und einen neuen zu kaufen. Dann kam ich auf die Kabel Idee ;) An 0,75m geschirmtes Kabel passende Stecker gelötet, und siehe da es klappte auf anhieb! Einen Versuch isses Wert, kost ja fast nix. Gruß, Maddin
Hallo, Schade, war nur so eine Idee, hätte ja sein können. Dann bleibt ja nur noch was Matthias schreibt, das CKOPT Bit setzen. Gruß, Arno
Hallo Leute, Ich habe wieder das selbe Problem, nur diesmal in einer neuen Schaltung. Gibt es vielleicht mittlerweile eine Lösung? In der Ponyprog-Hilfe steht, dass man Einstellungen in der INI Datei vornehmen soll, falls diese Fehlermeldung auftritt. Da habe ich auch einiges probiert...umsonst. MfG
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.