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?
> ... 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.
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.'
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.
