Hallo zusammen, bei meiner selbst erstellten PCB kann ich den Atmega (168PA-AU) nicht mehr beschreiben, seit ich ihn auf den externen Quarz umgestellt habe. Auf einem zweiten Aufbau der PCB mit internem Quarz verhält sich der uC wir zu erwarten und lässt sich flashen. Anbei ein Ausschnitt der PCB. Als Quarz verwende ich den folgenden: https://lcsc.com/product-detail/Crystals_Yangxing-Tech-X5032110592MSB2GI_C112574.html In der "Description" sind 20pF genannt, ich nehme also an, dass die LC ist. Mit der Faustformel komme ich auf 20pF*2-5pF=35pF, also habe ich 33pF gewählt. Habt ihr eine Idee, wo das Problem liegen könnte? Als zweiten Anhang noch ein Screenshot von den Settings von MiniCore. In der IDE steht zwar "Clock -> External ...", aber in der Dokumentation (https://github.com/MCUdude/MiniCore#supported-clock-frequencies) ist von External crystal/oscillator die Rede. Oder kann es doch daran liegen? https://www.mikrocontroller.net/articles/Quarze_und_AVR#Einstellung_der_Fuses Den externen Quarz benötige ich, da die Schaltung UART nutzt. Ich freue mich über jede Antwort! Lasst mich wissen, falls weitere Informationen benötigt werden.
Angehängte Dateien:
Hallo, extern Clock ist nicht Crystal sondern ein extern angelegter Takz. Schau ins Datenblatt des Mega168PA, ich kenne die MiniCore-IDE nicht. Du wirst einen externen Takt anlegen müssen um die Fuses wieder zu korrigieren. Gruß aus Berlin Michael
Tilman schrieb: > bei meiner selbst erstellten PCB kann ich den Atmega (168PA-AU) nicht > mehr beschreiben, seit ich ihn auf den externen Quarz umgestellt habe D.h. der Quarz(oszillator) schwingt nicht. Kann an allem möglichen liegen. Am wahrscheinlichsten sind Kurzschlüsse (bzw. Lötstellen allgemein) oder ein defekter Quarz. Kann man mit den Oszi oder Logikprüfstift am Ausgang des Oszillators leicht verifizieren. > In der "Description" sind 20pF genannt ... also habe ich 33pF gewählt. Daran liegt es nicht. OK, es sei denn sie haben nicht 33pF. Wenn das aus Versehen 100nF sind, klappts natürlich nicht ...
Tilman schrieb: > Ich freue mich über jede Antwort! Da bin ich aber gespannt. Die sichere Methode ist aus meiner Sicht: Quarz und Kondensatoren ablöten, externen Takt von irgendwo (1MHz vom Oszi zur Tastkopfkalibration) holen und mit XTAL1 verbinden. Dann mit dem Flasher die Fuses überprüfen. 0000 in CLKSEL0-3 (also alle 4 programmiert!) heißt: "Externer Oszillator" und ist somit falsch. 0010 ist die Einstellung für den internen Oszillator 8Mz und die Einstellung 011 steht in meinem Datenblatt für den benötigten Full-Swing-Oscillator. Das ist hoffentlich richtig, aber ein wenig verdächtig, da es als einziger Wert nur 3stellig angegeben ist. Wenn aber schon 0011 in den Fuses steht, liegt es wohl an der Schwingbedingung für den Quarz, also Lötstellen und Kondensatoren überprüfen. Viel Glück!
Klaus S. schrieb: > Quarz und Kondensatoren ablöten Nicht notwendig. Einfach Takt anlegen. Gruß Jobst
Klaus S. schrieb: > Quarz und Kondensatoren ablöten, externen Takt von irgendwo (1MHz vom > Oszi zur Tastkopfkalibration) holen und mit XTAL1 verbinden. Wenn 1MHz eingespeist wird, dann muss man den 11MHz Quarz nicht auslöten, und die Kondensatoren auch nicht.
Jobst M. schrieb: > Klaus S. schrieb: >> Quarz und Kondensatoren ablöten > > Nicht notwendig. Einfach Takt anlegen. Wenn XTAL2 "aus Versehen" auf GND gelegt wurde, z.B. weil man sich mit dem Gehäuse des Quarzes einen Kurzschluß gebaut hat, dann klappt das nicht. Ist aber nur geraten, den der TO zeigt den Aufbau nicht. Michael U. schrieb: > extern Clock ist nicht Crystal sondern ein extern angelegter Takz Das ist die übliche Fehlinterpretation. Es wird nicht dazu gesagt, was denn nun "external" ist. Nur der Quarz oder auch der Oszillator? Abgesehen davon ist das anscheinend eine Arduino-IDE. AFAIK ist es bei Arduino gar nicht vorgesehen, den AVR mit einem externen Takt zu versorgen. Entweder interner RC-Oszillator oder interner Oszillator mit externem Quarz.
Axel S. schrieb: > Abgesehen davon ist das anscheinend eine Arduino-IDE. AFAIK ist es bei > Arduino gar nicht vorgesehen, den AVR mit einem externen Takt zu > versorgen. Entweder interner RC-Oszillator oder interner Oszillator mit > externem Quarz. Das ist eine Boarddefinition, welche der IDE hinzugefügt werden kann. Ist also nicht wirklich Arduino. Nur die IDE. In der Boarddefinition findet sich eine boards.txt Datei. Dort sind die verwendeten Fuses Varianten aufgeführt. Man kann also herausfinden, wie das gemeint ist. (wenn man will) Zudem zeigt es (AVRdude) die Fusess beim "Bootloader brennen" in den ausführlichen Meldungen.
Axel S. schrieb: >> Nicht notwendig. Einfach Takt anlegen. > > Wenn XTAL2 "aus Versehen" auf GND gelegt wurde, z.B. weil man sich mit > dem Gehäuse des Quarzes einen Kurzschluß gebaut hat, dann klappt das > nicht. Ist aber nur geraten, den der TO zeigt den Aufbau nicht. Wenn External Clock ausgewählt wurde, ist XTAL2 völlig irrelevant. Über weitere Fehler spekuliere ich erstmal nicht weiter. Axel S. schrieb: > Das ist die übliche Fehlinterpretation. Es wird nicht dazu gesagt, was > denn nun "external" ist. Nur der Quarz oder auch der Oszillator? Das steht ziemlich eindeutig im Datenblatt. Gruß Jobst
Jobst M. schrieb: > Axel S. schrieb: >> Das ist die übliche Fehlinterpretation. Es wird nicht dazu gesagt, was >> denn nun "external" ist. Nur der Quarz oder auch der Oszillator? > > Das steht ziemlich eindeutig im Datenblatt. Ja! Nur ist hier das Menu gemeint, was du wohl obersehen hast. Und da ist "External" halt eben ein "Full Swing Crystal" Hier der Nachweis: https://github.com/MCUdude/MiniCore/blob/master/avr/boards.txt#L364
EAF schrieb: > Nur ist hier das Menu gemeint, was du wohl obersehen hast. > Und da ist "External" halt eben ein "Full Swing Crystal" > > Hier der Nachweis: > https://github.com/MCUdude/MiniCore/blob/master/avr/boards.txt#L364 Das verstehe ich nicht. In der angegebenen boards.txt steht eindeutig: 168.menu.clock.11_0592MHz_external.bootloader.low_fuses=0b1111{...} In der Übersichtstabelle des Datenblatts für den ATmega18PB (die ich vorher nicht so schnell gefunden hatte) steht ebenso eindeutig für CKSEL3-0: Low Power Crystal Oscillator 1111 - 1000 Full Swing Crystal Oscillator 0111 - 0110 Internal 128kHz RC Oscillator 0011 Nach meinem Verständnis stellt damit MiniCore den LowPowerCrystalOscillator als Betriebsmodus für "External" ein. Und der ist nach meinem Halbwissen kritischer als der FullSwingOscillator in der externen Beschaltung, um sicher anzuschwingen. Damit ist auch klar, daß die von mir in meinem vorigen Posting schon als verdächtig eingestuften 011 im Datenblatt vermutlich falsch sind. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Datenblatts für den ATmega18PB Dreckfuhler Das benutzte Datenblatt 8271E–AVR–07/2012 ist für den ATmega168PA, also wohl das richtigerweise Zuständige.
Klaus S. schrieb: > Nach meinem Verständnis stellt damit MiniCore den > LowPowerCrystalOscillator als Betriebsmodus für "External" ein. Und der > ist nach meinem Halbwissen kritischer als der FullSwingOscillator in der > externen Beschaltung, um sicher anzuschwingen. Und der vom TE verwendete Quarz soll auch mit 100µW belastet werden, so wie die gängigen HC-49/S Quarze.
Klaus S. schrieb: > Das verstehe ich nicht. In der angegebenen boards.txt steht eindeutig: > > 168.menu.clock.11_0592MHz_external.bootloader.low_fuses=0b1111{...} > > In der Übersichtstabelle des Datenblatts für den ATmega18PB (die ich > vorher nicht so schnell gefunden hatte) steht ebenso eindeutig für > CKSEL3-0: https://www.engbedded.com/fusecalc/ Low Fuses 0xF7 Und du wirst sehen externe Crystal! Denn eine Programmierte Fuse ist 0 und eine unprogrammierte eine 1 So wie es für Flash Zellen eben üblich ist.
EAF schrieb: > https://www.engbedded.com/fusecalc/ > Low Fuses 0xF7 > > Und du wirst sehen externe Crystal! > Denn eine Programmierte Fuse ist 0 und eine unprogrammierte eine 1 > So wie es für Flash Zellen eben üblich ist. Das hat ja keiner bestritten. Die Behauptung, die mir unverständlich erschien, war, daß die Zeile: 168.menu.clock.11_0592MHz_external.bootloader.low_fuses=0b1111{...} in boards.txt einen FullSwingOscillator einstellen würde. Mein Denkfehler war, daß ich die 0b1111 für das LowNibble hielt und den Inhalt der geschweiften Klammer für einen Kommentar. Überraschung: Ist es nicht! Wir können also festhalten, daß für die Schaltung des TO im LowerFuseByte 0xF7 stehen sollte. Ob das so ist, kann nur der TO nachkontrollieren. Steht es so richtig drin, liegt der Fehler in der Oszillatorschaltung. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Wir können also festhalten, daß für die Schaltung des TO im > LowerFuseByte 0xF7 stehen sollte. Ob das so ist, kann nur der TO > nachkontrollieren. > Steht es so richtig drin, liegt der Fehler in der Oszillatorschaltung. So sieht es aus. Klaus S. schrieb: > Überraschung: Ist > es nicht! Ist es nicht!
Beitrag #7089181 wurde vom Autor gelöscht.
EAF schrieb: >> Das steht ziemlich eindeutig im Datenblatt. > > Ja! > Nur ist hier das Menu gemeint, was du wohl obersehen hast. > Und da ist "External" halt eben ein "Full Swing Crystal" > > Hier der Nachweis: > https://github.com/MCUdude/MiniCore/blob/master/avr/boards.txt#L364 Nein, das habe ich nicht übersehen, ging zu dem Zeitpunkt (bis eben noch) allerdings davon aus, dass das Menu korrekt ist. Gruß Jobst
Schön! Dann sind ja jetzt alle Klarheiten beseitigt.
Vielen Dank für die ganzen Antworten! Für die ausgewählte Variante werden folgende CKSEL Bits verwendet: https://github.com/MCUdude/MiniCore/blob/18d2ac780376a985c0f343cabe95aee4d27dc3d7/avr/boards.txt#L289 Da das für die lfuse 0xF7 ergeben sollte, habe ich mich bei einem zweiten Board noch einmal getraut und es mit den Einstellungen wie im Eingangspost geflashed und ... es hat funktioniert! > avrdude: 1 bytes of lfuse written > avrdude: verifying lfuse memory against 0b11110111: > avrdude: load data lfuse data from input file 0b11110111: > avrdude: input file 0b11110111 contains 1 bytes > avrdude: reading on-chip lfuse data: > > Reading | ################################################## | 100% 0.00s > > avrdude: verifying ... > avrdude: 1 bytes of lfuse verified Leider kann ich mit meinem ersten Board immer noch nicht reden. Ich habe auch schon versucht, mit einem anderen Arduino ein 1MHz Signal zu erzeugen und an XTAL1 zu hängen (und GND verbunden), leider erfolglos. Einen Oszi habe ich leider nicht. Lötstellen habe ich erneut durchgepiepst (ich habe nur den Atmega draufgelötet, den Quarz und die Kapazitäten hat jlcpcb draufgelötet, der Atmega wäre zu teuer gewesen). Da ich nur 4 der 5 gelieferten Boards brauche, gebe ich mich damit zufrieden und werde auf den (aktuell) teueren Atmega verzichten müssen. Vielen Dank nochmal! Hier bekommt man echt immer schnell kompetente Hilfe.
Tilman schrieb: > Einen Oszi habe ich leider nicht. Lötstellen habe ich erneut > durchgepiepst 1. Und mit der Lupe genau angesehen? 2. Welche Spannungen misst Du im eingeschalteten Zustand an XTAL1 und 2 gegen GND. (DC!) 3. Welche Widerstände misst Du im ausgeschalteten Zustand von XTAL1 und 2 gegen GND und zueinander? 4. Wo kommst Du her? Evtl. erklärt sich jemand in Deiner Nähe dazu bereit mal sein Scope dranzuhalten. Bzw. draufzuschauen. 5. Du kannst auch mal versuchen 1MΩ von XTAL1 zu XTAL2 zu ziehen. Das funktioniert normalerweise hier auch ohne, aber es ist ein Versuch wert. Gruß Jobst
Habe schon lange keinen Atmega retten müssen, aber die eingespeiste Taktfrequenz muss deutlich höher sein als der Takt des Programmer.
Anbei meine Zusammenfassung, was man zu diesem Thema wissen sollte: http://stefanfrings.de/avr_verfused/index.html
Als externe Taktquelle kann man auch einen weiteren AVR nehmen, z.B. ATtiny25. Man muß nichtmal ein Programm schreiben, nur die CKOUT-Fuse enablen. Je nach CKDIV8-Fuse kommen dann 8MHz oder 1MHz raus.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.