Hallo zusammen, ich habe heute versucht meinen Atmega32 auf eine externe Taktquelle einzustellen. 16 MHz Quarz + Kondensatoren angeschlossen und in AVRProg von Int RC 67ms + 6 CK auf Ext Xtal 67ms + 16K CK gestellt. Ich hatte vorher ein Programm geflasht, dass einen Port binär hochzählt. Resultat: - uC nicht mehr ansprechbar. - uC läuft noch da Kontrollprogramm läuft. - Das vorhandene Programm läuft gefühlt um den Faktor 30 langsamer (100ms pro Schritt zu 3s). Es sollte meiner Kenntnisse nach um den Faktor 16 schneller laufen da von 1MHz auf 16Mhz umgestellt wurde. Ich bin ein wenig überfragt, was da los ist. Was kann da schief gegangen sein und wie komme ich wieder auf den internen Takt?
ich schrieb: > uC nicht mehr ansprechbar Takt vom Programmer stark verringern, dann die Fuses auslesen und kontrollieren bzw. hier posten.
> ... Faktor 30 langsamer ...
Merkwürdig.
Könnte es sein, dass auf 'External RC Oscillator' gestellt wurde? In
diesem Fall sollte ein Widerstand zwischen Vcc und XTAL1 helfen,
vielleicht so etwa 10 kOhm.
wenn sonst alles stimmt -mal mit CKOPT spielen -sicher, dass es die passenden Kondensatoren sind?
Hallo, hast du auch im Fuses den Teiler zurückgesetzt ? Im Auslieferungszustand ist Teiler meist Enable. Mit freundlichen Grüßen
Kondensatoren sind 2x 22pF. Mir ist unklar, wie ich beim AVRProg den Takt senke. Es gibt keine Option dafür.
Verfused und zugenäht... Mit großer Sicherheit sind die Fuses falsch eingestellt, wie man AVR mit externem Quarz betreibt steht hier: https://www.mikrocontroller.net/articles/Quarze_und_AVR Mögliche falsche Fuseeinstellungen -------------------------------------------- Fuses sind auf externen RC - Oszillator eingestellt: - Verbindung +Vcc - 10 kOhm nach XTAL1 und von XTAL1 22pF nach GND Fuses auf externen Taktgeber (external Oszillator): - eine Taktquelle 2 MHz an XTAL1 anschließen Schaltung mit CMOS Baustein und Quarz gibt es viele im Netz, Beispielsweise die hier http://www.ferromel.de/tronic_26f.htm (zufällig ausgewählt aber in dieser Art funktioniert das relativ zuverlässig). danach (wie Vorredner geschrieben) beim Versuch auf den AVR zuzugreifen den ISP Takt des Programmers verlangsamen. Solltest du die Fuses so eingestellt haben, dass du SPI disabled hast, hilft dir nur noch ein HV-Parallelprogrammer.
ich schrieb: > Mir ist unklar, wie ich beim AVRProg den > Takt senke. Es gibt keine Option dafür. Wenn du mit avrdude flasht ist das die Option -B. -B 20 sollte reichen um bei sehr langsam eingestellten Fuses den Zugang zu ermöglichen
> Solltest du die Fuses so eingestellt haben, dass du SPI disabled hast ...
'Notes: 1. The SPIEN Fuse is not accessible in SPI Serial Programming
mode.'
Angehängte Dateien:
-
Fuse1.png
45 KB -
FuseAVRProg.png
14 KB
So, ich habe jetzt versucht den uC mit einem externen Takt zu versorgen. Dabei habe ich festgestellt, dass der uC ohne externen Taktgeber läuft. Egal, ich habe es geschafft die Fuses auszulesen. Siehe Bilder, die Bytes sind L: 0xFA H: 5C (AVRDude) Wie ich feststellen konnte, ist die Interpretation in den Programmen unterschiedlich. Laut AVRProg ist alles so, wie ich es eingestellt habe. Damit scheint das Programm Käse zu sein.
ich schrieb: > So, ich habe jetzt versucht den uC mit einem externen Takt zu versorgen. > Dabei habe ich festgestellt, dass der uC ohne externen Taktgeber läuft. Ja, nur halt offensichtlich nicht richtig. Sprich: zieh' das mit dem externen Taktgeber bis zum Ende durch! > Egal, ich habe es geschafft die Fuses auszulesen. Siehe Bilder, die > Bytes sind L: 0xFA H: 5C (AVRDude) > Wie ich feststellen konnte, ist die Interpretation in den Programmen > unterschiedlich. Es wird wohl eher das Problem sein, dass unterschiedliche Werte gelesen werden. Wenn der Takt scheisse ist, kann alles passieren. Dass tatsächlich korrekte Werte gelesen werden, ist dann eher Zufall. Man kann das relativ gut abschätzen, indem man immer wieder die Signatur einliest. Wenn da in 100 Versuchen auch nur ein Fehlversuch dabei ist, kannst du alles andere knicken, du kannst es dann nur noch schlimmer machen, wenn du versuchst, die Fuses erneut zu beschreiben. Also nochmal: Zieh' das mit dem externen Taktgeber bis zum Ende durch! Oder tausche auf Verdacht die Bürdekondensatoren. Am wahrscheinlichsten ist, dass die parasitäre Lastkapazität schon zu hoch ist (Versuchsaufbau auf Breadboard o.ä.), also Bürdekondensatoren tendenziell eher mal verkleinern, z.B. 2x15pF oder 2x12pF. Nur wenn das nichts bringt, und/oder es sich nicht um einen Versuchsaufbau handelt, sondern um ein regelgerecht designtes PCB, dann besteht eine gewisse (allerdings recht kleine) Wahrscheinlichkeit, dass ein Versuch in die andere Richtung (z.B. 27pF, 33pF oder 39pF) etwas bringt. Es gibt tatsächlich Quarze, die sowas brauchen, nur sind sie eben vergleichsweise selten in freier Wildbahn anzutreffen.
c-hater schrieb: > ... Was ist denn mit dir los? Wo ist dein verachtender Unterton geblieben? Nicht dass mich das Fehlen jetzt stört.. Ganz im Gegenteil! Also: Weiter so!
ich schrieb: > So, ich habe jetzt versucht den uC mit einem externen Takt zu > versorgen. > Dabei habe ich festgestellt, dass der uC ohne externen Taktgeber läuft. > Egal, ich habe es geschafft die Fuses auszulesen. Siehe Bilder, die > Bytes sind L: 0xFA H: 5C (AVRDude) > Wie ich feststellen konnte, ist die Interpretation in den Programmen > unterschiedlich. Laut AVRProg ist alles so, wie ich es eingestellt habe. > Damit scheint das Programm Käse zu sein. Du solltest für 16MHz-Quarz noch CKOPT programmieren (also auf 0 setzen), damit der Oszillator bei der Frequenz stabil laufen kann. Und aufpassen mit den Begriffen: Du willst keinen externen Takt, sondern einen externen Quarz! Wenn du ein Oszi oder einen Frequenzzähler hast, schau dir mal das Signal an XTAL1 und XTAL2 an, ob das 16MHz hat und halbwegs sinusförmig ist... Faktor 30 langsamer als 1MHz klingt nach einem 32768Hz-Uhrenquarz. Aber den hast du ja sicherlich nicht dran... wäre ein seltsamer Programmierfehler denkbar, der durch Neuprogrammierung der Bootloader-Fuses das Timing-Verhalten beeinflusst? Stell doch mal testhalber die Clock Options wieder auf internen RC-Oszillator zurück und schau, ob das Timing wieder stimmt (ohne die Boot-Fuses zu ändern). Außerdem als generelle Anmerkung: OCDEN und JTAGEN können dazwischenfunken. Wenn ich die nicht brauche, deaktiviere ich sie generell. MfG, Arno
Dann schreibe ich doch noch eine Zusammenfassung. Aufgabe: Atmega 32 von internen Oszillator auf externen Quarz umstellen. Problem: uC ist nach dem Umstellen sehr langsam/zeigt seltsames Verhalten. Ursache: Zum Umstellen der Fuses wurde AVRProg verwendet. Das Programm scheint die Auswahl im Drop-Down-Menü nicht in den korrekten Bytes für die Fuses umzurechnen. Siehe Bilder, die von mir hochgeladen wurden. Dieses Phänomen bestätigt sich, nachdem die Fuses über AVRDude umgestellt wurden. Eingestellt wurde: Ext. Crys. HF Start up 16K CK + 64ms (und ja, genau das kann auch wieder ausgelesen werden) AVRProg liefert: Ext Xtal Startup 30us + 1K CK (und ja, das Auslesen lässt sich 100x wiederholen) uC läuft jetzt auf 16Mhz, alles i.O. Quintessenz: Für den Atmega 32 ist AVRProg zum Setzen der Fuses nicht geeignet.
Hallo ich schrieb: > AVRProg Warum sollte man auch ein Programm verwenden, dass seit 5 Jahren nicht mehr gepflegt wird? https://sourceforge.net/projects/avrprog/ Wir haben ja den Standard: Avrdude
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.