STK500 Sockets fallen nacheinander aus

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

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

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

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

1

switch(i)

2

        {

3

        case 0:

4

        {

5

                PORTC = 255;

6

                PORTC &=~ (1<<j);

7

                delay_us(200);

8

                PORTC &=~ (1<<j-1);

9

                delay_us(15);

10

                PORTC &=~ (1<<(j+1));

11

                PORTC &=~ (1<<(j+2));

12

                delay_us(1);  

13

                PORTC &=~ (1<<(j+3));

14

        }    

15

        break;

16

        case 1:

17

        {

18

                PORTC = 255;

19

                PORTC &=~ (1<<j);

20

                delay_us(200);

21

                PORTC &=~ (1<<j+1);

22

                delay_us(15);

23

                PORTC &=~ (1<<abs(j-1));

24

                PORTC &=~ (1<<abs(j-2));

25

                delay_us(1);  

26

                PORTC &=~ (1<<abs(j-3)); 

27

        }

28

        break;

29

        }

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

Problem mit den Fuses?

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

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

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

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.

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

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?

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...

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?

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 :)

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.

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 :)

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

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