ATmega168 "zerflasht"

Hallo,

ich habe eine Schaltung mit einem ATmega168, bei der am ISP auch noch andere IC's hängen, die via ISP und je einer CS Leitung mit dem ATmega kommunizieren. Bei der Entwicklung der Software für die Schaltung habe ich mittlerweile den zweiten ATmega "produziert", der nicht mehr programmierbar ist. Ich flasche mit einem STK im System. Ich habe auf meiner Platine eine 10-polge Flachbandbuchse, die mit dem STK ISP10Pin verbunden ist. Mir ist bewußt, dass es zu Problemen kommen kann, wenn ich in einem ungünstigen Moment flashe und eine CS-Leitung eines anderen "ISP-Bus-Teilnehmers" noch aktiv ist.

Der ATmega ist nach so einem mißglücktem Flash-Versuch auch nicht mehr direkt auf dem STK zu flashen. Ich stecke ihn in die grüne Buchse, und verbinde ein 6 poliges Flachband-Kabel mit der grünen Stiftleiste und dem ISP6Pin-Verbinder. Alle anderen Verbindungen sind getrennt. Aber auch in diesem Zustand lassen sich nicht mal mehr die Signature Bytes auslesen.

Hat jemand einen Tipp für micht, wie ich den µC noch mal zur Kommunikation bewegen kann? In seinen Fuses ist ursprünglich externen Takt >8 MHz eingestellt. Ich habe also auch schon versucht einen 16MHz Quarz auf das STK zu stecken und den ATmega damit zu betreiben, leider ohne Erfolg.
Die ISP-Geschwindigkeit im AVR-Studio habe ich selbstverständlich auch schon in allen Möglichenkeiten durchprobiert.

Viele Grüße
Andreas

- - - Aktualisiert - - -

Hallo,

noch ein Eintrag. Ich habe mich gerade an die High-Voltage Parallel-Programmierung erinnert. Diese hat mir noch nie geholfen, deshalb habe ich da nicht gleich dran gedacht. Aber im aktuellen Fall scheint der Atmel zumindest wieder ein bisschen zu kommunizieren. Ich habe mit Hilfe von Google folgende konfiguration und Verkabelung hergestellt:

Anhang 27951

Das Flachbandkabel, das oben das Bild verlässt ist eine Verbindung von PROG CTRL und PA. Das AVR-Studio habe ich auf PP/HVSP mode umgestellt. Die Signature-Bytes kann ich nun wieder auslesen. Die sind aber 0xFE 0xFE 0xFE. Da scheint also noch was nicht zu passen. Hat noch jemand einen Tipp?

Viele Grüße
Andreas

Laut meiner Beschreibung gehört >PROG DATA mit PortB und PROG CONTROL mit PortD verbunden.

Hallo Hubert,

danke für deinen Hinweis. Der Controller ist gerettet. Die Ursache war, dass die RSTDISBL Fuse gesetzt war. Vermutlich durch das flashen in einem ungünstigem Zeitpunkt, als noch Kommunikation auf dem Bus lief. Ich werde deshalb jetzt in meiner Prototyp-Schaltung, in der ich die Software entwickle ein paar Maßnahmen weitere ergreifen, dass alle SPI Busteilnehmer auf Reset sind, solange die AVR-Leitung auch auf Reset liegt. Die Reset-Leitungen der Bus-Teilnehmer werden eigentlich vom AVR gesteuert, da ich diese im Betrieb neu umkonfigurieren und somit resetten muss.

In meiner Anleitung zum STK500 ist der ATmega168 noch nicht aufgelistet. Deshalb habe ich via Google versucht die passende Beschaltung herauszufinden. Da hat wohl jemand Mist veröffentlicht.

Viele Grüße
Andreas

Zitat:

---

Zitat von Bumbum

In meiner Anleitung zum STK500 ist der ATmega168 noch nicht aufgelistet. Deshalb habe ich via Google versucht die passende Beschaltung herauszufinden. Da hat wohl jemand Mist veröffentlicht.

---

Ich schau immer nach zu welchem angeführten Kontroller der verwendete Pin-kompatibel ist. Das hat bisher immer funktioniert.