Hallo allerseits
Ich habe vor kurzem das stk500 bekommen, und hab gerade damit angefangen
ein wenig was selbst zu programmieren.
Leider will es seit heute früh nichtmehr so wie ich es will. Gestern
Abend habe ich noch ein wenig mit den Taktzahlen gespielt (Quarz
eingesetzt usw...), und die UART Schnittstelle ausprobiert.
Und seit heute früh geht einfach garnixmehr.
Ich wollte einfach nur da weitermachen wo ich Gestern Abend aufgehört
hatte (UART), als aufeinmal kein einziges byte mehr am PC angekommen
ist, und der Controller auch auf kein Paket reagierte (Was den Tag davor
ja noch problemlos funktioniert hatte).
Dann dachte ich dass vielleicht die Taktzahl nicht stimmt, also habe ich
alles überprüft (Jumper/Fuses) aber das war alles i.O.
Und ausserdem müsste ja bei falsche Taktzahl wenigstens irgend ein
Paket ankommen (auch wenn es natürlich das falsche ist).
Das kam mir alles schon sehr merkwürdig vor, und ich hab dann versucht
wenigstens wieder die LEDs direkt auf dem Board anzusprechen. Aber
nichteinmal das funktionierte mehr.
Auch das Beispielprogramm vom Handbuch wollte nichtmehr.
Es ist mir klar das irgendwo der Wurm drin ist. Ich habe sogar den
Verdacht dass er ganz offensichtlich ist aber ich komme nicht drauf.
Das hab ich auch schon in Betracht gezogen (also dass der µC kaputt
ist). Aber es war nie mehr als 8mhz, und ich hab nur atmega8515 und
atmega16 benutzt
sogar n nigelnagelneuen atmega16 hab ich eingesetzt... Das Problem
besteht weiterhin
Gut wenn es mit nem neuen µC auch nicht klappt liegts woanders drann.
Aber nur weil du maximal 8MHz verwendet hast, heißt das nicht dass du
den µC nicht übertakten kannst. Dazu musst du nur auf Low-Frequence
einstellen und High-Frequence dranhängen.
Robin Tönniges wrote:
> Aber nur weil du maximal 8MHz verwendet hast, heißt das nicht dass du> den µC nicht übertakten kannst. Dazu musst du nur auf Low-Frequence> einstellen und High-Frequence dranhängen.
Aber davon geht ein AVR mit Sicherheit nicht kaputt.
Hallo,
@Robin Tönniges: Quark... Schon deshalb, weil der AVR auf dem STK500
immer per ext. Clock getaktet wird. Das spielt in allen Fuse-Varianten,
egal ob ext. Crystal, Resonator oder Clock. Bei intern geht sowieso
nichts zu übertakten.
@Jonas: Programmieren, Verify, Flash lesen, Fuses lesen usw. geht?
Signatur wird richtig gelesen?
Auch nur ein AVR auf das Board gesteckt?
Gruß aus Berlin
Michael
Schätze mal, das Board ist per statischer Aufladung gestorben.
Könntest probieren, einen manuellen Firmwareupgrade zu machen, ansonsten
heißt es: µC des Boards tauschen.
"Programmieren, Verify, Flash lesen, Fuses lesen usw. geht?"
jap funktioniert fehlerlos
"Signatur wird richtig gelesen?"
exakt
"Auch nur ein AVR auf das Board gesteckt?"
ja
danke schonmal für die hilfe
Jonas wrote:
> ...> sogar n nigelnagelneuen atmega16 hab ich eingesetzt... Das Problem> besteht weiterhin
Hi
und den Atmega16 (nicht der gleiche wie Atmega8515!) auch in den
richtigen Sockel verwendet?
"und den Atmega16 (nicht der gleiche wie Atmega8515!) auch in den
richtigen Sockel verwendet?"
Ich hab im Handbuch gelesen...
Mir ist das zugegebenermaßen am ersten Tag wie ich das stk500 bekommen
hab mal passiert aber seitdem nichtmehr.
"Könntest probieren, einen manuellen Firmwareupgrade zu machen"
wo ist der unterschied zum normalen upgrade? (das ich gerade eben
gemacht hab aber nix gebracht hat)
Ferndiagnose :
Problemquelle 1 :
STK500 defekt
Problemquelle 2 :
Anwender-µC defekt
Problemquelle 3 :
Anwenderprogramm nicht o.k.
Problemquelle 4 :
Anwenderschaltung nicht o.k.
Zu 1 :
Nach Deiner Aussage soll das Flashen, Verify und Signaturauslesen
fehlerfrei (d.h. keine Fehlermeldung der Programmiersoftware bzw.
richtige Signaturbytes) funktionieren. Hieraus würde ich erst mal
schließen, dass das STK500 funktioniert.
Zu 2 :
Da Du flashen kannst, würde ich eine kleine Bsp.-Anwendung programmieren
(z.B. LED-Blinken) und dies auf dem STK500 ohne irgendwelche welche
Zusatzhardware testen. Wenn die LED entspechend irgendwelcher Vorgaben
blinkt etc. scheint auch der µC o.k. zu sein.
Zu 3 :
Kenn Dein Programm zwar nicht, meist liegt aber dort der Fehler.
Aussagen wie "gestern liefs aber noch" bzw. "ich habe doch eine kleine
Änderung vorgenommen" oder besonders schlimm "ich habe nichts
geändert!!!" stehe ich sehr kritisch gegenüber !!!!
Zu 4 :
Prüfe die Spannungspfade und die Verbindung, es könnte ja ein
Wackelkontakt irgendwo sein.
Zeig mal bitte deinen Aufbau als Foto, mit dem du erwartest, dass alle
LEDs angehen müssten und das entsprechende Programm dazu.
Vielleicht hast du dich doch verjumpert, vertippt, o.ä. und siehst den
Wald vor lauter Bäumen nicht.
Ist deine Spannungsversorgung ok?
Unterhalb des Boards eventuell leitende Verunreinigungen?
Was sagen die Status-LEDs nach dem Einschalten des Boards?
Zieh mal alle ungenutzten Stecker ab, wenn du das Programm testest.
Arbeiten die I/Os korrekt? Mit Multimeter/Oszi direkt am Controller
messen.
Was anderes fällt mir jetzt auch nicht mehr ein - aber bevor wir
aufgeben können wir auch noch was im Dunkeln stochern...
Mit dem Code würde ich testen:
1
ldi r16, 0xFF
2
out DDRD, r16
3
4
ldi r16, 0b10101010
5
out PORTD, r16
6
7
stop:
8
rjmp stop
Port D natürlich entsprechend mit den LEDs verbinden.
Das ist mir soo peinlich. Es funktioniert wieder.
Ich gebs ja zu: Ich bin bezüglich diesen Themas ein absoluter Neuling.
Aber ich kann es mir immer noch nicht erklären:
Das Programm war 100 Prozentig nicht Fehlerhaft. Es war sogar das
Test-Programm hinten im Handbuch vom STK500. Ich bin das 100mal
durchgegangen und es war kein Fehler drin.
Das schwöre ich auf mein ganzes Computerequipment!
Vor einer Stunde hab ichs nochmal ausprobiert. Es ging nicht.
Alles was ich seitdem getan hab war folgendes (Chronologisch sortiert):
- STK500 ausgeschaltet
- Mit dem Multimeter alle Taster und LEDs überprüft
- Stromversorgung ausgesteckt
- RS232 ausgesteckt und wieder eingesteckt
- Nach ner Zeit Stromversorgung wieder angesteckt (Ich war was anderes
am basteln)
- Neues Projekt im AVR Studio gestartet
- Code von Kai eingesetzt
- STK500 eingeschaltet
- Port D mit den LEDs verbunden
- µC geflasht
- Verwundert auf das funktionierende STK500 geschaut
>Ist deine Spannungsversorgung ok?
Ja ich habe gerade noch damit was anderees gemacht.
>Unterhalb des Boards eventuell leitende Verunreinigungen?
Hab ich auch schon überprüft.
>Was sagen die Status-LEDs nach dem Einschalten des Boards?
War alles im grünen Bereich.
>Zieh mal alle ungenutzten Stecker ab, wenn du das Programm testest.
War schon alles auf Sparflamme.
>Arbeiten die I/Os korrekt? Mit Multimeter/Oszi direkt am Controller>messen.
Hab ich auch gemacht (s.o.)
Eigentlich sollte ich ja froh sein dass es jetzt funktioniert, aber ich
würde doch zu gern wissen was der Fehler war.
Warscheinlich war ich der Fehler. seufz
Danke und entschuldigt nochmals
>Danke und entschuldigt nochmals
Kein Problem :)
Versuch mal deinen eigentlichen Code wieder ans Laufen zu kriegen - kann
sein, dass du da nochmal über irgendwas stolperst. Hauptsache du hast
jetzt eine funktionierende Referenz, mit der du abgleichen kannst.
Schönen Sonntag noch
Kai
Hi,
so ein Problem in der Art hatte ich auch. Bloß bei mir ging gar nix mehr
mit dem STK500. Ich hab schon das schlimmste befürchtet das der uC im
sterben lag. Aber dem war nicht so nach verschiedenen, gescheiterten
Tests hab ich das STK500 an meinem alten Laptop angeschlossen... und
siehe da, da lief es wunderbar.
Mögliche Schlussfolgerung: COM-Port des Rechners defekt. Also
Nullmodemkabel an PC und Laptop angeschlossen und mit Putty ein V.24
Terminal geöffnet. Mhhh Kommunikation zwischen beiden Rechnern
funktioniert.
Tja was bleibt da noch übrig...?? OK mein XP-Rechner hat seit dem
Vorfall ein paar automatische Systemupdates durchgeführt. Die Comtreiber
wurden dabei aktualisiert. Die Einstellung an sich spielt ja keine
Rolle, da das AVR-Studio sich den Comport ja passend zurechtlegt.
Und jetzt kommts... Ich hab das Treiberupdate rückgängig gemacht und
siehe da mein STK500 läuft wieder prima ;)
Vielen lieben Dank an Redmond kann ich da nur sagen. Saubere Arbeit
Microsoft. Bis alles wieder lief, sind sicherlich 10 Stunden frust und 2
Liter Kaffee den Abgrund runter. Naja soll nur mal nen Tipp sein, falls
euer STK streikt. Da ich eh aus der Linuxschiene komme werde ich in
Zukunft das alles auf Linux umstricken. Da sollte mir dann sowas nicht
mehr passieren..
Liebe Grüße
Lars
Wobei Lustigerweise das Codebeispiel von Atmel fehlerhaft ist.
Genauso muß man bei der Softwareroutine von Atmel bez. TWI einen timeout
dazubauen da die Originalroutine ewig auf ein ACK wartet.
Aus auch diesem Grund schreibe ich mir meine Software selbst.
Hast du schonmal ALLE Spannungen überprüft? Ich hab mal mein halbes
Board zerlegt um nen Fehler zu suchen und dann hat sich rausgestellt
dass sich die V_Target zurückgesetzt hat, warum auch immer. Musste sie
einfach nur neu einstellen und die Sache war erledigt.
Immerhin hab ich mich dadurch mal ausgiebig mit dem Board
auseinandergesetzt und hab den Schaltplan bekommen den ich gerne
weiterreichen kann falls Bedarf besteht.
