-         

Ergebnis 1 bis 4 von 4

Thema: ATmega168 "zerflasht"

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672

    ATmega168 "zerflasht"

    Anzeige

    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:

    Klicke auf die Grafik für eine größere Ansicht

Name:	STK.jpg
Hits:	15
Größe:	92,5 KB
ID:	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

  2. #2
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.186
    Laut meiner Beschreibung gehört >PROG DATA mit PortB und PROG CONTROL mit PortD verbunden.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672
    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

  4. #4
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.186
    Zitat Zitat von Bumbum Beitrag anzeigen
    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.
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

Ähnliche Themen

  1. Antworten: 10
    Letzter Beitrag: 01.11.2017, 13:53
  2. [ERLEDIGT] Problem: Erste "Inbetriebnahme" eines Atmega168
    Von schorsch_76 im Forum AVR Hardwarethemen
    Antworten: 2
    Letzter Beitrag: 21.04.2012, 17:13
  3. Antworten: 2
    Letzter Beitrag: 15.06.2011, 22:18
  4. LPC1114 (Cortex M0): "sei()" und "cli()"
    Von Jaecko im Forum ARM - 32-bit-Mikrocontroller-Architektur
    Antworten: 1
    Letzter Beitrag: 02.07.2010, 13:25
  5. ASM: was machen "swap" und "cbr" genau?
    Von RHS im Forum AVR Hardwarethemen
    Antworten: 3
    Letzter Beitrag: 18.08.2004, 18:16

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •