ATMega1284P LED geht nicht

[Julian (Gast)]

Moin,
Ich habe einen ATMega1284P auf meinem Steckbrett installiert. An PA0 
hängt eine LED gegen VCC. Reset liegt per 1k auf VCC.

Ich programmiere den IC per AVR MKII mit folgendem Programm:

>>#include <avr/io.h>
>>
>>int main(void)
>>{
>>  DDRA = 0x01;
>>  PORTA = 0x01;
>>
>>  while(1);
>>
>>  return 0;
>>}

Mein Problem: AVR Studio meldet erfolgreiche Programmierung, jedoch tut 
sich an der LED rein gar nichts!

Das ganze war erst gelötet und ist nun auf einem Steckbrett.
LED ist richtig herum angeschlossen und funktioniert mit Masse anlegen 
auf PA0. Wechseln zwischen 1MHz intern, 8MHz intern und 16MHz Quarz hat 
keinen Unterschied gemacht. Wechseln des Ports ebenfalls nicht.

Ich bin mittlerweile völlig ratlos, wo der Fehler liegen soll!

Hat da vielleicht noch jemand ne Idee?

Julian

[Carl D. (jcw2)]

> hängt eine LED gegen VCC
...
> PORTA = 0x01;

Dann erwartest du, daß die mit 0 μA Strom leuchtet?
Lass mal PORTA auf 0
Und mach noch 100..470Ω dazwischen.

[Daniel B. (inox5)]

1.Nachdem Du auf das Quarz umgeschaltet hast in den Fuses, konntest Du 
dann noch erfolgreich programmieren?

2.Falls ja, probiere folgendes Programm:

#include <avr/io.h>

int main(void)
{
  //PORTS
  DDRA |= (1<<DDA0);
  PORTA |= (1<<PORTA0);
    while(1)
    {
      
    }
}

3. Falls es dann immernoch nicht funktioniert: Hardware checken. 
Insbesondere ob die LED richtig gepolt und angeschlossen ist, gegen 
Masse geschaltet ist und an sich funktioniert.

[Julian (Gast)]

Sorry mein Fehler:
In der Verzweiflung habe ich bereits beides ausprobiert. Also PA0 auf 
Masse gegen VCC und umgekehrt.

Ist ne 5V LED mit integriertem Vorwiderstand. Funktioniert an einem 
ATMega32 problemlos!

[Julian (Gast)]

Daniel B. schrieb:
> 1.Nachdem Du auf das Quarz umgeschaltet hast in den Fuses,
> konntest Du
> dann noch erfolgreich programmieren?

Jup.

> 2.Falls ja, probiere folgendes Programm:
> #include <avr/io.h>
>
> int main(void)
> {
>   //PORTS
>   DDRA |= (1<<DDA0);
>   PORTA |= (1<<PORTA0);
>     while(1)
>     {
>
>     }
> }

Habe dafür die LED wieder gegen GND gedreht. Hat aber leider auch nicht 
funktioniert.

> 3. Falls es dann immernoch nicht funktioniert: Hardware checken.
> Insbesondere ob die LED richtig gepolt und angeschlossen ist, gegen
> Masse geschaltet ist und an sich funktioniert.

Wenn ich PA0 aktiv mit VCC verbinde, leuchtet sie. Beide GND sind an 
Masse angeschlossen, VCC, AREF und AVCC an 5V. 1k zwischen Reset und 
VCC, 22p zwischen GND und XTAL1 bzw. XTAL2. 1 16MHz Quarz zwischen XTAL1 
und XTAL2.

[Thomas W. (Gast)]

Julian schrieb:
> In der Verzweiflung habe ich bereits beides ausprobiert. Also PA0 auf
> Masse gegen VCC und umgekehrt.

Wildes Probieren ist in Sachen Elektronik oft ein schlechter Ratgeber. 
Es gib Bauelemente, die das gar nicht mögen.

