ATmega328p bleibt ohne Programmer stehen

OP #6133659
Lesenswert?

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. :-)
(Firma: Vescomp) #6133671
Lesenswert?

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...
Beitrag #6133690 wurde von einem Moderator gelöscht.
OP #6133946
Lesenswert?

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:
1
#include <avr/io.h>
2
#include <stdint.h>
3
#define F_CPU 16000000UL
4
#include <util/delay.h>
5

6
uint8_t checkKey();
7
void blink();
8

9
int main(void) {
10
    //Port B auf Eingang
11
    DDRB=0x00;
12
    //Port D auf Ausgang  
13
    DDRD=0xFF;
14
    /* Jetzt kommt der Fehler. Zunächst hatte ich PORTB auf
15
    0xFF, sollten einfach alle Pull-Ups an.
16
    Da mich aber die LED auf dem Board genervt hat,
17
    hab ich einfach das obere Nibble raus genommen: */
18
    PORTB=0x0F; 
19
    PORTD=0x00;
20
    uint8_t status = 0;
21
    while (1) {
22
        if(checkKey() == 1){
23
            if(status == 0){
24
                status = 1;
25
                blink();    //meine LED blinken lassen, beim verlassen an
26
            }
27
            else{
28
                status = 0;
29
                PORTD &= ~(1<<PD7);   //meine LED aus
30
            }
31
        }
32
    }
33
}
34

35
uint8_t checkKey(){
36
    if(PINB != 0x0F){
37
        _delay_ms(60);    //entprellen
38
        if(PINB != 0x0F){
39
            while(PINB != 0x0F){  //warten bis taste losgelassen
40
                PORTD &= ~(1<<PD0);   //Kontroll-LED an
41
            }
42
            PORTD |= (1<<PD0);    //Kontroll-LED aus
43
            return 1;
44
        }
45
    }
46
    return 0;    
47
}
48

49
void blink(){
50
    while(checkKey() == 0){
51
        _delay_ms(500);
52
        PORTD ^= (1<<PD7); 
53
    }
54
    PORTD |= (1<<PD7);
55
}

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
Gast #6133988
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren