ATMega8 "verfused" Kann man den noch retten

Guten Morgen,

ich glaube ich habe einen ATMega8 "kauptt" programmiert. Ich benutzte zum programmieren das STK500. Ich habe einen Quarz in den Sockel des STK eingesetzt und den OSCEL-Jumper auf 2-3 gesetzt. Dann habe ich die Fuses des Atmega auf einen externen Quarz (Medium Frequency) umgestellt. Alles hat funktioniert. Die Geschwindigkeit hat gepasst, da eine RS232-Kommunikation einwandfrei funktioniert hat.

Dann wollte ich Port B an die LEDs des STK anschließen und habe deshalb den kompletten Port B als Ausgang konfiguriert:

Code:

---

DDRB = 0b11111111;
PORTB = 0b00000000;

---

Nach dem flashen dieses Programmteils konnte ich nicht mehr mit meinem STK500 kommunizieren.Ich bekomme immer eine Fehlermeldung, dass das STK500 nicht angeschlossen ist. Wenn ich den Mega8 aus der Fassung ziehe geht es. Ebeneso wenn ich den OSCEL Jumper ziehe. (Die Kommunikation mit dem STK geht dann, programmieren nicht)

Ein Blick ins Datenblatt des Mega8 hat dann auch ergeben warum: PB6 und PB7 werden als XTAL-Pins verwendet. Mist!

Die RS232-Kommunikation läuft jetzt auch nicht mehr sauber.

Ich vermute das Problem ist, dass die XTAL-Pins durch den Atmel auf 0V gezogen werden und somit der Takt des Atmels und des STK aus dem Ruder gebracht wird.

Also habe ich den XTAL-Jumper vom STK noch gezogen und OSCEL wieder auf 2-3 gesteckt, damit der Atmel vom Quarz läuft und das STK vom Takt abgetrennt ist. So ist die Kommunikation mit dem STK wieder gelaufen. Ich habe den ISP-Takt auf 1,2kHz gesetzt und die Fuses des Mega8 wieder auf den Internen RC-Oscillator setzen können. Nur leider blockiert er immer noch mein STK. Sobald der Mega8 steckt kann das AVR-Studio nicht mehr mit dem STK kommunizieren, egal wie ich die Jumper XTAL und OSCEL setze, oder sogar ganz weg lasse.

Aus Verzweiflung habe ich die zwei Pins PB6 und PB7 (XTAL1 und XTAL2) des Mega8 hochgebogen, aber trotzdem blockiert er das STK.

Hat noch jemand eine Idee?

Viele Grüße
Andreas

Zitat:

---

... ATMega8 "kauptt" programmiert ... (XTAL1 und XTAL2) des Mega8 hochgebogen ...

---

Klingt nicht gut. Für eher einfache Fuseprobleme - umgestellt auf externen Takt und keinen Quarz oder Takt zur Hand - habe ich nen Fuseretter (klick). So wie Deine Beschreibung klingt, fürchte ich aber, dass das auch nix hilft.

Zitat:

---

Zitat von Bumbum

Aus Verzweiflung habe ich die zwei Pins PB6 und PB7 (XTAL1 und XTAL2) des Mega8 hochgebogen, aber trotzdem blockiert er das STK.

---

Aber will man einen Controller mit hin-und-hergebogenen Beinchen wirklich noch retten?

Also wenn du STK500 hast, dann verwende doch den HV-Programmier-Modus. Da sind doch nur ein paar zusätzliche Kabel zum stecken.

Hallo,

ich habe den Fehler gefunden: Ich habe mal die Versorgungsspannung überprüft und festegestellt, dass diese von eingestellten 5V am STK auf über 6V steigt, sobald der Atmel8 steckt. Erklären kann ich mir das nicht. Ich habe deshalb den ADC im Verdacht, da ich diesen gleichzeitig mit der Port B Änderung geflasht habe. Also habe ich die PB6 und PB7 Beinchen wieder runtergebogen und die ARef und AVCC Pins dafür hochgebogen und nun läuft wieder alles. Die ARef Ausgabe vom STK habe ich überprüft: 0V. Wenn ich an den hochgebogenen Pins vom Atmel messe, messe ich 2,56V am Ref-Pin und 5V am AVCC Pin. Wo kommen denn die >6V her??