Damit es nicht gar so schwierig wird, könntest du am Port ein 
Rechtecksignal ausgeben, z.B. indem du in deiner Hauptschleife den Pin 
abwechselnd auf 0 oder 1 schaltest - verziert mit ein paar 
delay()-Aufrufen. Und statt LED könntest du auch mal einen 
Spannungsmesser dran halten.

Aber vielleicht hast du deine Ports auch systematisch durch probieren 
gekillt :-(

[Daniel B. (inox5)]

#include <avr/io.h>

int main(void)
{
  //PORTS
  DDRA = 0xFF;
  PORTA = 0xFF;
    while(1)
    {
      
    }
}

Sollte den gesamten PORTA auf high schalten. Miss doch mal die Pegel an 
PA0:7 und schau ob die auf 5V gehen.

[Guest (Gast)]

Julian schrieb:
> Wenn ich PA0 aktiv mit VCC verbinde

und er eigendlich auf GND programmiert ist kannst Du schonmal ein neues 
IC bestellen.
Einen Port der auf Ausgang steht von Außen hart mit GND oder Vcc zu 
verbinden ist keine gute Idee. Die erlaubten 40mA sind da schneller 
überschritten als Du hinsehen kannst.

[Julian (Gast)]

Thomas W. schrieb:
> Wildes Probieren ist in Sachen Elektronik oft ein schlechter Ratgeber.
> Es gib Bauelemente, die das gar nicht mögen.

Wildes Probieren lass ich mir nicht vorwerfen. Bei LED mit Vorwiderstand 
bei 5V ist simples kurzzeitiges umpolen kein Problem. Ich habe den IC zu 
Anfang, in meine mit einem ATMega32 funktionierende Platine, gesteckt 
und da hätte die LED direkt leuchten sollen, was sie auch nicht tat!

> Damit es nicht gar so schwierig wird, könntest du am Port ein
> Rechtecksignal ausgeben, z.B. indem du in deiner Hauptschleife den Pin
> abwechselnd auf 0 oder 1 schaltest - verziert mit ein paar
> delay()-Aufrufen. Und statt LED könntest du auch mal einen
> Spannungsmesser dran halten.

Braucht gar nicht so komplex. Eine Spannungsmessung (auch bei kompletten 
Port ein) hat erneut ergeben, dass überall ca. 0,2V anliegen. Auch an 
anderen Ports, die nicht beschaltet sind!

[Daniel B. (inox5)]

Noch ein Versuch, was mir mal mit dem Atmel Studio passiert ist:

Checke mal, ob Du überhaupt ein aktuelles Compilat programmierst.

[Julian (Gast)]

Guest schrieb:
> Julian schrieb:
>> Wenn ich PA0 aktiv mit VCC verbinde
>
> und er eigendlich auf GND programmiert ist kannst Du schonmal ein neues
> IC bestellen.
> Einen Port der auf Ausgang steht von Außen hart mit GND oder Vcc zu
> verbinden ist keine gute Idee. Die erlaubten 40mA sind da schneller
> überschritten als Du hinsehen kannst.

Prinzipiell korrekt. Praktisch sind die Pins im hochohmig und es fließt 
kein Strom. Wie gesagt, am Anfang in eine bereits funktionierende 
Schaltung eingebaut und kein Ergebnis. Hätte es daran gelegen, dass ich 
da VCC oder GND rangebe, hätte er zu Anfang funktionieren müssen ;)

Mal davon abgesehen, hast du prinzipiell recht, auch wenn man ein PORT 
m.E. so schnell nicht zerschießt. Strom aus dem Labornetzteil ist auf 
ca. 100mA begrenzt.

[Julian (Gast)]

Daniel B. schrieb:
> Noch ein Versuch, was mir mal mit dem Atmel Studio passiert ist:
>
> Checke mal, ob Du überhaupt ein aktuelles Compilat programmierst.

