ATmega168 verhält sich mit ISP anders

[SaschaGast (Gast)]

Hallo,

ich benutze einen ATmega168. Port C PC4 und PC5 sind mit LEDs 
beschaltet, wobei die LED an PC5 unter bestimmten Umständen (z.B. Fehler 
im Gerät) blinken soll. Die LED's hängen mir 470R in Reihe an 5V und 
werden direkt vom µC-Port getrieben (Port=0->LED leuchtet, Port=1->LED 
leuchtet nicht). Die restlichen Port C's werden als ADC genutzt mit 
4,096V externer Referenz. DDRC hat PC4 und PC5 auf 1 damit Output 
gewählt ist, die restlichen DDRC's lasse ich im Init-Zustand den der µC 
bein hochfahren hat.  Der Quarz ist 8MHz mit 2x10pF. PC6 (Resetleitung) 
hat einen 4k7 Pull-Up. MOSI, MISO und SCK gehen direkt zum µC, ohne 
Pull-Ups.
Die Steuerung für die Blinkerei ist im Timer 1.

Folgendes Problem:

Mit angestecktem ISP-Kabel funktioniert das Blinken der LED an PC5 
bestens. Wenn ich das ISP-Kabel nicht angeschlossen habe, blinkt die LED 
an PC5 nicht.  Ob das Debug-Wire enabled ist oder nicht ändert nichts an 
diesem seltsamen Verhalten. Es muss noch nicht einmal der AVR-Dragon 
USB-seitig angesteckt sein damit die LED blinkt, es reicht das ISP 
anzustecken. Wenn ich bei abgezogenem ISP-Kabel den Zustand herstelle wo 
die LED blinken soll, es aber nicht tut, und dann im Betrieb das 
ISP-Kabel anstecke beginnt die LED zu blinken und blinkt auch weiter 
wenn ich das ISP-Kabel wieder abziehe.

Was könnte der Fehler sein ?

MfG, Sascha

[Lukas K. (carrotindustries)]

SaschaGast schrieb:
> Port C

JTAG ausschalten

[Hc Z. (mizch)]

Luk4s K. schrieb:
> JTAG ausschalten

Am Mega168?  Da hat Pawlow einen Hund zuviel gehabt.  Und der hat prompt 
gebissen.

[SaschaGast (Gast)]

Ich hab im Datenblatt gesucht und finde nichts zum JTAG ... bin einfach 
zu dämlich ... das DebugWire hab ich schon disabled/enabled, hat keinen 
Einfluss .... was ich eben noch gefunden habe ist das ein Pull-Up am SCK 
zu gehen scheint ... was heisst scheint, mit Pull-Up an SCK gehts ... 
habt Ihr eine Erklärung dafür ? Ich freue mich zwar wenn es geht, aber 
allein schon des Lernens wegen möchte ich verstehen warum der Pull-Up 
hilft. Hängt es vielleicht mit den internen Pull-Ups zusammen ?

[SaschaGast (Gast)]

Hab jetzt den PortB DDRB PB5 (SCK) auf Input geschaltet und PORTB, PB5 
auf 1 gesetzt so dass der interne Pull-Up eingeschaltet ist (?) und nun 
blinkt die LED auch ohne ISP-Kabel. Ich vermute mal im AVR-Dragon ist 
ein Pull-UP an SCK und durch den geht es (muss ich bei Gelegenheit mal 
durchmessen, der Dragon ist im Moment in einem Gehäuse eingebaut). 
Verstehen tue ich das aber leider nicht, schon garnicht wie die 
Beschaltung an PortB Einfluss auf den PortC nehmen kann ?

[Hc Z. (mizch)]

Zu JTAG konntest Du nichts finden, da der ATmega168 keinen hat.  Deshalb 
meine Anspielung auf den Pawlowschen Beißreflex, der Dir die 
JTAG-Antwort eingebracht hat.  (Der kommt vom ATmega32 + Verwandte.)

Was ist sonst an PORTB?  Wird PINB im Programm verwendet und vielleicht 
ein bestimmter Pegel am SCK-Pin angenommen?

[Lukas K. (carrotindustries)]

Wie ist denn der Reset-Pin beschaltet? Der Zustand von SCK sollte dem µC 
eigentlich ziemlich egal sein. Wahrscheinlicher ist, dass der Resetpin 
in der Luft schwebt.

[Hc Z. (mizch)]

Reset hat einen internen Pullup und kann deshalb nicht in der Luft 
hängen.

[SaschaGast (Gast)]

An den PortB Leitungen die zum ISP gehen ist nur MOSI, MISO und SCK 
dran. Alle direkt zum Stecker, ohne Pull-Ups und ohne dass weitere 
Signale geschaltet werden. PB0,PB1 und PB2 steuern Signale meines Geräts 
und an PB6 und PB7 hängt der Quarz. Reset (PC6 an PortC) ist mit 4k7 an 
5V verbunden, der ist auch bestueckt, hab ich grade nochmal geprüft (es 
sei denn der ist kaputt und hochohmig).

[Hubert G. (hubertg)]

Eventuell Kondensatoren am Quarz zu klein, sollten 12 - 22 p sein.

[Micro (Gast)]

masse.....