Hier mal mein Code, der dafür verantwortlich sein könnte:

Code:

---

ADMUX = (1<<REFS1) |(1<<REFS0);
 ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);

---

Kann sich darauf jemand von euch einen Reim machen, welchen Denkfehler ich begangen habe?

@Thomas E: Da hast du natürlich recht. Aber zum Entwickeln der Software im STK, bei der man den Controller gefühlte 103352x flasht wird er noch ausreichen. In die Endanwendung kann ich ja dann einen neuen spendieren.

@Hubert.G: Danke für den Hinweis. Ich habe von diesem Modus zwar mal ganz am Anfang in der der Anleitung gelesen, aber das ganze völlig vergessen. Wofür verwendet man denn üblicherweise diesen Modus? Der Verkabelunsaufwand ist ja nicht ohne. Ist das tatsächlich dann dafür da, wenn der Controller "verfused" wurde?

Viele Grüße
Andreas

Ich kann mir nicht ganz vorstellen das der ADC für die 6V verantwortlich sind.
Bevor ich Beinchen hochbiege würde ich eher den Code löschen.
HV-Programmierung ist nicht nur für verfusede Kontroller, du kannst den Reset ja auch als I/O verwenden. Dann funktioniert allerdings ISP nicht mehr und du brauchst HV.

Wenn das STK-Board selbst gelötet ist und nicht über USB sondern über RS232 angesteuert wird, dann würde ich empfehlen nochmal die Schaltung zu checken. Dann könnte diese 6V durchaus an dem MAX232 vorbei zum µC kommen.
Bauteile auf Lötbrücken-wo keine hingehören-prüfen.

Wenn ich mir vorstelle ich biege immer die Beinchen der µC weg, um was zu testen....*kopfschüttel* ...wie wäre es denn einfach den Sockel mit den entsprechenden Pins auf ein Breadboard zu verlängern? Ich weiß, ich weiß, dazu muss man ein Braedboard kaufen... blöde Idee von mir ;)

Hallo Hubert,

danke für die Erklärung der HV-Programmierung. Das Problem für mich war ja, dass der Controller auf nichts mehr reagiert hat, bzw. das ganze STK lahm gelegt hat sobald er gesteckt war. Ansonsten war nichts weiteres verkabelt. Es war lediglich das 6-polige ISP-Kabel auf dem STK gesteckt. Also war der Controller für mich eh für die Tonne. Da macht dann Beinchen biegen auch nichts mehr, hauptsache man kommt auf die Ursache und kann sie vielleicht das nächste mal vermeiden.

@HeXPloreR: Das STK500 ist gekauft und funktioniert seit Jahren einwandfrei. Und tut es ohne den komischen Mega8 auch. Ich habe heute damit mehrere verschiedene Schaltungen einwandfrei geflasht.
Klar hätte ich mir einen "Zwischensockel" bauen können, aber siehe meine Erklärung an Hubert.

Die Ursache ist für mich aber immer noch unlogisch. Ein "leeres" STK500, das einwandfrei funktioniert. Alle Jumper in der Standard-Stellung bis auf den OSCEL für den Quarz. Nur ein Mega8 im grünen Sockel und das 6-polige ISP-Kabel entsprechend gesteckt. Und dann ca. 20 Zeilen Code zum initialisieren der Ports und Funktionen und dann habe ich plötzlich >6V Versorgungsspannung solange der Atmel steckt. Ich habe den Controller nur "aufgesetzt" und sobald ich ihn anhebe ist die Spannung des STK wieder auf 5V runter gegangen und ich konnte via AVR-Studio damit kommunizieren. Controller wieder aufgesetzt und die Spannung war >6V und das AVR-Studio meldet, dass kein STK angeschlossen ist. Durch hochbiegen von ARef und AVCC am Mega8 ist nun alles wieder in Ordnung und ich kann ohne Probleme flashen.

Ich versteh's nicht! Und zur Verwirrung hier noch mal der komplette Code:

Code:

---

#define AVRGCC