Die Hex Datei ist korrekt ausgewählt und ist laut Windows im Moment vor 
der Programmierung aktualisiert worden. Habe die Datein auch mal 
gelöscht und neu kompiliert, leider kein Unterschied :/

[Guest (Gast)]

Julian schrieb:
> Mal davon abgesehen, hast du prinzipiell recht, auch wenn man ein PORT
> m.E. so schnell nicht zerschießt.

Das stellt man oft erst später an unerklärlichem Verhalten fest. Solche 
Versuche sollte man nur mit einem Widerstand (hier wohl 330 Ohm) 
durchführen.

Julian schrieb:
> Strom aus dem Labornetzteil ist auf ca. 100mA begrenzt.
Und damit zweieinhalb Mal so hoch wie es ein Port nach Datenblatt 
maximal ab kann.

Du hast den Prozessortyp im Atmelstudio aber vor dem Compilieren 
angepasst?

[Julian (Gast)]

Ich habe das Gefühl, dass der IC das Programm überhaupt gar nicht erst 
ausführt! Denn würde er den PORT auf Ausgang schalten, würden da keine 
wackligen 0,2V anliegen. Kann das sein, dass der Programmzeiger evtl. 
durch Fuses noch speziell gesetzt werden muss? Btw. JTAGGEN, Brown Out, 
CKDIV8 ist gesetzt.

[Daniel B. (inox5)]

Mach mal das JTAGEN aus, sofern du per PDI/ISP drauf bist.

[Guest (Gast)]

Das wird nichts ändern, JTAG liegt auf PortC.

[Julian (Gast)]

Ich bin mir nicht ganz sicher, reicht es, im "AVRISP mkII in ISP mode 
with ATmega1284P"-Fenster einfach den IC auszuwählen? Read-Signature 
meldet match.

Habe sicherheitshalber, nachdem es nicht funktioniert, ein neues Projekt 
erstellt und dort direkt den IC gewählt. Demenstprechend denke ich 
schon.

[Guest (Gast)]

Julian schrieb:
> Ich bin mir nicht ganz sicher, reicht es, im "AVRISP mkII in ISP mode
> with ATmega1284P"-Fenster einfach den IC auszuwählen?

Nein, Du mußt in den Projekteigenschaften den richtigen Prozessor 
wählen, Du hast nur die Programmierfunktion angepasst.

[Guest (Gast)]

ähh, AVcc hast Du aber auch angeschlossen oder?

[Julian (Gast)]

Guest schrieb:
> Nein, Du mußt in den Projekteigenschaften den richtigen Prozessor
> wählen, Du hast nur die Programmierfunktion angepasst.

Danke!!! Das war der entscheidende Hinweis. Wieso auch immer stand er da 
auf ATMega128 -.-

Wozu muss ich denn zweimal angeben, was für ein IC ich nutze? Müssen die 
Optionen nicht zwangsweise immer gleich eingestellt sein?

[c-hater (Gast)]

Julian schrieb:

> Wozu muss ich denn zweimal angeben, was für ein IC ich nutze? Müssen die
> Optionen nicht zwangsweise immer gleich eingestellt sein?

Nein, die Flasherei ist weitestgehend unabhängig von der 
Programmerstellung. Du kannst z.B. problemlos Hex-Dateien flashen, von 
denen du nichtmal den Quelltext hast.

Zwar hat Atmel eine Möglichkeit vorgesehen, den Programmer entsprechend 
dem aktuellen Projekt einzustellen (das muß aber erstmal aktiviert 
werden und funktioniert auch eher schlecht bis garnicht), aber 
umgekehrt, daß also die Programmerstellung sich nach den Einstellungen 
des Programmers richtet, dafür gibt es keine Möglichkeit.

Und es widerspräche ja auch völlig der Kausalität. Zuerst schreibt man 
das Programm, dann wird geflasht. Also macht nur eine Parameterübergabe 
in Richtung der Flash-Mimik irgendeinen Sinn.