Hallo, bin neu hier im Forum und daher möchte ich kurz einige Sätze zu meiner Person schreiben, da ich bzgl. MCs und Elektrotechnik blutiger Anfänger bin: Bringe zwar einige Erfahrungen aus Programmierung in C, Assembler und einigen anderen Programmiersprachen mit, allerdings bezogen sich bis vor kurzem diese Kenntnisse ausschließlich auf Entwicklung von einfacher Anwendungssoftware. Hinsichtlich Elektrotechnik und vor allen Dingen der Hardware rund um MCs habe ich ein äußerst lückenhaftes Grundwissen und tue mich mit meinem neuen Hobby der MC-Programmierung noch etwas schwer. Nachdem ich zwei Bücher (Schmitt, Trampert)gelesen habe, bin ich vor etwa zwei Wochen auf dieses Forum gestoßen, welches ich abendlich seither fleißig studiert habe. An dieser Stelle ein Lob an Euch, ist wirklich eine tolle, sehr informative Internetpräsenz inkl. Forum. Einige meiner Fragen konnte ich bereits durch lesen beantworten und auch das Tutorial hat mir bei meinen ersten Schritten sehr geholfen. Wirklich klasse. Allerdings komme ich seit einigen Tagen trotz Forum nicht weiter. An dieser Stelle möchte ich bereits jetzt um Nachsicht bitten, falls es sich in Euer Augen um eine triviale Sache handeln mag oder die Dinge an anderer Stelle in anderer Form behandelt wurden (aus Foren im Bereich Maschinenbau ist mir die Problematik mit Anfängern durchaus geläufig). Aber zum Problem: Besitze ein STK500 und programmiere derzeit die Prozessoren vom Typ "ATMEGA16 16PC". Bei einfacheren Programmen bei welchen ich z.B. LEDs angesteuert habe, hat bisher alles prima funktioniert. Nun habe ich mir ein kleines Programm für ein kleines Steuergerät geschrieben, mit welchem ich über den prozessorinternen AD-Wandler eine Spannung (0 bis 5V) messe. Diesen Istwert vergleiche ich mit einem Sollwert. Entsprechend des Istwertes soll ein Pin am PortC bestromt werden um einen Transistor anzusteuern (oder nicht). Das Programm hat beim Debuggen und der Simulation einwandfrei funktioniert. So weit so gut. Was seltsamerweise jetzt nicht mehr klappt ist das flashen des ATMEGA16. Wenn ich versuche zu flashen erscheint ein "ISP-Mode Error". (Alle Meldung OK, bis auf: PROGRAMMING FLASH.. Failed!) Da ich den Prozessor mit meinen anderen Programmen beschreiben kann und ich schon andere Prozessoren verwendet habe, vermute ich ja, daß ich bei der Konfiguration etwas geändert werden muß, sobald ich den AD-Wandler verwende. Hat jemand vielleicht einen Tipp für mich woran das liegen könnte und worauf bei der Konfiguration zu achten ist? Ich weiß im Moment nicht mal wo ich ansetzen muß, da viele Sachen für mich noch böhmische Dörfer sind. Im Voraus vielen Dank. Nachfolgend mein Programm: .INCLUDE "m16def.inc" .DEF adhb = r18 .DEF sollwert = r19 .DEF ausgang = r20 .CSEG rjmp start .org $10 start: ;Portkonfiguration ldi r16, 0x00 out DDRB, r16 out DDRA, r16 ldi r16,0xFF out DDRC, R16 ; Konfiguaration AD-Wandlung an Port A (über Steuerbytes ADMUX und ADCSR) ldi r16, 0b00100000 out ADMUX,r16 ; Referenzspannung extern an Pin AREF, Ergebnis linksbündig Highbyte, Messung an PIN ADC0 ldi r16, 0b11000101 out ADCSR, r16 ; Modus single Conversion mit Taktteiler 32 ;Sollspannung einlesen: ldi sollwert,0b00000000 in sollwert, PINB haupt: ;AD-Wandlung sbic ADCSR, ADSC rjmp haupt ;Vergleich Istspannung mit Sollspannung in adhb,ADCH cp adhb, sollwert brsh keinstrom cp adhb, sollwert brlo strom rjmp weiter keinstrom : ldi ausgang, 0b00000000 out PORTC, ausgang rjmp weiter strom: ldi ausgang, 0b10000000 out PORTC, ausgang rjmp weiter weiter: sbi ADCSR,ADSC rjmp haupt .EXIT
Hallo, das Programm ist dem Programmer sowas von egal solange das Fileformat stimmt und der Prozessor der eingestellte ist. Prozessor im richtigen Sockel? Nur ein Prozessor gesteckt? ISP-Clock passt (max. 1/4 des CPU-Taktes)? ISP-Kabel richtig gesteckt? Gruß aus Berlin Michael
Hallo, vielen Dank für Deine Antwort, es wäre schön wenn es daran liegen würde. Ich schrieb ja schon oben, daß ich den Prozessor programmieren kann. Bedeutet: ich spiele z.B. ein LED-Programm auf und ich kann programmieren. Klappt alles einwandfrei. Das STK500 fasse ich nicht an, sondern wechsel nur im AVR-Studio mein Programm und es funktioniert nicht. Wechsel ich wieder das Programm auf z.B. das LED-Programm kann ich programmieren, ohne auch nur etwas am Setup des STK500 geändert zu haben, noch den Prozessor berührt zu haben. Um die Fragen zu beantworten: -Sockel ist der 3100A3. Prozessor ist richtig eingesetzt (Markierung) -es ist auch nur ein Prozessor gesteckt -ISP-Clock ist auf 57,6 kHz eingestellt -ISP-Kabel ist mit von ISP6PIN mit SPROG3 (unverdreht) verbunden. Grüße Sven P.S. Was hat es eigentlich mit der ISP-Clock genau auf sich?
Habe das Programm jetzt Stück für Stück neu geschrieben und nach jeder Zeile auf den ATmega16 programmiert. Funktioniert alles bis ich die Zeile inkl Sprungziel schreibe. brsh keinstrom :keinstrom Woran kann das liegen? Mir ist auch noch aufgefallen, daß die Signatur nicht passt 'Signature does not match selected device'.
>Habe das Programm jetzt Stück für Stück neu geschrieben und nach jeder >Zeile auf den ATmega16 programmiert. > >Funktioniert alles bis ich die Zeile inkl Sprungziel schreibe. > > brsh keinstrom >:keinstrom Ich geh mal davon aus, dass Du hier niemanden veräppeln willst. Die interessante Frage ist jetzt, was passiert, wenn Du das 'brsh' testweise --> an einer anderen Stelle <-- einfügst? Wenn das Programmieren dann funktioniert, ist dies wohl als Indiz für einen physikalischen Defekt der betreffenden Flash-Speicherzelle zu werten. Vielleicht im Zusammenhang mit der Eigenschaft von Flashmemory, nur eine begrenzte Zahl von Schreibzyklen (Größenordnung 10000) mitzumachen? Wenn das Programmieren dann auch NICHT funktioniert, wäre das ein sehr sehr SEHR seltsamer Fehler, der eigentlich gar nicht existieren kann :-) Einen Grund dafür gäbe es allerdings doch - wenn auch eher theoretisch. Wenn das zur 'brsh'-Instruktion gehörende Bitmuster sehr viele Einsen oder Nullen beinhaltet, braucht das Programmieren entsprechend viel Strom - vielleicht so viel, dass Deine Versorgungsspannung auf einen ungenügenden Wert einbricht.
Hallo, nein, nein. Mir ist das wirklich ernst, da ich hier wirklich am Verzweifeln bin und schon das STK500 als defekt in Verdacht habe. Jedenfalls schon mal vielen Dank für Deine Antwort AVRFan, ich glaube das ging schon mal in eine richtige Richtung. Nachdem ich diese Tipps beherzigt habe scheint in der Tat so, daß es mit dem Befehl 'brsh' nichts zu tun hat, sondern mit dem 17.Befehl in diesem oder in einem anderen Programm. Ist das Programm kürzer (so wie meine anderen bisher getesteten Programme), dann gibt es keine Probleme. Sobald das Programm eine Länge von 17 Befehlen oder mehr aufweist, tritt der Fehler auf. Im Rahmen des Experimentierens habe ich dann mal eine serielle High Voltage Programmierung durchgeführt. Seltsamerweise tritt hier keine Fehlermeldung bei der Programmierung auf. Diese scheint daher auf den ersten Blick erfolgreich durchgeführt worden sein, was dem aber nicht so ist. Über die Funktion 'Verify Flash' im Bereich Auto läßt sich nach der seriellen HV-Programmierung folgende Fehlermeldung generieren: Warning: Flash Byte Adress 0x0000 is 0xff (should be 0x0F).. Failed! Ich habe solch eine Fehlermeldung als Bildschirmausdruck als Dateianhang beigefügt. Daraufhin habe ich den Flash-Speicher ausgelesen und überprüft was tatsächlich auf den Speicher geladen wurde. Siehe da, die Programmierung ist unvollständig. Die Befehle des Programmes mit den Adressen > 18 wurden zwar geladen, aber alles was vor (einschließlich) des 17. Befehls steht, d.h. der Anfang des Programmes, fehlt. Wie geschrieben, das passiert bei der seriellen High Voltage Programmierung. Über ISP, läßt es sich erst gar nicht programmieren. Erst wenn das Programm Befehle <17 hat, dann funktionieren beide Programmierungen einwandfrei. Daraufhin habe ich mir gedacht, wenn es denn an einem zerschossenen bit oder Byte liegt, verändere ich die Adressierung des Programmbereiches (hoffe diese Logik macht grundsätzlich Sinn) und habe am Programmanfang die Direktive .org$10 gegen die Direktive .org$90 getauscht. Ergebnis ist das gleiche nur die Fehlermeldung hat sich dagingehend geändert, daß jetzt 'Flash Byte Adress 0x0120...' ausgegeben wird. Was mich noch weiter wundert ist, ich habe 3 Prozessoren vom Typ ATmega16, die ich zeitgleich vor etwa einer Woche als Neuware gekauft habe. Die Dinger habe ich bestimmt nicht mehr als 20 mal beschrieben (mittlerweile zwar mehrfach, aber weit unter 1000). Das Problem taucht bei allen meinen drei Prozessoren auf. Insofern müßte es ja ein riesiger Zufall sein, daß alle drei Prozessoren unter dem gleichen Fehler leiden. Zur Stromversorgung. Ich habe eine Labornetzteil Voltcraft 1405Pro (u.a. 0 bis 40V bei 5A). Daran sollte es eigentlich nicht liegen - oder irre ich mich? Programmieren tue ich bei 12,2V. Ansonsten was hat es zu bedeuten - oder in welchem Zusammenhang könnte es stehen - daß wie bereits in meinen vorangehenden Beitrag aufgeführt, die Signatur nicht passt? Weiterhin vielen Dank für Eure Hilfe.
Hab jetzt einen nagelneuen ATmega8 eingesetzt und wollte die Signatur überprüfen. Passt auch nicht. 'Signature does not match selected device'. Das kann doch nicht sein!?! ISt das Board vielleicht doch kaputt? Ich möchte jetzt den Atmega8 nicht einfach mal ins blaue programmieren bevor ich nicht weiß was los ist... Jemand noch eine Idee woran so etwas überhaupt liegen könnte?
>ISt das Board vielleicht doch kaputt?
Meine vorsichtige Meinung: Die Symptome deuten leider darauf hin.
Defekte Controller kann man mittlerweile ausschließen. Hmm, da ist
guter Rat teuer. Ich würde alle Kabel und Controller vom Board
abziehen, es zuerst einer gründlichen Sichtprüfung (nah unter einer
Lampe, damit man auch was erkennen kann) unterziehen und danach mit
einem Pinsel, und zwar einem von der festeren Sorte, d. h. keinen
Staubpinsel. Über zwei nebeneinandergelegten, leeren DIN-A4-Seiten,
damit man hört, wenn was fällt und es anschließend findet. Alle Ecken
und Winkel penibel "auskehren". Sollte sich ein Lötzinnkrümelchen oder
ein kurzes Drahtstück irgendwohin verirrt haben und dort was
kurzschließen, ist dies vielleicht die Rettung für Dein Board. Eine
weiterer Test bestünde darin, zu versuchen, ein Firmware-Update
durchzuführen (geht wahrscheinlich nur, wenn das Board nicht schon auf
dem neuesten Stand ist).
Maue Tipps, ich weiß, sorry... :-|
Wenn du in deinem AVR Studio mal im Menü Debug / Select Platform & Device nachschaust, erscheint dort als Device der Mega 16? Das AD-Wandler-Programm muss natürlich geladen sein. Wenn nicht, wäre das die Erklärung, warum die Signatur nicht passt. Außerdem könnte dein Code für einen (falsch ausgewählten) kleineren AVR zu lang sein und seltsame Fehlermeldungen provozieren. Grüße, Peter
Ertsmal danke für Eure Antworten. Das Problem ist leider immer noch da :-( Äußerlich sind kein Defekte am Board erkennbar. Auch wenn ich Lötkrümel ausgeschlossen habe, da ich das Board erst vier Wochen habe und sehr sorgsam damit umgegangen bin und die Lötarbeiten an ganz anderer Stelle stattfinden, habe ich den Rat befolgt. Es hat keine Änderungen bewirkt. Das neuste Update ist auf dem Board aufgespielt, ebenso wie die neuste mir bekannte Version vom AVR-Studio (SP2 build 571) ist auf dem Rechner drauf. Zu: Menü Debug / Select Platform & Device ATmega16 ist eingestellt. So wie die Sache jetzt ausschaut werde ich gleich mal zum Bekannten mit meinem STK500 fahren und ihn mal drüber schauen lassen ggf. mir mal seins ausleihen bevor ich mir ein neues kaufe. Werde weiter berichten.
Also es sieht so aus, als ob mein Board kaputt ist :-( Werde es umtauschen. Beim Bekannten geht es auch nicht. Mit seinem Board klappt aber alles einwandfrei so wie es soll. Trotzdem vielen, vielen Dank für Eure Tipps und Unterstützung.
So was Doofes, das tut mir leid für Dich. Hier noch ein Link zu einer (englischsprachigen) "STK500-Reparaturanleitung", deren Inhalt ich mir jedoch nicht angesehen hab: http://www.build-a-bot.com/STK500//fixstk500.zip Jetzt musst Du nur noch den einen alles entscheidenden hilfreichen Hinweis darin finden - falls existent... ;-) Außerdem gibt es auch einen Schaltplan des STK500: http://www.build-a-bot.com/STK500//STK500_Schematics.zip Und zu guter Letzt noch eine deutsche Übersetzung des STK500-Handbuchs: http://home.arcor.de/matrixman/STK500-HW-Beschreibung.pdf Vielleicht ist etwas davon ja in irgendeiner Form für Dich (oder Deinen Bekannten) nützlich.
Danke für die Anleitungen. Vielleicht werde ich sie irgendwann mal benötigen bzw. für andere möglicherweise jetzt schon hilfreich. Hab jetzt ein neues STK500 und es klappt alles perfekt. Euch ein schönes Wochenende und nochmals danke für diese tolle und schnelle Unterstützung.
Gerne, und Dir gleichfalls ein nice WE sowie allzeit funktionierendes neues STK500 :-)
:-) Bevor ich ein neues Thema aufmache, vielleicht nochmal eine Frage zu meinem Programm, da es nicht so funktioniert wie ich möchte. (wenn ich ein neues Thema aufmachen soll, kein Thema) Es geht um den Anschluss AVCC und AGND. Laut Datenblatt vom ATmega16 soll AVCC an VCC und AGND an GND angeschlossen werden. Zur Rauschunterdrückung ist ein Beispielschaltung mit einer Spule und einem Kondensator für AVCC angegeben. Sie ist aber nicht zwingend notwendig, sondern Anschluß an VCC sollte auch direkt funktionieren und für eine 8bit-Auflösung ausreichend sein. Da ich im Moment nur einen passenden 100nF Kondensator habe (Spule wird noch gekauft), habe ich AVCC direkt an VCC angeschlossen. Es geht ja im Moment auch mehr um die Funktion des Programmes. Das Ergebnis ist äußerst merkwürdig. Mein Ausgabeport (PortC) wird permanent mit folgender Bitbelegung 11110111 belegt. Nach längerem hin und her habe ich dann mal mein Programm, unten stehend genannt, abgewandelt. Ohne AD-Wandlung und den PortC als Ausgabeport von Eingabe-PortB programmiert. Es ändert sich nichts. PortC ist immer noch noch mit 11110111 permanent belegt. Entferne ich den Anschluß zu AVCC, d.h. AVCC ist überhaupt nicht angeschlossen und hängt frei, dann klappt das nachstehende Programm prima und PortC gibt das aus was ich über PortB binär eingebe. Woran könnte das liegen? .INCLUDE "m16def.inc" .DEF akku = r16 .DEF toleranz = r17 .DEF spannunghb = r18 .DEF sollwert = r19 .DEF ausgang = r20 .CSEG rjmp start .org $10 start: ; Einstellung der Ports ldi r16, 0x00 out DDRB, r16 ldi r16,0xFF ; out DDRC, r16 ; out PORTB, r16 ldi akku, 0b00000000 out PORTB, akku out PORTC, akku schleife: ldi sollwert,0b00000000 in sollwert, PINB ldi toleranz, 0b00000001 out PORTC, sollwert rjmp schleife .Exit
Schon mal vielen Dank. JTAG war aktiviert wobei das doch nur die Pins 24 bis 27 betrifft?! Oder irre ich mich? Muß jetzt gleich weg, daher konnte ich mich noch nicht ausreichend beschäftigen allerdings das Ergebnis gefällt mir immer noch nicht. Die Pins lassen sich an PortC über PortB schalten. Allerdings liegt die Spannung bei etwa 3V im neutralen Zustand an PortC. Lege ich den entspprechenden einen Pin bei B auf Masse fällt C auf 0V ab. Gebe ich Strom auf B, geht C auf 5V hoch. Sobald gar nichts drafu liegt ist es 3V. Muß nochmal schauen.
>das Ergebnis gefällt mir immer noch nicht. Es ist allerdings logisch. >1 ldi r16, 0x00 >2 out DDRB, r16 >3 ldi r16,0xFF ; >4 out DDRC, r16 ; >5 out PORTB, r16 >6 ldi akku, 0b00000000 >7 out PORTB, akku >8 out PORTC, akku >Die Pins lassen sich an PortC über PortB schalten. Klar, Du liest ja PINB in 'sollwert' ein und gibst 'sollwert' gleich danach auf PORTC (durch Zeile 3 und 4 als Ausgang konfiguriert) aus. Die Zeile "ldi sollwert,0b00000000" ist übrigens obsolet. >Allerdings liegt die >Spannung bei etwa 3V im neutralen Zustand an PortC. Ja, weil Port B vor sich hin floatet. Alle Pins sind ja als Eingänge ohne aktivierte Pullups konfiguriert. Die Zeilen 1, 2, 6, 7 sorgen dafür (und 5 hat überhaupt keine Wirkung). DDRB = 00000000 und PORTB = 00000000. Messen könntest Du das Floaten an Port B niemals - sobald Du ein Messgerät zwischen einen Pin und GND oder VCC klemmst, ist es damit nämlich sofort vorbei, weil das Messgerät dann durch seinen Innenwiderstand den Pegel festlegt. Aber an Port C ist ebendieses Floaten messbar, weil Port B ja dann weiterhin offen ist. Das ist, was Du misst; die angezeigten "3 V" ist der zeitliche Mittelwert aus ständig unregelmäßig wechselnden L- und H-Pegeln. Der "Fehlerbehebung" besteht natürlich darin, an Port B die Pullups einzuschalten, damit sie die Eingänge, an denen nichts angeschlossen ist, "schwach" (aber sicher) auf H-Pegel ziehen. >Lege ich den >entspprechenden einen Pin bei B auf Masse fällt C auf 0V ab. Gebe ich >Strom auf B, geht C auf 5V hoch. Sobald gar nichts drafu liegt ist es 3V. Jetzt weißt Du, wieso.
Herzlichen Dank. Das hat mir sehr geholfen, insbesondere die Erklärung was passiert wenn keine Pull-Up-Widerstände eingeschaltet sind. Das war mir bis dato noch unklar. Bislang habe ich es einfach hingenommen, daß in solchen Fällen diese aktiviert gehören, sofern kein externer Widerstand angebracht wird (wenn ich das richtig verstanden habe). Mit ein wenig Abstand ist mir auch klar, warum mein Programm nicht wie geünscht funktionieren konnte, da ich die Pullups gleich mit dem übernächsten Befehl wieder deaktiviert habe (ist doch richtig!?). War im festen Glauben, daß sie aktiviert gewesen sind. Unter Strich war ich in der Situation einfach etwas überfordert da der ganze Stoff inhaltlich noch nicht fest genung sitzt, und es Freitag schnell gehen mußte (zu schnell) weil ich das Problem nicht mit ins Wochenende nehmen wollte. Einmal mehr der Beweis, daß Eile zur Unachtsamkeit verleitet und in der Ruhe die Kraft liegt. Hoffe, daß ich beim nächsten Mal von meiner Seite durchdachtere Fragen stelle. Wie dem auch sei, ich habe viel dazugelernt und dafür ein dickes dankeschön ...und für Eure Geduld mit Anfängerproblemen :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.