Atmega644: Fusebits verstellt, wie reaktivieren?

Hallo zusammen,

jetzt ist mir auch das passiert, was jedem, der einen AVR einsetzt, sicher passieren wird: hab die Fuse-Bits eingestellt, dabei leider verstellt und jetzt reagiert der AVR nicht mehr unter avrdude.
Eigentlich wollte ich den Takt auf einen 20MHz-Quarz einstellen und hab dabei leider auf 0.4 - 0.9 MHz eingestellt (Fragt bitte nicht nach, wie das passiert ist :( )
Wie bekomm ich den jetzt wieder zum Laufen? Da Quarze in diesem Bereich leider so gut wie nicht zu finden sind, wird wohl ein RC-Bandpass einzusetzen sein. Oder ist es möglich, bei dieser Einstellung auch einen externen Taktgeber anzuschliessen?

Danke für eure Antworten,

Markus

Ein externer Takt an XTAL1 funktioniert eigentlich fast immer...

Eine Gängige sorte Resonatoren sind auch 455 kHz Keramikresonstoren. Die Frequenzen wird man auch nicht so ernst nehmen müßen, ein 1 MHz Quarz oder Resonator sollte auch noch gehen. Der externe Takt ist aber das sicherste und funktioniert bei eigentlich jeder einstellung der Fuses.

Hallo markus,

Zitat:

---

Zitat von cipher

... jetzt ist mir auch das passiert, was jedem, der einen AVR einsetzt, sicher passieren wird ...

---

Also das ist mir noch nie passiert - aber es ist ja eine interessante Frage. Also habe ich meine Experimentierplatine mit dem m168/20MHz genommen und die fuses so gesetzt wie Du. Überraschung (für mich) - nun lief wirklich nix mehr. Also (m)einen 36kHz-Takt aus einer bestehenden Schaltung (das ist eine IR-LED für einen SFH5110) auf XTAL1 gelegt. PonyProg tat noch immer nix - es erkannte einfach den Controller garnicht. Aber mein STK500-Clon wurde auf Programmierfrequenz 1 kHz gesetzt - und nun konnte ich die fuses wieder zurücksetzen. Danach Quarz einsetzen - und alles ist beim Alten - sprich: der m168 läuft wie eh und je (jedenfalls die 1-sec-LED blinkt wie immer). Vielleicht hilft Dir das?

Danke für eure Antworten. Hab's gestern abend noch mit einem Quarzoszillator versucht. Den einzigen, den ich zu Hause rum liegen hatte, war ein 12MHz und mit dem tat sich leider nichts. Ich werd's dann heute noch mal mit ner niedrigeren Frequenz ausprobieren. Gut zu wissen, dass es mit einem externen Taktgeber gehen müsste.

Viele Grüße,

Markus

Hi zusammen,

ich hab geschafft! Scheinbar waren die 12MHz zu viel, mit 480 kHz gings. Weil ich leider keinen entsprechenden Taktgeber hatte, musste ein Mega8 herhalten ;)

Danke nochmals für eure Antworten

Ich habe ein ähnliches Problem mit einem Mega32: Ich habe ihn mit dem bei AVR Studio enthaltenen AVR Prog (benutze als Programmer mySmartUSB) auf die Einstellung "Ext. XTAL, Startup 4,2ms + 1k CK" eingestellt, um einen externen Quarz (mit 3,6864MHz) zu betreiben worauf der µC nicht mehr reagierte (auf diese Weise habe ich schon 2 Mega32 dazu gebracht nicht mehr zu reagieren). Das erstaunliche ist aber, dass AVR Prog bei einem neuen Mega32 als Einstellung "Ext Clock, Startup 30µs + 6CK" anzeigt, der µC aber mit einem internen Takt von ungefähr 1MHz arbeitet. Der Programmer AVR-OSP II zeigt mir bei den Fuses aber keine Einstellung, die die Taktquelle betrifft als gesetzt an, also ist bei meinem µC noch gar kein Fuse-Bit gesetzt?! Oder schreibt bzw. liest AVR Prog die Fuses falsch? Auf welche Einstellung sollte ich den µC mit AVR-OSP setzen, um den Quarz zu aktivieren?

mfg _R2D2

AVRprog scheint nen Bug bei den Fuses für den M32 zu haben, da zeigt er bei mir auch was falsches an. Stell mal auf M16 um, die sind ja bis auf die Speichergröße baugleich. Damit klappt es bei mir.

Es ist auch bei einem commerziellen ISP Interface möglich das falsche Fuse werte Ausgelesen werden. Kann z.B. passieren wenn die Kabel zu lang sind oder die Zielschaltung so schlecht ist das es viele Störungen gibt.
Dann solle man aber auch beim Auslesen des Flasch in der Regel keine reproduzierbaren Ergebnisse bekommen.


Für die Fuse einstellungen kann man z,B. hier nachsehen:

http://www.engbedded.com/cgi-bin/fc.cgi

der 3,5 MHzs Quarz sollte als low oder med Freq durchgehen.

Also die low fuss zum Beispiel als 0xD9 oder 0xED. Welche der Startup Zeiten man wählt ist weniger wichtig. Im Zweifelsfall lieber etwas länger.