ATtiny13A führt Programm nicht aus

[Julian U. (julian94)]

Hallo zusammen,
seit paar Tagen versuche ich meinen ATtiny13A zum Laufen zu bekommen. 
Ich habe verschiedene Beiträge/Artikel hier und auf anderen Seiten 
durchgeforstet, aber nichts passendes für mich finden können.
Zum Anliegen:
Es soll lediglich eine LED zum blinken gebracht werden. In der Uni 
arbeiten wir mit einem ATmega128 und dem STK500, das mir aber für mein 
Vorhaben deutlich zu überdimensioniert scheint. Also wie gesagt, ich 
will ohne Entwicklungsboard meinen tiny mit einer blinkenden LED zum 
Laufen bringen. Problem hierbei ist, dass der zueghöroge Ausgang (PB3) 
permanent HIGH ist, egal was ich schalte und walte.
Im Detail:
Ich habe das AVr Studio 6 und als Programmer/Debugger den Atmel ICE III. 
Meinen tiny habe ich gemäß Datenblatt korrekt über SPI mit dem 
programmer verbunden. Mein C-Code (siehe unten) wird korrekt gebuildet 
und anschließend auch ohne Fehlermeldung auf den tiny übertragen. 
Anschließend leuchtet meine LED dauerhaft.
Ich habe bereits gelesen, dass man in den Build-Einstellungen auf 
"Release" stellen muss. Auch das klappt leider nicht.
Auch habe ich verschiedene Grundschaltungen ausprobiert, obwohl mein 
Profesor meint, dass prinzipiell keine Grundschaltung nötig wäre. Die 
aktuelle Grundschaltung sieht so aus, dass am RESET-Pin ein Pull-Up von 
10k und ein 47nF Kondensator an GND angeschlossen ist. Außerdem noch ein 
100nF zwischen Vcc und GND. Vcc ist übrigens eine konstante Spannung von 
5V. Und an Pin PB3 ist meine LED mit Vorwiderstand an GND angeschlossen. 
Einen externen Quarz verwende ich (noch) nicht, weil für meine ersten 
Tests ich nicht darauf angewiesen bin und erstmal Hard- und Software 
kennenlernen möchte. (In der Uni arbeiten wir bspw. mit Eclipse auf Arch 
Linux).
Wo könnte mein Fehler liegen? Ist es eine fehlende Einstellung im AVR 
Studio oder ist meine Schaltung falsch? Sind irgendwelche Fuses 
standardmäßig "falsch" gesetzt, sodass ich sie anders setzen muss? Nach 
meinen Recherchen ja eigentlich nicht. Ansonsten habe ich alle 
Einstellungen auf Standard gelassen.
Ich bedanke mich schon einmal und hoffe hier keinem in irgendeiner Art 
und Weise auf die Füße getreten zu haben.

Anbei noch mein C-Code:

#define F_CPU 8000000L

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    DDRB |= (1 << PB3);
  
  while(1)
    {
    PORTB |= (1 << PB3);
    _delay_ms(500);
    PORTB &= ~(1 << PB3); 
    _delay_ms(500);
    }
}

Grüße

Julian

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Julian Utsch schrieb:
> obwohl mein
> Profesor meint, dass prinzipiell keine Grundschaltung nötig wäre.

Der gute Mann meint evtl. nur die Resetschaltung, die man auch mal 
weglassen kann. Der Abblockkondensator (100nF) ist allerdings immer 
nötig für einen stabilen Betrieb des MC.

Zum Problem: Das muss was ganz dummes sein, denn am Programm kann es 
nicht liegen, das sieht alles richtig aus - viel isses ja auch nicht.
Entweder ist der kleine Kerl kaputt, oder nur PB3 ist kaputt. Probier 
mal einen anderen Pin.
Kann eigentlich auch kein falsches Fusen sein, dann würde die LED 
trotzdem blinken, wenn auch mit der falschen Frequenz. Wenn du den Tiny 
programmieren kannst, ist auch ein MC Takt da.

[HildeK (Gast)]

Julian Utsch schrieb:
> Wo könnte mein Fehler liegen?

> Sind irgendwelche Fuses
> standardmäßig "falsch" gesetzt, sodass ich sie anders setzen muss?

Ich kenne zwar den Tiny13 nicht, aber bei dem von mir gerne genommenen 
Tiny25 oder auch beim Mega8 ist per Default der interne Takt auf 1MHz 
eingestellt. Für 8MHz musst man den CLKDIV herausnehmen.
Vielleicht hast du nur nicht lange genug Geduld gehabt und die LED 
blinkt mit 1/8 Hz anstatt mit 1Hz.

[HildeK (Gast)]

Noch ein Tip:
bei Verwendung von _delay_ms() muss man die Compileroptimierung aktiv 
haben.

[Julian U. (julian94)]

