Hi,
ich versuch mich gerade zum ersten Mal einen µC zu programmieren. Dabei
habe ich jetzt ein Problem: Ich erhalte ständig die Meldung "Entering
programming mode.. FAILED!". Das Einstellen der "ISP-Freuqency" geht
noch.
Meine "Ausstattung":
AVR Studio Ver. 4.18.692 (incl. SP1)
WinAVR 20100110
AVR ISP MKII
ATtiny 25
Ich habe den Baustein bereits programmieren können, also Hardware,
Treiber und Co. sollten OK sein.
Ich geh davon aus, dass das letzte Programm welches ich auf dem µC
gespeichert habe den Fehler verursacht. Allerdings kann ICH das nicht
anhand des Code erkennen.
Hier der Code den ich gespeichert hab:
#include <avr/io.h>
#include <stdint.h>
int main(void)
{
uint8_t pins;
pins = 0;
DDRB = 0x02;
pins = PINB;
PORTB = 0x04;
while (1)
{
if( PINB & 0x04 )
PORTB = 0x02;
else
PORTB =0x00;
}
return 0;
}
Könnte mir jemand sagen ob es am Code liegen kann, und wenn ja wie ich
dies beheben kann. An den "Fuses" hab ich nichts geändert.
MfG
Tobias
Also mit einem Programm kann man einen Atmel nicht killen, weil im
Programmiermodus der Resetpin auf Low ist und so das Programm nicht
ausgeführt wird. Wenn du an den Fuses wirklich nichts verstellt hast,
dann überprüfe nocheinmal die Hardware. Die ISP Frequenz kleiner 1/4 der
Taktrate stellen (also kleiner 250k). Was hängt sonst noch an den Pins
des Controllers außer dem ISP Interface? Irgendwo hohe Lasten,
Kapazitäten?
>Ich geh davon aus, dass das letzte Programm welches ich auf dem µC>gespeichert habe den Fehler verursacht.
Nein. Es kann an den Fuses liegen, an der externen Beschaltung des
Controllers, an der Verbindung, an der Programmer-Hardware, der
PC-Hardware oder an der Software. Aber niemals am Code.
Hi,
wow das geht ja schnell. Vielen Dank für die Antowrten. Ich bin zwar
froh, dass der Code nicht schuld ist allerdings hab ich an der Hardware
bewusst nichts verändert.
Die Fuses kann ich nur im Tab "Fuses" ändern,oder? da war ich nicht
drin. Deshalb sollte sich da nichts geänder haben. Allerdings kann ich
die nicht auslesen.
Ich werd mal die Hardware genau unter die Lupe nehemn. Und dann nochmal
schreiben.
MfG
Tobias
Hi,
wie gesagt, dass Hauptproblem ist, dass alles so wie es ist schonmal
funktioniert hat! Ich habe das Programm gespeichert, wollte ei neues
drauf machen, da es nicht funktioniert hat und seit dem geht es nicht
mehr.
Deshalb meine Annahme das es nicht an der Hardware lag, die ich gerade
auch nochmal überprüft habe.
100nF ist drin
kein große Kapazität o.Ä. an den Pins für die Programmierung
Taktrate ist 6,478k
Ich such weiter...
MfG
Tobias
Welche Farbe haben die LED's am MKII? Beide GRÜN? Oder leuchtet/Blinkt
die LED am ISP Anschluss Orange?
Geht das Auslesen der Signatur des Chips noch? Vllt hast du einen
falschen µC eingestellt.
Hi,
beide sind Grün. Wenn ich versuch den µC auszulesen / programieren wird
die eine orange ( alles wie es sein soll ).
Nein Signatur kann ich nicht (mehr) auslesen. Der richtige Chip ist aber
eingestellt!
MfG
Tobias
Hast Du irgendwelche witzigen Sachen angestellt, wie LEDs ohne
Vorwiderstand anschließen oder dergleichen? (Vielleicht hats den
MOSI-Pin beschädigt?)
Ansonsten ALLES weg an Peripherie vom Controller, was noch dran ist.
Dann muss es funktionieren, oder es ist ernsthaft was faul.
Vorerst Danke für die ganzen Antworten, allerdings nervt mich das Teil
jetzt und ich leg es weg bis morgen, ansonsten macht es noch Begegnung
mit nem Hammer.
Nochmal, die Hardware hab ich jetzt 3 mal geprüft. Und mit der hat es
die letzten ca. 10 mal auch funktioniert.
Sollte ich die "Fuses" doch unbeabsichtigt verändert haben, können
dadurch noch andere Probleme entstehen als das, dass der Takt von extern
zugeführt werden muss?
MfG
Tobias
Einfach das Zeug beiseite tun und ne Nacht drüber zu schlafen ist
manchmal wirklich die beste Entscheidung.
>Nochmal, die Hardware...
OK :-)
>Sollte ich die "Fuses" doch unbeabsichtigt verändert haben, können>dadurch noch andere Probleme entstehen als das, dass der Takt von extern>zugeführt werden muss?
Der Fuse-Verstell-GAU ist, den Reset-Pin zum I/O-Pin umzufunktionieren.
Das ist im normalen ISP-Programmiermodus möglich, aber sobald es
geschehen ist, ist der µC nicht mehr ISP-programmierbar und somit die
Aktion nicht wieder rückgängig zu machen. Das geht nur noch im
High-Voltage-Programmiermodus, der nicht von allen Programmern
unterstützt wird.
Der Programmer würde dann aber meckern und die Orange LED würde blinken,
was so viel heißt wie das er den Controller nicht resetten konnte.
Es gibt jetzt noch zwei Fehlerquellen: Du hast andere Hardware an den
ISP Leitungen dran (LED's, widerstände...) oder der Controller hats
zeitliche gesegnet.
Ich hatte das Problem auch schonmal, das es mal ging, mal gings nicht.
Woran es lag, weiß ich bis heute nicht! Setz einfach mal nen anderen
Controller ein zum testen.
Ok, ich werd mich heut mal dran machen den µC auf ner anderen Platine
ohne alles aufzubauen, nur mit dem Anschluß zum ISP.
Also die orange LED leuchtet nur beim Versuch zu Lesen / Programmieren,
somit ist der GAU auszuschließen.
Ich bin Anfänger und hab die gesamte Hardware geliehen. Den Chip
austauschen geht vorerst nicht, da ich keinen weiteren hab.
Also die Schaltung hat an MISO und MOSI noch weitere Komponenten dran.
Werd mich mal versuchen die SMD Bausteine auszulöten um den Chip
"freizulegen".
MfG
Tobias
Kannst du den Strom des AVRs messen? Durch den Stromverbrauch des AVRs
im normalen Betrieb kann man eine Aussage machen ob der Takt noch
vorhanden ist oder er irgendwie verfused ist.
So jegliche "unnötige" externe Beschaltung ist weg.
Die Leds des Programmiergerätes sind immernoch beide grün. Der Fehler
ist immernoch vorhanden.
Ich befürchte langsam das der Chip kaputt ist.
Hab den Strom gemessen, zuerst 350µA (ja µ!) und nach 10 oder 20
sekunden hab ich dann 250µA. Allerdings hab ich ne Vcc von 4,1V.
Da du den 20mA bereich vorgeschlagen hast würde ich behaupten, dass die
Werte nicht gut sind....
Ich denke die 6,** von denen er geredet hat, das ist die ISP Frequenz
und nicht der Takt des AVRs. Aber trotzdem sind 350µA zu wenig. Bei
internen 1MHz benötigt er (@4,1V) 900µA. Und bei 128KHz Taktfrequenz
dürfte er nur 120µA ziehen. Also dürfte etwas mit dem Takt nicht
stimmen.
Ja, 6kHz waren die ISP Frequenz.
Den Takt hab ich selber nicht eingestellt. Wenn ich es richtig weiß war
er von Anfang an auf 128kHz eingestellt.
Das "Erasen" des Bausteins löscht nicht die "Fuses" oder?
Ich denk, es wär nen Versuch wert, irgendwie einen Takt von ~100 kHz
herzustellen und den mal auf Pin CLKI zu geben. Dann (bei angelegtem
externem Takt) das Programmieren mit ~10 kHz ISP-Frequenz nochmal
versuchen.
Ok, vielen Dank für eure Hilfe, allerdings hab ich keine Möglichkeit
einen 100kHz Takt zu erzeugen. Somit muss ich wohl bis Montag warten...
Sobald ich dann weiß woran es lag geb ich bescheid
MfG
Tobias
So, des Rätsels Lösung: Chip liegt im Müll :)
Mein Dozent von dem ich den Chip hab hat bereits bei einigen ATtiny
festgestellt, dass die beim Verbinden mit dem Programmierkabel einen ESD
Schaden bekommen können.
Er hat das Problem dadurch behoben, dass er eine dauerhafte elektrische
Verbindung zwischen der Versorgungsspannung des Chip und der Masse der
Programmierleitung hergestellt hat. Seither hat er keine Probleme mehr.
MfG
Tobias
Hallo,
Anfänger_Tobias schrieb:
> So, des Rätsels Lösung: Chip liegt im Müll :)>> Mein Dozent von dem ich den Chip hab hat bereits bei einigen ATtiny> festgestellt, dass die beim Verbinden mit dem Programmierkabel einen ESD> Schaden bekommen können.
Es ist oft weniger ein ESD Problem als eine erhebliche
Potenzialdifferenz zwischen Programmer-GND, also meist Schutzleiter über
PC-GND->PE.
Netzteile, die keine Verbindung zwischen AVR-GND und PE haben aber z.B.
Entsörkondensatoren auf der Primärseite, die mit GND der Ausgangsseite
verbunden sind.
Da entlädt sich dann der auf rund 120V aufgeladene Kondensator über
einen Eingangspin von AVR oder Programmer, wenn nicht GND zuerst Kontakt
bekommt.
Anwärter simd z.B. kleine Schaltnetzteile (Handynetzteile usw.), die
sich dank 5V eigentlich gut für AVR-Experimente sind.
> Er hat das Problem dadurch behoben, dass er eine dauerhafte elektrische> Verbindung zwischen der Versorgungsspannung des Chip und der Masse der> Programmierleitung hergestellt hat. Seither hat er keine Probleme mehr.
Der einfache und sichere Weg, wenn es weiter keine zuverlässige
GND-Verbindung gibt.
Gruß aus Berlin
Michael
Anfänger_Tobias schrieb:
> Er hat das Problem dadurch behoben, dass er eine dauerhafte elektrische> Verbindung zwischen der Versorgungsspannung des Chip und der Masse der> Programmierleitung hergestellt hat. Seither hat er keine Probleme mehr.
Danke fürs Feedback. Kannst du der Sache noch etwas weiter nachgehen:
Wie genau hat er diese Vebindung gemacht? Man kann ja nicht einfach
einen Draht einlöten, denn das gäbe einen Kurzschluß. Einen paar zig
KOhm Widerstand könnte ich mir an der Stelle vorstellen, ist ein solcher
dort verbaut?
HI,
Ihr habt beide Recht :)
GND Pin des ISP dauerhaft mit GND PIN des Chip verbunden. Um
Ausgleichsströme zu begrenzen ist n Widerstand in der Verbindung. Der
genaue Wert ist nicht so wichtig, er soll nur dauerhafte
Ausgleichsströme begrenzen aber trotzdem Überspannung vermeiden als
irgendwo zwischen 500 und 5000 Ohm.
MfG
Tobias
Hab gerade erst gesehen, dass ich Vcc und GND geschrieben hatte, das ist
natürlich FALSCH!
GND(Programmer) GND(Chip) Verbinden!
Alles weitere hat Michael bereits richtig geschrieben, ich habs als ESD
kurz gefasst, auch wenn es nicht ganz richtig ist.
Meinem Dozent ist es besonders bei Verwendung des Laptop aufgefallen.
Eine weitere einfache Lösung wäre auch alle Pins des ISP Connector bis
auf den GND etwas zu kürzen. Dadurch sollte stets zuerst GND kontaktiert
werden.
MfG
Tobias