ATmega328p bleibt ohne Programmer stehen

[Alexander F. (gustin)]

Guten Abend zusammen,

die Kurzfassung ist im nächsten Absatz :-)
In Langfassung folgende Situation:
vor einiger Zeit habe ich mir ein paar Arduino UNO Boards
zum experimentieren zugelegt. Zum Testen hatte ich dann auf einen
ein kleines LED Blinkprogramm gespielt. Damals noch per AVR Studio 4
mit einem Diamex PROG-S. Das lief auch bis eben hervorragend.
Da ich mir kürzlich einen neuen PC
zugelegt habe dachte ich, steige ich auf etwas Aktuelleres um,
so habe ich mit MPLAB X und einen MPLAB Snap zugelegt,
letzterer ist heute angekommen.
Nach vielem Kopfzerbrechen und komischen Fehlern habe ich die
Kombination letztlich doch ans laufen bekommen und ein
neues Testprogramm geschrieben: einfach einen Taster eingebunden,
womit sich die LED einschalten, "auf blinken" und wieder ausschalten
lässt. Das funktionierte auch soweit.
Als ich dann aber den Programmer abgeklemmt habe
blieb der ATmega sofort im Programm stehen.
Sobald ich ihn wieder anklemme läuft das Programm
an selber Stelle weiter.
Dachte erst an Stromversorgung, aber der Programmer liefert
keinen und am Board liegt es wohl auch nicht. Externer Takt?
Auch eher nicht, der ATmega lief auf 16MHz. Irgendeine Fuse?
Vielleicht zeigt der Bootvektor auf einen leeren Bereich?
Kann ja auch nicht, er resettet ja nicht in der Situation.

Nach langem eingrenzen
habe ich folgendes Problem ausgemacht:
Sobald am ISP Anschluss vom Arduino-Board der SCK Pin auf LOW
gezogen wird, läuft der Kollege. Dann auch ohne Programmer.

Hier bin ich mit meinem Latein am Ende.
Hat jemand eine Idee woran das liegen kann und wie ich das behebe?

Achso:
schreibe in Assembler bzw. C, der ganze Arduinokram
ist nicht mehr drauf. :-)

[Peter D. (peda)]

Alexander F. schrieb:
> Hier bin ich mit meinem Latein am Ende.

Warum?
Du hast doch den Fehler gefunden. Dein Program wertet diesen Pin aus.

[Marc V. (Firma: Vescomp) (logarithmus)]

Alexander F. schrieb:
> Achso:
> schreibe in Assembler bzw. C, der ganze Arduinokram
> ist nicht mehr drauf. :-)

 Und wie wäre es wenn du mal das schickst, was drauf ist?

 Achso:
 SCK ist PB.5.
 Hat absolut nix mit funktionieren oder nicht funktionieren zu tun.

 Kann aber sein, daß irgendjemand PB.5 als Eingang deklariert hat
 und Arduino möglicherweise Log.0 an PB,5 erwartet um weiterzugehen...

[Einer K. (Gast)]

Marc V. schrieb:
> und Arduino möglicherweise Log.0 an PB,5 erwartet um weiterzugehen...
Normalerweise nicht.

[Alexander F. (gustin)]

Okay,
danke schonmal dafür.
Ich hatte tatsächlich das obere Nibble von Port B als
Eingang (auch noch Hochohmig) und das war mit in einer Abfrage.
Manchmal hat man auch wirklich einen Knoten im Gehirn. :D

Jetzt frage ich mich nur noch, warum es bei Pin 4 kein
Problem gab...

[Einer K. (Gast)]

Alexander F. schrieb:
> Jetzt frage ich mich nur noch, warum es bei Pin 4 kein
> Problem gab...

Vielleicht solltest du nochmal in dein Programm schauen.

[Alexander F. (gustin)]

Nein, glaube ich habs gefunden.
An Pin 13 hängt noch eine LED, denke mal die hat den Eingang
hochgezogen. :-)

[Einer K. (Gast)]

Beim UNO ist da ein OPV dazwischen.
So kann die LED da eigentlich nix hoch ziehen.

[Alexander F. (gustin)]

Ist tatsächlich noch ein OPV vor, hatte hier nur auf ein
Bild mit den Pinbelegungen geschaut, da war die mit eingezeichnet.
Naja, jedenfalls läuft es jetzt und es lag an meiner Schludrigkeit.
Dann hab ich ja jetzt was zum spielen :D

