www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega128 zurücksetzen via GALEP III


Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !!!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: Miraculix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute, der Galep ist hier unnötig.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Takt an XTAL1 funktioniert auch, wenn SPIEN deaktiviert ist?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das mit dem Takt an XTAL1 funktioniert auch, wenn SPIEN deaktiviert ist?

Kann man mit SPI nicht abschalten.

MfG Spess

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas B. (loopy83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es noch weitere Ideen?
DANKE

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.