STK500 Sockets fallen nacheinander aus

[Kai F. (kai-)]

Hallo,
ich programmiere jetzt schon seit fast einem Jahr relativ häufig auf 
meinem STK500. Hat auch bis jetzt alles super funktioniert.
Jetzt ist allerdings ein Problem aufgetreten, das ich mir einfach nicht 
erklären kann.
Angefangen hat es als ich einen ATmega32 ohne geänderte Hardware (nur 
ein sehr sehr kleines Softwareupdate), der auf dem Sockel auf dem STK500 
saß, programmieren wollte.
Eine Minute zuvor hat noch alles funktioniert, aber auf einmal gibt mir 
CodevisionAVR eine noch nie gesehene Fehlermeldung (zu schnell 
weggeklickt um sich den Text zu merken) und hängt sich auf.
Also hab ich das AVR Studio ausgepackt und versucht auf das STK500 zu 
connecten ohne Erfolg. Also... alle Kabel entfernt, immernoch nicht. 
Erst als ich den mega32 aus dem Sockel genommen habe, kam ich wieder auf 
das Board drauf. Das komische war, dass ich nichts verändert habe und an 
das STK auch keine zusätzliche Hardware angeschlossen habe. Der 
Controller hat auch immernoch Strom bekommen und hat sein Programm auch 
noch ausgeführt.

Also hab ich eben schnell das Programm auf einen mega8 umgeschrieben und 
konnte ihn ohne Probleme programmieren und die Fuses setzen. Bei dem 
Versuch ihn erneut zu programmieren, habe ich wieder den gleichen Fehler 
wie beim mega32 bekommen und konnte auch mit AVRStudio nicht aufs STK 
connecten. Als ich den mega8 entfernt hatte, ging das jedoch wieder...

Dann hab ich mir gedacht frag ich hier mal ob jemand eine Idee hat woran 
das liegt bevor ich mir noch einen Sockel lahm lege.

Vielleicht kann mir ja wer helfen

Gruß
Kai

[Erik D. (dareal)]

Bin zwar µC-Newbie aber greift dein Programm vllt. auf die ISP-Port zu, 
was das Programmieren unmöglich macht?

[Kai F. (kai-)]

das Programm benutzt tatsächlich die Pins, die auch der ISP benutzt, das 
ist allerdings auch egal, da man die Pins benutzen kann und das Programm 
genauso vorher auch lief. Außerdem zeigt ein neuer µC das gleiche 
Verhalten und es geht auch nicht um das Programmieren, sondern darum, 
dass ich nicht mal mehr auf das STK500 connecten kann

[Kai F. (kai-)]

hat keiner eine Idee?
Das Programmieren von eingebauten Controllern funktioniert bis jetzt 
einwandfrei

[derwarze (Gast)]

Scheint mir so als ob die Versorgungsspannung kurzgeschlossen würde. Die 
grüne LED neben der vtarget brücke leichter normal hell? Wenn nicht mal 
den Jumper ziehen leuchtet die dann heller schliesst was die 
Betribsspannung kurz, meist ein versehentlich falsch gesteckter IC auf 
dem Sockel.

Da externes Proggen geht ist die Haupthardware des STK ja ok.

[Kai F. (kai-)]

Das Problem scheint tatsächlich an meinem Lauflicht Programm zu liegen, 
weil ein frischer Controller sich wieder ansprechen lässt. Nur geht eben 
nichts mehr wenn ich das Programm drauf spiele... Also das Programm 
läuft schon, aber das STK lässt sich nicht mehr ansprechen. Wenn ich 
VTarget ziehe wird die LED schwächer und die eine leuchtet rot und 
blitzt hin und wieder grün.
Wie kann ich denn ein Programm schreiben, das das komplette STK lahm 
legt wenn ich nur die STK eigenen LEDs verwende?
Ich hab den interessanten Teil vom Programm mal angehängt. Die Variable 
j wird über einen Timer hoch bzw runter gezählt.
Das ganze ist ein Knight Rider Lauflicht, also mit Schweif

switch(i)
        {
        case 0:
        {
                PORTC = 255;
                PORTC &=~ (1<<j);
                delay_us(200);
                PORTC &=~ (1<<j-1);
                delay_us(15);
                PORTC &=~ (1<<(j+1));
                PORTC &=~ (1<<(j+2));
                delay_us(1);  
                PORTC &=~ (1<<(j+3));
        }    
        break;
        case 1:
        {
                PORTC = 255;
                PORTC &=~ (1<<j);
                delay_us(200);
                PORTC &=~ (1<<j+1);
                delay_us(15);
                PORTC &=~ (1<<abs(j-1));
                PORTC &=~ (1<<abs(j-2));
                delay_us(1);  
                PORTC &=~ (1<<abs(j-3)); 
        }
        break;
        }

[Gast23 (Gast)]

Hast du schon HV-Programierung versucht?

[Kai F. (kai-)]

nein, hab ich noch nicht, werd ich dann mal bei Gelenheit mal tun