Vielen Dank an alle und eine Gute Nacht. :-)

[M. K. (sylaina)]

Arduino Fanboy D. schrieb:
> Beim UNO ist da ein OPV dazwischen.
> So kann die LED da eigentlich nix hoch ziehen.

Vor allem da sie gegen Ground geschaltet ist. Die zieht bestenfalls 
runter.
Ohne das Programm zu sehen kann man schlicht nicht sagen, was da alles 
falsch drin war.

[Alexander F. (gustin)]

Moin zusammen,
der Fehler ist ja gefunden. Ich hatte mich,
weil das Programm ja lief und wegen der Sache
mit dem Programmer, einfach so auf Konfig und Hardware versteift,
dass ich gar nicht mehr über einen Programmfehler nachgedacht habe.
Aber hier ist noch der Code, das waren nur ein paar Zeilen zum Testen:

#include <avr/io.h>
#include <stdint.h>
#define F_CPU 16000000UL
#include <util/delay.h>

uint8_t checkKey();
void blink();

int main(void) {
    //Port B auf Eingang
    DDRB=0x00;
    //Port D auf Ausgang  
    DDRD=0xFF;
    /* Jetzt kommt der Fehler. Zunächst hatte ich PORTB auf
    0xFF, sollten einfach alle Pull-Ups an.
    Da mich aber die LED auf dem Board genervt hat,
    hab ich einfach das obere Nibble raus genommen: */
    PORTB=0x0F; 
    PORTD=0x00;
    uint8_t status = 0;
    while (1) {
        if(checkKey() == 1){
            if(status == 0){
                status = 1;
                blink();    //meine LED blinken lassen, beim verlassen an
            }
            else{
                status = 0;
                PORTD &= ~(1<<PD7);   //meine LED aus
            }
        }
    }
}

uint8_t checkKey(){
    if(PINB != 0x0F){
        _delay_ms(60);    //entprellen
        if(PINB != 0x0F){
            while(PINB != 0x0F){  //warten bis taste losgelassen
                PORTD &= ~(1<<PD0);   //Kontroll-LED an
            }
            PORTD |= (1<<PD0);    //Kontroll-LED aus
            return 1;
        }
    }
    return 0;    
}

void blink(){
    while(checkKey() == 0){
        _delay_ms(500);
        PORTD ^= (1<<PD7); 
    }
    PORTD |= (1<<PD7);
}

Hier sind ja jetzt die die Eingänge PB4 und PB5(SCK) hochohmig,
also hätte mMn PB4 den gleichen Fehler verursachen müssen,
dem war aber nicht so.

Das obere Nibble von DDRB ist jetzt auf Ausgang, dann sind
die Pegel dort definitiv low, so läuft es auch wie es soll.

Das war übrigens nur ein schnell dahingetipptes Programm um
irgendwas zu haben das ich auf den µC schreiben kann.
Meine LED hing schon an PD7 und für den Taster war ich zu faul die
Pins zu zählen, daher hab ich den ganzen Port genommen :D

[Einer K. (Gast)]

Alexander F. schrieb:
> Hier sind ja jetzt die die Eingänge PB4 und PB5(SCK) hochohmig,
> also hätte mMn PB4 den gleichen Fehler verursachen müssen,
> dem war aber nicht so.

Bei hochohmigen Eingängen machen geringste Leckströme/Einstreuungen 
schon gewaltige Unterschiede aus.

Mantra:
Offene Eingänge gilt es zu vermeiden.
Bzw. Beim auswerten dieser, kann jeglicher Mist passieren.

Bei den Arduinos kommt erschwerend hinzu, dass beim UNO die LED an PB5 
entkoppelt ist, aber beim Nano und ProMini eben nicht.
Da wird der Eingang durch die LED belastet und kann selbst mit dem 
internem Pullup nicht unbedingt High erreichen.

Programme, welche Pin13 als Input nutzen sind also nicht sonderlich 
portabel.

Meine Empfehlung (für ATMega328P Arduinos) :
Den Pin 13, PB5, nur als Ausgang nutzen.
Entweder als Leuchtmelder oder eben für SPI

[M. K. (sylaina)]

Alexander F. schrieb:
> Meine LED hing schon an PD7 und für den Taster war ich zu faul die
> Pins zu zählen, daher hab ich den ganzen Port genommen :D

Also bei meinem Arduino sind die Pins beschriftet, da muss man nicht 
zählen ;)