Hallo, ich habe einem Kollegen ein Board mit einem ATmega128 (TQFP64) gebaut. Lief für ein paar Wochen alles wunderbar. Nun hat er "ein wenig damit rumgespielt" und ihr könnt euch denken was das heißt... ich habe das Ding wieder auf meinem Tisch liegen :( Wenn ich im AVR Studio auf connect gehe und mir den Fuses Reiter anschaue, kommt eine Fehlermeldung und bei allen Fuses sind die Häckchen raus. Programmiert hat er über SPI. Ich habe keine Ahnung wie er das geschafft hat, aber ich brauche nun eine Lösung und zwar möglichst ohne den Chip auszulöten (Gefahr für die Lötpads, dass die abreißen), denn das Board war teuer. Ich habe mir also den parallelen Programmiermodus zu Gemüte geführt und versucht, ihn mit einem GALEP-III anzusprechen. Dazu habe ich an den Chip 18 Kabel angelötet. PB0 - PB7 => Data PD1 - PD7 => für RDY/!BSY, !OE, !WR, BS1, XA0, XA1, PAGEL !RESET PA0 => BS2 XTAL1 VCC und GND sind ja noch auf dem Board vorhanden. Da ich keinen passenden Sockel habe, habe ich die angelöteten Kabel einfach in die Klemmkontakte des GALEP eingeklemmt und habe nun versucht, mit dem Chip zu kommunizieren. Als Referenzbelegung (alo wie ich die Belegung des 128 auf den 40 pol DIL Sockel übertragen kann) habe ich den ATmega 644 genommen. Dessen parallel Programmierpins sind von der Belegung gleich wie die des ATmega128. Nun kommt aber bei jedem Kommunikationsversuch mit dem 128, dass er eine falsche Bauteilkennung hat. Ich habe sowohl den 128, als auch den 644 in der Bauteilliste ausgesucht... ohne Erfolg. Hat jemand einen hilfreichen Hinweis, ob ich mit meinem Aufbau vielleicht komplett auf dem Holzweg bin, oder wie ich die Bauteilkennung ignorieren und ein lesen/schreiben erzwingen kann? VIELEN DANK !!!
Hi Versuch doch erstmal an XTAL1 einen Takt zu legen. Evtl. kannst du ihn dann ansprechen. Wenn GALEP das Teil nicht unterstützt, stehen die Chancen eher schlecht. MfG Spess
Über SPI kann man den Controller nicht komplett abschießen, ich würde auch erstmal einen Takt >1Mhz an XTAL1 anlegen und versuchen, den Stein über SPI anzusprechen.
Hallo Andreas, hole Dir die neueste Version der Galep32-Software für den Galep III bei http://www.conitec.de oder http://www.conitec.net. Die kann den ATMEGA128, schau in der Device-List nach..... In der Hilfe zum Programm findet sich sicher auch eine Liste wie der TQFP64 auf den 40-poligen Socken umzusetzen ist. Auf der Web-Seite von Conitec (Hersteller vom Galep III) gibt es auch eine Telefonnummer (keine 0900-Abzocke!!!) unter der man die sehr kompetente und freundliche Hotline erreichen kann. Bisher, bin selber sehr zufriedener Besitzer eines Galep III, wurde mir dort stets weitergeholfen. Viel Erfolg! Miraculix
Ich vermute, der Galep ist hier unnötig.
Hallo, ihr meint also, über SPI kann man die ganze Sache nicht so programmieren, dass man sich selber aussperrt? Von Anfang an war ein externer Takt von 10MHz programmiert und der Quarz hat auch ordnungsgemäß geschwungen... was er jetzt aber nicht mehr macht. Entweder er sollte jetzt wieder mit internem Takt arbeiten oder mit dem angeschlossenen Quarz.... aber er rührt sich nicht. Er synchronisiert sich mit dem mkII von ATMEL... grünes Licht, also irgendwie muss er schon noch da sein... ich weiß es nicht. Die neuste GALEP32 Software habe ich auch und der 128er im TQFP64 Gehäuse wird auch unterstützt. Ich habe jetzt gefunden, wie ich die Bauteilkennung deaktivieren kann. Lesen klappt fehlerfrei. Nur werden alle Fusebits als aktiv gemeldet (siehe Bild). Nur programmieren funktioniert noch nicht. Wenn ich erst lese und dann direkt ohne Änderungen programmiere, meldet er OK. Aber er wird sicher nur den Inhalt überprüfen und nix programmieren. Setze ich einen Hacken unter den Config Bits, schlägt das schreiben fehl. Ich versuche mal, einen Funktionsgenerator aufzutreiben... wird sicher schwer. Oder wie wäre es am einfachsten, ohne weiteren uC, einen Takt an XTAL1 zu legen? Vielen Dank für die zahlreichen Hinweise!
>Von Anfang an war ein externer Takt von 10MHz programmiert und der Quarz >hat auch ordnungsgemäß geschwungen... Das sind zwei Paar Schuhe! Externer Takt heißt, daß ein externes Taktsignal anliegt, externer Quarz arbeitet mit einem eigebauten Oszillator, der den Quarz schwingen läßt. Wenn jetzt also auf externen Takt gefused ist, erwartet der Controller eine Schwingung an XTAL1 und der Quarz ist abgeschaltet. >Oder wie wäre es am einfachsten, ohne weiteren uC, einen Takt an >XTAL1 zu legen? Genau so. Nimm einen Büchsenoszillator zwischen 1 und 16MHz oder einen NE555, der im genannten Frequenzbereich schwingt und lege das Ausgangssignal an XTAL1, der Quarz kann derweil dran bleiben. Fuse dann wieder auf Quarz um und entferne die Taktquelle wieder.
Das mit dem Takt an XTAL1 funktioniert auch, wenn SPIEN deaktiviert ist?
Hi
>Das mit dem Takt an XTAL1 funktioniert auch, wenn SPIEN deaktiviert ist?
Kann man mit SPI nicht abschalten.
MfG Spess
> Von Anfang an war ein externer Takt von 10MHz programmiert und der Quarz hat auch ordnungsgemäß geschwungen... was er jetzt aber nicht mehr macht. Könnte drauf hindeuten, dass CKOPT nicht gesetzt wurde. Dann laufen die Dinger mit 10MHz nur, wenn sie wollen. Als erstes sollte man IMMER die Signatur lesen. Wenn die nicht kommt, sondern nur FF, dann ist der AVR nicht ansprechbar. Externen Takt (keinen Quarz, sondern einen Takt!) anlegen und nochmal versuchen. > Ich habe jetzt gefunden, wie ich die Bauteilkennung deaktivieren kann. Wozu? > Lesen klappt fehlerfrei. Nur werden alle Fusebits als aktiv gemeldet (siehe Bild). Also er liest immer FF? Siehe oben...
Die Signatur konnte ich fehlerfrei via SPI lesen und meine Testprogramme liefen auch fehlerfrei mit 10MHz. Die Bauteilkennung hatte ich nur deaktiviert, weil sie mir zu Beginn Probleme gemacht hat. Aber das funktioniert jetzt auch fehlerfrei mit der parallelen MEthode. Ich schaue mal, ob ich einen Oszillator finde... Mit dem galep32 Tool kann ich nur ein paar Fuses setzen. Wenn ich die WDTON Fuse aktiviere, ist auch automatisch die BOOTRST gesetzt. Aber SPIEN und JTAGEN kann ich nicht setzen. Ich schreibe die Werte rein (via GALEP3) und nach dem lesen sind die dann wieder deaktiviert. Lesen des Chips, löschen und Leertest gehen ohne Fehler. Nur beim Programmieren der Fuses gibt es immer einen Fehler nach dem Überprüfen der Fuses. Ich habe schon mit Conitec telefoniert, die schauen ob es vielleicht ein Fehler bei der Implementierung des ATmega128 gibt. Die melden sich heute im Laufe des Tages nochmal. Ich versuche derweil nochmal die Sache mit dem externen Takt... irgendwoher werde ich schon einen auftreiben/erzeugen können. MfG Andreas
Angehängte Dateien:
-
Unbenannt.png
8,3 KB
Ich habe jetzt einen Taktgenerator aufgetrieben. Ich habe an XTAL1 ein 1MHz, Uss=5V Rechtecksignal mit 2,5V Offset angelegt. Aber es rührt sich immer noch nichts. Immer wieder die gleiche Fehlermeldung (im Anhang) :( An der Schaltung und dem Stecker habe ich nichts verändert... also Hardwaretechnisch ist alles roger... denn es hat ja mal tadellos funktioniert. Habt ihr vielleicht noch andere Ideen? Ich hoffe ja noch auf den Anruf der Firma Conitec, dass ihr Programm einen Fehler hat, dass ich dann zumindest im Parallelmodus die Fuses anders setzen kann. Aber wenn ihr sagt, dass man per ISP nichts einstellen kann, dass man sich aussperrt von dem 128er... was zum Teufel hat dann mein Kollege gemacht? Er selber weiß auch nicht, was genau vorgefallen ist. Ich kann also nicht mal beschreiben, was zu diesem Verhalten geführt hat. Er hatte auch nur einen SPI Programmer... also mit mehr konnte er gar nicht kommunizieren... Ich hoffe mir oder einem von euch kommt noch die rettende Idee. Ich würde nur sehr sehr sehr ungern den ATmega mit einem Heißluftfön auslöten müssen! VIELEN DANK!
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.