[Michael G. (linuxgeek)]

Problem mit den Fuses?

[Kai F. (kai-)]

die Fuses sind auf 8MHz interner Oszi gestellt. Sollte da was nicht 
stimmen, würde das Programm wohl auch nicht ausgeführt werden...
echt komisch sowas

[Björn W. (bwieck)]

Hast Du evtl den Resetpin als Portpin programmiert?
Das würde das Verhalten erklären.

Bei Mega8 ist PortC Bit6 der Resetpin...
Dann hilft nur noch HV-Programierung.

Grüße
Björn

[Kai F. (kai-)]

nein, das Problem ist zuerst beim mega32 aufgetreten und dann nur auch 
noch beim mega8. Der Reset Pin wird in beiden Fällen nicht benutzt

[Jadeclaw D. (jadeclaw)]

Ich empfehle mal, das Programm so abzuändern, daß die 
Programmieranschlüsse als Eingänge verwendet werden. Logik-ICs mögen es 
im Allgemeinen nicht, wenn Ausgang auf Ausgang arbeitet.

Gruß
Jadeclaw.

[Kai F. (kai-)]

das Problem ist, dass ich den Controller nur nur über HV programmieren 
könnte oder eben wenn ich ihn auf einer externen Platine verlöte. Ein 
einfaches ändern des Programms ist daher nicht möglich...
Außerdem halte ich das für ein Gerücht, dass es nicht funktioniert wenn 
die ISP Pins auf Ausgang geschaltet sind. Das würde ja auch dem In 
System widersprechen

[Knut B. (Firma: TravelRec.) (travelrec)]

Da die Pins des Controllers hochohmig werden, wenn die ISP-Schnittstelle 
des STK den Reset-Pin des Controllers auf Masse zieht, ist es vollkommen 
wurst, ob das Programm an den MOSI, MISO und SCK-Pins wackelt, oder 
nicht. Die ISP-Treiber des STK machen sich auch nichts bei laufendem 
Programm daraus, da es OC-Ausgänge mit PullUp sind. Daran liegt es also 
definitiv nicht. PortC ist tatsächlich auf die LEDs geklemmt und der 
10-polige Stecker ist nicht zufällig verdreht?

[Kai F. (kai-)]

PORTC ist wirklich auf die LEDs geklemmt und nicht verdreht, sonst würde 
das Programm ja auch nicht mehr richtig ausgeführt werden.
Es kann auch eigentlich nichts mit der Programmierschnittstelle zu tun 
haben, da ich das STK gar nicht mehr ansprechen kann, also nicht mal 
mehr zum Dialog komme, wo ich den Controller programmieren kann...

[Knut B. (Firma: TravelRec.) (travelrec)]

Kann es sein, daß der Controller einfach zu viel Strom zieht und das 
Netzteil am STK zu schwach ist? Das STK braucht 10...12V bei 500mA um 
richtig zu funktionieren. Du hast auch nur einen Controller im STK 
stecken, ja?

[Kai F. (kai-)]

Es steckt wirklich nur ein Controller im STK und ich verwende ein 
Bleiakkuladegerät mit 300mA, das reicht normal auch. Ändern tut sich 
auch nichts wenn ich es mit meinem Labornetzteil (5A) beheize.
Was ich jetzt aber herausgefunden habe ist, dass alles wieder zu 
funktionieren scheint wenn ich den Jumper bei AREF herausziehe.
Sehr merkwürdig... aber jetzt weiß ich wenigstens wie ich meinen mega32 
rette :)

[Andreas K. (a-k)]

Den AREF Jumper sollte man immer offen lassen, es sei denn man will 
ausdrücklich die vom STK500 erzeugte Referenzspannung an dem AREF-Pin 
haben. Sonst hat man das Problem, dass bei Verwendung des ADC die 
Controller-interne Referenzspannung (also oft VCC) auf diesem Pin liegt 
und dort gegen die STK500-Referenz ankämpft.

[Kai F. (kai-)]

das scheint tatsächlich das Problem gewesen zu sein.
Ich hatte im Code den ADC initialisiert, aber nicht benutzt
Vielen Dank an alle, die sich damit rumgeschlagen haben :)

[Peter D. (peda)]

Travel Rec. wrote:
> Da die Pins des Controllers hochohmig werden, wenn die ISP-Schnittstelle
> des STK den Reset-Pin des Controllers auf Masse zieht, ist es vollkommen
> wurst, ob das Programm an den MOSI, MISO und SCK-Pins wackelt, oder
> nicht.

Das stimmt.

Ich hab auch öfter die LEDs auf SPI-Pins gelegt und noch nie Probleme 
gehabt.
Es sieht ganz lustig aus, wenn die LEDs beim Programmieren mitflackern.


Peter

[Knut B. (Firma: TravelRec.) (travelrec)]

Booah, der ADC... Na wer denkt denn an sowas. Na man gut, daß das jetzt 
geklärt ist ;-)