Nachtrag:
PB4 ist ebenfalls dauer haft HIGH. Die restlichen Pins waren vorher 
durch die ISP Verbindungen belegt und sind LOW. Auch wenn ich das delay 
weglasse und quasi PB3 auf LOW im Code schalte, bleibt PB3 HIGH.

[Thomas E. (thomase)]

Julian Utsch schrieb:
> Sind irgendwelche Fuses
> standardmäßig "falsch" gesetzt, sodass ich sie anders setzen muss? Nach
> meinen Recherchen ja eigentlich nicht. Ansonsten habe ich alle
> Einstellungen auf Standard gelassen.

Die Fuses sind natürlich richtig gesetzt. Ein Attiny13 läuft per default 
mit 1,2MHz.

Julian Utsch schrieb:
> Anbei noch mein C-Code:

#define F_CPU 8000000L

Damit wird keine Frequenz eingestellt, sondern dem Compiler mitgeteilt, 
mit welcher der Controller läuft! Also Fuses richtig einstellen 
(CLKDIV8), Frequenz richtig angeben.

Die Basisfrequenz eines Attiny13 beträgt 9,6MHz, mit CKDIV8 1,2MHz!

Also ohne Fuse-Änderung:

#define F_CPU 1200000L

oder ganz komfortabel, auch ohne Fuse-Einstellung:

#define F_CPU 9600000L
.
.
#include <avr/power.h>
.
.
int main(void)
{
 clock_prescale_set(1);
.
.
.
}

Dann passen auch die delays. Der Rest deines Programms ist zu einfach, 
um falsch zu sein. Es sei denn, deine Schaltung hat eine Macke oder du 
kompilierst für einen anderen Controller, flasht ein falsches Hex-File 
oder dein Programmer ist Scheisse oder, oder...

Am Programm liegt es jedenfalls nicht. Wenn du meine Ratschläge 
einbaust.

mfg.

[Julian U. (julian94)]

Danke Thomas für den Hinweis mit der Taktrate. Das hatte ich nicht 
gewusst. Bin jetzt auf die 1,2Mhz umgestiegen, aber gleicher Effekt wie 
vorher.
Ich habe eben einen neuen tiny angeschlossen und ihn somit zum ersten 
Mal programmiert. Diesmal ist das Programm noch primitiver. Es soll die 
LED an Pin PB3 ausgeschaltet lassen. Und nach dem erfolgreichen 
programmieren leuchtet die LED wieder. Ich bin ratlos. Warum ist dieser 
Ausgang wieder auf HIGH?
Der Programmer ist eigentlich noch fast neu und kann unmöglich kaputt 
sein.

[Christain (Gast)]

Mach zur Not mal ein paar Fotos vom Aufbau. Vielleicht sieht man ja 
etwas offensichtliches ...

MFG

[Marco G. (grmg2010)]

Kann es sein, dass der PIN Reserviert ist, wie bei anderen uCs die 
JTAG-Pins und erst freigegeben werden muss?

[Thomas E. (thomase)]

Lass mal den ganzen Port blinken:

int main(void)
{
    DDRB = 0x1F;
  
  while(1)
    {
    PORTB = 0x1F;
    _delay_ms(500);
    PORTB = 0; 
    _delay_ms(500);
    }
}

Programmer abziehen!


Marco G. schrieb:
> Kann es sein, dass der PIN Reserviert ist, wie bei anderen uCs die
> JTAG-Pins und erst freigegeben werden muss?

Nein. Der hat nur 8 Pins. Da wäre JTAG etwas viel des Guten.

Das passt schon alles.

@Julian: Du misst auch an Pin 2?
PB3 liegt nicht an Pin 3, sondern an Pin 2. Sowas passiert schnell im 
Eifer des Gefechts. Das Layout ist an der Stelle ein bisschen fies.

mfg.

[Julian U. (julian94)]

@Thomas:
Jetzt hast du mich verwirrt ;) PB3 ist nicht Pin PB3?? Das steht doch 
auch so im Datenblatt, dachte ich zumindest.
Ich hab eben deinen Code getestet. Auch hier gleiches wie vorher. Nur 
Pin PB3 und Pin PB4 leuchten und zwar konstant...

[Thomas E. (thomase)]

Julian Utsch schrieb:
> Jetzt hast du mich verwirrt ;) PB3 ist nicht Pin PB3?? Das steht doch
> auch so im Datenblatt, dachte ich zumindest.

Natürlich ist PB3 an PB3. Nur das ist Pin 2 am Controllergehäuses. Die 
Reihenfolge der Ports ist auf dieser Seite des Controllers PB5, PB3, 
PB4. Aber wenn dich das nicht verwirrt, will ich auch keine Verwirrung 
stiften.

