Also wenn du STK500 hast, dann verwende doch den HV-Programmier-Modus. Da sind doch nur ein paar zusätzliche Kabel zum stecken.
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:
Kann sich darauf jemand von euch einen Reim machen, welchen Denkfehler ich begangen habe?Code:ADMUX = (1<<REFS1) |(1<<REFS0); ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);
@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:
Viele GrüßeCode:#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); }
Andreas
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.
Lesezeichen