#include <avr/io.h>
#include <util/delay.h>
#include <compiler.h>

//F_CPU = 4000000

#define BAUD                    9600l
#define UBRRValue                (F_CPU / (BAUD * 16) - 1)

void sendMsg (char *Msg, bool addCR)
{
    while (*Msg != 0)
    {
        while ( !(UCSRA & (1<<UDRE)));
        UDR = *Msg++;
    }

    if (addCR)
        sendMsg ("\r\n", FALSE);
}

int main (void)
{
    DDRB =  0b11111111;
    PORTB = 0b00000000;
   
    DDRD =  0b00000000;
    PORTD = 0b00000000;

    DDRC =  0b00000000;
    PORTC = 0b00000000;
   
    UCSRB = (1<<RXCIE) | (1<<TXEN);
    UCSRC = (1<<UCSZ1) | (1<<UCSZ0);
    UBRRH = (U8)(UBRRValue>>8);
    UBRRL = (U8)UBRRValue;

    ADMUX = (1<<REFS1) |(1<<REFS0);
    ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);

    sendMsg ("Start", TRUE);
       
    while (1)
    {
    }

    return (0);
}

---

Viele Grüße
Andreas

Zitat:

---

Zitat von Bumbum

Code:

---

#define AVRGCC

#include <avr/io.h>
#include <util/delay.h>
#include <compiler.h>

//F_CPU = 4000000

#define BAUD                  9600l
#define UBRRValue                (F_CPU / (BAUD * 16) - 1)

void sendMsg (char *Msg, bool addCR)
{
    while (*Msg != 0)
    {
        while ( !(UCSRA & (1<<UDRE)));
        UDR = *Msg++;
    }

    if (addCR)
        sendMsg ("\r\n", FALSE);
}

int main (void)
{
    DDRB =  0b11111111;
    PORTB = 0b00000000;
   
    DDRD =  0b00000000;
    PORTD = 0b00000000;

    DDRC =  0b00000000;
    PORTC = 0b00000000;
   
    UCSRB = (1<<RXCIE) | (1<<TXEN);
    UCSRC = (1<<UCSZ1) | (1<<UCSZ0);
    UBRRH = (U8)(UBRRValue>>8);
    UBRRL = (U8)UBRRValue;

    ADMUX = (1<<REFS1) |(1<<REFS0);
    ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);

    sendMsg ("Start", TRUE);
       
    while (1)
    {
    }

    return (0);
}

---

---

Das Format der eingefügten Codes ist echt mies ( Hallo, Admin). Eine 1(bei 9600l ) ist ist es nämlich nicht. Was macht dieses Zeichen dort?

Und auf wieviel MHz soll der laufen?

Was findest du denn Mies daran? Das L ist nötig, damit der Compiler die Formel in der nächsten Zeile überhaupt berechnet. Ich glaube es weißt auf einen Long hin. Ohne diesen Buchstaben bringt der Compiler einen Überlauffehler.

hmm, kommt der Fehler denn wirklich vom 9600 (ohne L - denn wenn, dann großgeschrieben, auch weil besser lesbar).

Oder eher daher das F-CPU auskommentiert wurde - und dadurch mit F_CPU nicht gerechnet werden kann?

F_CPU ist in den Projekt-Eigentschaften bereits hinterlegt. Das steht im Code nur als Erinnerungshilfe. (Deswegen übrigens auch ohne #define)
Wenn es nicht stimmen würde, wäre keine RS232-Kommunikation möglich. Das geht nicht mal ohne Quarz vernünftig.

Warum probierst du es nicht einfach mal? Es gibt aber keinen Fehler wie von mir geschrieben sondern nur eine Warnung (integer overflow in expression). Ob der Code trotz der Warnung funktioniert weiß ich jetzt leider nicht aus dem Stegreif.

Und mit einem großen L gehts auch. ;-)

Warum ich es nicht probiere ist schnell gesagt: Mein einziger bisher funktionierender selbst abgeänderter Code in C lief bisher nur mit WinAVR2010 auf einem m128 mit 16Mhz und RS232 Kommunikation (nur Terminalempfang).


Okay, ich bin wieder still... ;)