Julian Utsch schrieb:
> Ich hab eben deinen Code getestet. Auch hier gleiches wie vorher. Nur
> Pin PB3 und Pin PB4 leuchten und zwar konstant...

Dann teste mal so:

int main(void)
{
    DDRB = 0x07;
  
  while(1)
    {
    PORTB = 0x07;
    _delay_ms(500);
    PORTB = 0; 
    _delay_ms(500);
    }
}

Also lass die beiden Kandidaten mal raus.

mfg.

[Jonas G. (jstjst)]

Bist du dir sicher das dein Controller richtig programmiert wurde?

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Jonas G. schrieb:
> Bist du dir sicher das dein Controller richtig programmiert wurde?

Der ICE III behauptet das jedenfalls, steht ja im ersten Posting. Aber 
es ist ja möglich, mal ein Verify Lauf auszuführen, um da ganz sicher zu 
sein. Ich möchte jetzt jedenfalls auch mal ein Bildchen vom Aufbau 
sehen, denn das Programm ist ja extrem simpel und richtig. Es muss also, 
wie schon geschrieben, etwas ganz dummes sein, oder die Tinys des TE 
sind alle breit. Auch die Fuses können gar nicht so falsch sein, denn 
der MC lässt sich ja programmieren, also muss der Oszillator zumindest 
laufen. Selbst wenn der Tiny mit seinen originalen 1,2MHz rennt, muss 
die LED blinken.

[Julian U. (julian94)]

Anbei mein Schaltungsaufbau. Die Beschaltung hatte ich ja eingangs schon 
erwähnt. Da fällt mir auch eine Frage ein. Ich habe ja ein Pull-Up am 
Reset Pin und dann eine Reset Leitung zum ICE III. Funktioniert das 
beides zusammen? (grünes Kabel oben links)
Wenn ich heute Abend zuhause bin, kann ich gerne Beschriftungen für die 
Kabel hinzufügen, falls es benötigt wird.

[Karl H. (kbuchegg)]

Julian Utsch schrieb:
> Anbei mein Schaltungsaufbau. Die Beschaltung hatte ich ja eingangs schon
> erwähnt. Da fällt mir auch eine Frage ein. Ich habe ja ein Pull-Up am
> Reset Pin und dann eine Reset Leitung zum ICE III. Funktioniert das
> beides zusammen? (grünes Kabel oben links)

Es ist bei Problemen immer einen gute Idee, zum Testen des Controllers 
den Programmer ganz einfach abzuziehen. Hängt kein Programmer am 
Controller kann er ihn auch nicht beeinflussen.
Aus dem Grund ist eine einfach lösbare Steckverbindung am 
Programmieranschluss immer eine gute Idee.

[Thomas E. (thomase)]

Julian Utsch schrieb:
> Anbei mein Schaltungsaufbau.

Das sieht auch alles gut aus. So langsam bleibt dann aber auch nicht 
mehr viel.

Wird das richtige File geflasht? Das wird beim Anlegen eines Projektes 
NICHT automatisch eingestellt!

mfg.

[Zensiert (Gast)]

Also vor dem Programmieren ist die LED aus?
Und danach, "egal" welches Hex-File geflasht wurde, an?
Was passiert wenn du den µC löschst? Ist die LED dann wieder aus?
D.h. die Ports können grundsätzlich schalten?!

[uwe (Gast)]

In welche Richtung ist die LED denn angeschlossen?
µC -> Anode-Kathode -> GND
µC -> Kathode-Anode -> VCC

[Zensiert (Gast)]

uwe schrieb:
> In welche Richtung ist die LED denn angeschlossen?
> µC -> Anode-Kathode -> GND
> µC -> Kathode-Anode -> VCC

Hm...war auch schon meine Idee, aber dann hätte sie ja trotzdem blinken 
müssen.

[Julian U. (julian94)]

Danke Thomas, du hattest den entscheidenden Hinweis. Es ist mir ja schon 
peinlich, aber das AVR Studio hat ein altes Hexfile benutzt. In der Uni 
benutzen wir Eclipse da funktioniert das ein wenig eleganter. Als ich 
dann mein uC mit dem neuen Hexfile beschrieben habe, blinkte es wie 
gewünscht :)
Für die Zukunft weiß ich in der Hinsicht jetzt Bescheid.
Ich danke euch für eure zahlreiche Hilfe und hoffe ihr seid mir nicht 
sauer wegen so einem dummen Fehler von mir.
LG Julian

[Stefan F. (Gast)]

Unglaublich, wie so triviale Dinge einen aufhalten können.

Ist mir aber auch schon passiert. Ich ärgere und schäme mich dann immer 
eine Weile lang in Grund und Boden. Und dann verfluche ich die Sch**** 
Software, die nicht so klug ist, von alleine das zu tun, was ich von ihr 
erwarte :-)

Ob wir noch echte KI erleben dürfen, bevor wir sterben?