Hallo Zusammen, dammed... ich habe einen Atmega88 (SMD) in eine Schaltung eingelötet, aber ich Depp habe beim ersten proggen für die Fuses die Einstellung interner RC Oszi des ATmega8 genommen... und jetzt kommt beim Proggen immer "device missing or unknwon device"... HILFE... Ich benutze PonyProg, serielle Schnittstelle, Pollin Board (also Serial:SI Prog API in PonyProg) Wenn ich das jetzt richtig sehe sind die Fuses CkDiv8 = 1 CkOut = 1 Sut1:0 = 10 Cksel3:0 = 0100 Nach dem Datenblatt soll dass die Einstellung für den Uhrenquarz sein. Also habe ich einen Uhrenquarz eingelötet, aber PonyProg leifert beim Versuch die Fuses zu schreiben oder zu lesen den obigen Fehler. Jetzt habe ich mir gedacht dass vielleicht der Oszillator mit dem Uhrenquarz nicht richtig läuft oder es zum proggen eine schnellere Frequenz braucht. Verstehe das nicht genau, aber das Datenblatt könnte so gelesen werden dass man einfach nur an XTAL1 einen Takt anlegen muss, also habe ich an XTAL1 den Ausgang eines 1MHz-Quarzoszillators angelegt... liefert aber immer noch den Fehler... Also habe ich mit einen anderen Atmega8 einnen 30kHz Oszillator gebaut und dieses 0 bis 5V Signal an XTAl1 angelegt... liefert aber immer noch den Fehler... Was kann ich denn noch machen um den ATmega88 bzw das Projekt zu retten? An den anderen Fuses habe ich nicht gespielt. Schon mal Danke, Olli
> interner RC Oszi des ATmega8 Jup, damit sollte der Atmega ohne externen Quarz oder Oszillator prima laufen, würde 8MHz / 8 = 1 MHz machen... > Jetzt habe ich mir gedacht dass vielleicht der Oszillator mit dem > Uhrenquarz nicht richtig läuft oder es zum proggen eine schnellere > Frequenz braucht. Nö, würde es eher mal langsamer denn schneller probieren. > CkDiv8 = 1 > CkOut = 1 > Sut1:0 = 10 > Cksel3:0 = 0100 Ähm, hab dieses Setting noch nie probiert, aber hast du tatsächlich die CkDiv8 gesetzt? Das wären dann 32kHz/8 = 4kHz Takt...das ist arg langsam, vor allem da der Chip langsamer (glaub es war ein viertel des Main-Taktes) als sein Clock beschrieben werden möchte.
f_ISP < f_MPU/4 stell also deine isp frequenz mal so weit runter, wie du kannst. dass ponyprog die häkchen bei nicht programmierten fuses setzt, weißt du?
Ich hatte das Problem auch mal, mit nem ATtiny24 - auch SMD. Zum Glück hatte ich noch einen passenden Dremelaufsatz parat: eine Mini-Trennscheibe. Also das Teil auf nen Akkuschrauber montiert und dem Tiny die Beinchen amputiert. Anschließend könnte ich die verbleibenden Füßchen leicht einzeln herunterlöten. Bin mal gespannt, ob du den µC noch mit ISP zum Laufen bekommst. Meines Wissens geht das nur mit HV-Programmierung - aber andere kennen sich da besser aus.
Es gibt bei PonyProg eine spezielle Option, mit der man den ISP-Takt sehr weit heruntersetzen kann. Siehe auch hier: http://www.lancos.com/e2p/ponyprog2000.html#s2.6.2 Die VERYSLOW oder ULTRASLOW-Option ist dann wohl notwendig. Gestzt wird: SPIBusSpeed=NORMAL auf: SPIBusSpeed=VERYSLOW oder: SPIBusSpeed=ULTRASLOW in der ponyprog.ini. Wichtig ist nur, daß weder SPIEN (ISP-Freigabe) noch RSTDSBL (Reset-Pin gesperrt) verstellt wurden. In diesem Fall hilft nur noch ein HV-Parallelprogrammer, z.B. STK500 oder Hammers HV-Prog. Nochmal zur Erinnerung: Bei PonyProg IMMER vor dem Programmieren der Fuses diese mit Read einlesen!
Danke für die Hinweise, vorallem das mit der Option zur Verlangsammung bei PonyProg, kannte ich nicht. Ich hatte gestern dann noch mit avrdude rumgespielt, weil ich dort den -i Parameter für nen Delay gefunden hatte. Funktionierte aber auch nicht... ... und die Lösung war... den 1MHz Takt des ext Oszillators an den XTAL2 Pin !!!! Da ist doch glatt das Datenblatt falsch, da steht in Beiden (doc8161, doc2545) eigentlich eindeutig dass beim ser. proggen der Takt an XTAL1 = Pin 7 beim TQFP anliegen muss... ... mit dem ext. Takt an Pin 8 ging es jedenfalls sofort... manoman. Thx, Olli
Komisch, irgendwie lese ich "verfust" immer nur im Zusammenhang mit "PonyProg"... Wann erhält dieses Programm endlich mal eine vernünftige Bedienoberfläche?
OlliW schrieb: > Da ist doch glatt das Datenblatt falsch, da steht in Beiden > (doc8161, doc2545) eigentlich eindeutig dass beim ser. proggen der Takt > an XTAL1 = Pin 7 beim TQFP anliegen muss... Nein, das Datenblatt ist korrekt. XTAL1 ist schon richtig, wenn ein externer Takt oder Quarz/Resonator gewählt wurde. Anders ist es, wenn ein interner, zu niedriger Takt gewählt wurde, da geht es garnicht. Es ist nun aber so, daß CPU und XTAL2 parallel am Ausgangstreiber des internen RC-Oszillators hängen. Knallst du da einen einigermaßen kräftigen Oszillator dran, z.B. so eine TTL-Blechbüchse, dann kommt der interne Treiber nicht mehr dagegen an, der externe bestimmt, wo es langgeht. Da hier Ausgang auf Ausgang arbeitet, sollte man sowas nur im Notfall und kurzzeitig machen, damit nichts abraucht. Da man aber nicht sicher sein kann, daß die Innenschaltung so bleibt, sollte man sich nicht darauf verlassen, daß das auch in Zukunft oder bei anderen Typen so funktioniert. Besser ist es, zweimal zu prüfen, ob man die Häkchen auch wirklich richtig gesetzt hat.
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.