Hallo, ich muss gestehen ich hab von AVR programmierung keine Ahnung. Aber die Umsetztung einer Bauanleitung aus dem Netz (DMX Dimmer von digitalenlightenment.de) zwingt mich dazu zwei AVR´s zu programmieren. Oder besser ein fertiges Programm richtig zu übertragen. Nun habe ich folgendes Problem: Die Bauanleitung schlägt TwinAVR vor in zusammenhang mit einer SP12 Hardware. (Direkte Verbindung der LPT mit der Schaltung über 2 Widerstände und 5 Drähte) Ich habe mir also TwinAVR herunter geladen und die Hardware gebaut. Aber mit TwinAVR bekommen ich keine Verbindung zum AVR. Eine Programmierung ist nicht möglich. Egal was ich mache, ich bekomme immer die Fehlermeldung "Programm enable Sequence not successfull..." Nun hab ich es mit Pony-Prog und einer etwas anderen Hardware versucht. Wie es scheint werden Daten übertragen, aber die Schaltung gibt keinen Mux von sich. Mein Verdacht ist nun, dass Pony Prog die Daten in einer anderen Weise überträgt wie TwinAVR... Kann das sein? Und hat vielleicht jemand einen Tip wie ich es mit TwinAVR doch noch hinbekommen könnte? Muss ich bei TwinAVR auch den Bausteintyp auswählen? Hab noch nichts dergleichen gefunden. Vielen Dank und Grüße Stefan
P.S.: Der Port-Treiber für NT-Systeme (Win-XP in meinem Fall) ist installiert.
1/ Hast du einen Schaltplan zu Hand, den man kontrollieren könnte? Besonders wie das "Targetboard", d.h. wo der AVR drauf sitzt, aufgebaut ist. Das Targetboart wird mit eigener Spannung versorgt? 2/ Hast du das Programmieren bereits auf einen anderen Rechner versucht? Bei manchen LPT? COM? Schnittstellen insbesondere an Laptops sind die Pegel OK für den eigentlichen Zweck aber untergrenzwertig für Exotenanwendungen wie AVR Programmieren.
Angehängte Dateien:
-
Dimmer_Schematic.jpg
710 KB
hey danke für die schnelle Antwort... einen Schaltplan habe ich natürlich. Das Targetboard hat eine eigene Stromversorgung. So weit hatte ich mich dann in die Problematik schon eingelesen :-) Ich habe das Flashen auch bereits auf einem anderen Rechner versucht. Dieser hat noch Win98 und somit ist kein Porttreiber von Nöten. Aber auch da hat es nicht geklappt. Nun zum Schaltplan... Wärend der Programmierung ist nur der AVR aufgesteckt. Alle anderen "Mehrbeiner" sind runter. Was mir ein bischen zu denken gibt ist der, laut Schaltplan, negierte Reseteingang... TwinAVR kann nach der programmierung den Eingang negieren. PonyProg scheinbar nicht. Das sind so meine Gedanken zu der Sache. Schaltplan hängt wie gesagt an. Vielleicht fällt dir ja was ein. Wäre super!!!
stefan wrote: > Was mir ein bischen zu denken gibt ist der, laut Schaltplan, negierte > Reseteingang... Das ist ein gutes Bauchgefühl von dir. Beim ISP Programmieren muss der ISP-Programmieradapter den Reset bedienen können, weil im Reset-Zustand programmiert wird! Bei deinem Schaltplan ist das nicht vorgesehen. Als einfacher Hack (#) könntest du an die Leitung zwischen dem /RESET des Resetcontrollers TL7705ACP und dem AVR die /RESET Leitung vom ISP-Programmieradapter anschliessen. TL7705ACP /RESET -------------+------------ /RESET AVR | | "RESET" vom ISP-Programmieradapter Skizze wie es z.B. im AVR-Tutorial aussieht http://www.mikrocontroller.net/articles/Bild:Avr-schaltplan-1.gif (aus http://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment ) # ADD: Checke vorher im Datenblatt des TL7705ACP, ob der Probleme hat, wenn der /RESET Ausgang eine Fremdspannung oder GND sieht. Checke ob der Ausgang /RESET des TL7705ACP dem ISP-Programmer bzw. der PC-Schnittstelle Probleme mit zu grossen Stromen macht.
So wie ich es im Datenblatt sehe, kann nichts kaputt gehen, wenn du den ISP wie beschrieben anklemmst. Aber vielleicht wartest du noch, bis sich ein Erfahrener dazu meldet.
Hello again.... Leider schlechte Nachrichten. Ich habe den AVR nocheinmal mit eingesetztem Reset Controller geflasht (So wie du es mir skizziert hattest). Wieder ohne Erfolg. Aus einem anderen Forum habe ich dann noch erfahren, dass die Fuse Bits bei Pony Prog genau entgegengesetzt zu TwinAVR gesetzt werden (Da wo bei TwinAVR ein Haken ist darf bei Pony Prog keiner sein). Das hatte ich vorher also auch falsch gemacht. Aber selbst mit richtig gesetzten Fuses ändert sich nichts. Nur zum reinen Verständniss: Der Resetcontroller setzt den Reset-Eingang des AVR beim Einschalten kurz auf Lo und macht damit einen Reset. Mal angenommen der Eingang würde durch das flashen nicht, wie es vorgesehen ist, dauerhaft auf Lo aktiv gesetzt. Dann würde das doch heißen, dass der Reset durch ein Hi signal durchgeführt wird und die Schaltung theoretisch funktionieren müsste, wenn ich den Pegel am Reset Eingang nach dem Einschalten dauerhaft auch Lo setzte. Aber auch dann tut sich nichts.
stefan wrote: > Hello again.... > Leider schlechte Nachrichten. > Ich habe den AVR nocheinmal mit eingesetztem Reset Controller geflasht > (So wie du es mir skizziert hattest). stefb schrieb das du den AVR im Reset halten mußt solange geflasht wird und nicht daß du den Reset-Controller einbauen sollst. > Wieder ohne Erfolg. > Aus einem anderen Forum habe ich dann noch erfahren, dass die Fuse Bits > bei Pony Prog genau entgegengesetzt zu TwinAVR gesetzt werden (Da wo bei > TwinAVR ein Haken ist darf bei Pony Prog keiner sein). Das hatte ich > vorher also auch falsch gemacht. Aber selbst mit richtig gesetzten Fuses > ändert sich nichts. Wie setzt du denn bitteschön die Fuse-Bits ohne daß der Controller im Reset bleibt? > Nur zum reinen Verständniss: > Der Resetcontroller setzt den Reset-Eingang des AVR beim Einschalten > kurz auf Lo und macht damit einen Reset. Mal angenommen der Eingang > würde durch das flashen nicht, wie es vorgesehen ist, dauerhaft auf Lo > aktiv gesetzt. Dann würde das doch heißen, dass der Reset durch ein Hi Da wird beim flashen garnichts gesetzt. Der Reset muß auf GND sein um überhaupt flashen zu können. > signal durchgeführt wird und die Schaltung theoretisch funktionieren > müsste, wenn ich den Pegel am Reset Eingang nach dem Einschalten > dauerhaft auch Lo setzte. > Aber auch dann tut sich nichts. Zieh den Reset-Controller wieder raus und lege den Reset-Eingang des AVR hart auf GND. Nimm meinetwegen eine Drahtbrücke oder nen rostigen Nagel aber auf GND muß der Reset liegen zum flashen. Solange das nicht gegeben ist kannst du auch keine Fuses verstellen. liebe grüße frank
Hi >Zieh den Reset-Controller wieder raus und lege den Reset-Eingang des AVR Einen vernünftigen Programmer vorrausgesetzt, stört der TL7705 definitiv nicht beim Programmieren. Langjährige eigene Erfahrung. MfG Spess
@Frank allem anschein nach hast du eine ganze Menge von meinem letzten Beitrag falsch verstanden. "Nur zum reinen Verständniss: Der Resetcontroller setzt den Reset-Eingang des AVR beim Einschalten kurz auf Lo und macht damit einen Reset. Mal angenommen der Eingang würde durch das flashen nicht, wie es vorgesehen ist, dauerhaft auf Lo aktiv gesetzt. Dann würde das doch heißen, dass der Reset durch ein Hi signal durchgeführt wird und die Schaltung theoretisch funktionieren müsste, wenn ich den Pegel am Reset Eingang nach dem Einschalten dauerhaft auch Lo setzte." Das war nicht auf die Programmierung bezogen sondern auf den NORMALEN Betrieb der Schaltung! Das der Reset beim proggen auf Lo gehalten werden muss hab ich inzwischen auch kapiert. Und das scheint ja auch zu funktionieren, sonst würde Pony wohl keinen einwandfreien Datentransfer melden... Ich habe auch nie ein Problem beim setzten der Fuses beklagt. Das läuft genauso reibungslos wie auch die Programm-Übertragung. Trotzdem: Die Schaltung funktioniert nicht! Und bitte jetzt keine Vermutungen das es einen Fehler im Schaltungsaufbau sein könnte. Ist alles gemessen und gecheckt. Mein Verdacht ist folgender (Ich hoffe ich kann es in verständliche Worte fassen): Bei TwinAVR gibt es die Möglichkeit im Setup festzulegen ob der Reset-Eingang des AVR nach der Programmierung Hi-Aktiv oder Lo-Aktiv sein soll. Diese Möglichkeit finde ich bei PonyProg nicht. Wie ist der Reset-Eingang also vom Werk aus? Hi oder Lo Aktiv? Sollte er vom Werk aus Hi-Aktiv sein so muss dies ja irgendwie geändert werden können. Denn laut Schaltplan muss er Lo-Aktiv sein damit die Schaltung ihren Reset bekommt.
Vielleicht trägt die Benennung des Pin9 mit /RESET (not RESET) zur Verwirrung bei. Wenn der Pin RESET heissen würde, bedeutete dies nach Konvention, dass ein HIGH Signal hier einen RESET auslöst. Das passt nicht zur aktuellen Situation: Ein LOW löst einen Reset aus, d.h. man kennzeichnet den Pin9 entsprechend als not RESET (/RESET). Der AVR befindet sich ohne Betriebsspannung quasi im Reset-Zustand. Beim Einschalten der Betriebsspannung ist die nicht sofort "da", sondern erst in paar Millisekunden ansteigend. Der Resetcontroller ist dafür da, um den AVR so lange im Anfangsreset zu halten, bis nach dem Einschalten eine stabile Betriebsspannung im System vorhanden ist. Im AVR-Tutorial wird diese Im-Reset-Halten-Zeit über das Aufladen eines Kondensators (Kapazität) über einen Widerstand (Strombegrenzung) realisiert. Hast du ein Spannungsmessgerät? Wenn der AVR nicht im Reset ist, d.h. am arbeiten oder trödeln, solltest du zwischen dem /RESET (Pin 9 am AVR) und GND (Pin 20 am AVR) einen HIGH Pegel messen (um 5V). Das sollte, wenn Vcc vorhanden und der Resetcontroller gearbeitet hat, paar Millisekunden nach dem Einschalten der Fall sein. Alternativ zum Multimeter könntest du dir mit einer Low-Current-LED und einem >1K Vorwiderstand eine RESET-Anzeige basteln. Vcc an Vorwiderstand an Anode LED/Kathode an Reset-Leitung. LED leuchtet wenn Vcc vorhanden und AVR im Reset ist. Wenn der AVR in den Reset geht, d.h. wenn der ISP-Programmieradapter anfangen will zu programmieren, ändert sich der Pegel dort auf LOW (ca. 0V). Wenn ISP-Programmer es nicht schafft, den AVR in den Reset zu holen, dann kann keine ISP-Programmierung stattfinden. Die beobachtete TwinAVR Fehlermeldung "Programm enable Sequence not successfull..." deutet darauf hin. Die Meldung kommt - gerade getestet - auch auf einem PC ohne ISP-Programmieradapter. Hast du deinen 5 Strippen (kurz!!! Jeder Zentimeter ist zuviel) + 2 Widerstände Aufbau mind. x Mal kontrolliert? Spätestens jetzt werden im Forum die ersten Kommentare gedacht, dass solche Simpel-ISPs gehen können, aber nicht müssen und dass die nix für Anfänger sind. Ein ordentlicger ISP-Adapter mit gepufferten Leitungen ist zuverlässiger und sicherer für die LPT-Schnittstelle des PCs. Die Fuses sind eine heikle Sache. Wenn die einmal falsch gesetzt sind, kann es sein, dass der AVR gar nicht mehr aufs ISP-Programmieren anspricht. Wenn du "Glück" hast, hat PonyProg nix gemacht, weil es die gleichen Probleme wie TwinAVR hat, aber nix meldet. Bei etwas Pech ist nur die Taktquelle verstellt und das kann man mit weiterem Basteln retten. Wenn du viel Pech hast, ist z.B. der Resetpin disabled, d.h. der AVR reagiert auf dortige Signale nicht mehr. Näheres im Wiki-Artikel AVR Fuses. Es wäre hilfreich die ggf. vermurkste Fuses-Einstellung anzugeben. Alternativ einen frischen AVR benutzen, wenn vorhanden.
Uiuiui :-) Das war jetzt ne Menge Input. Vielen Dank dafür! Ich werde alles der Reihe nach abarbeiten... Da kommt endlich mal mein Logiktester der seit Jahren im Regal verstaubt zum Einsatz. Bislang steht es um den AVR noch sehr gut wie es scheint, da ich ihn noch löschen kann und auch die Fuses setzten kann. (Zumindest mault PonyProg nicht rum) Dann mal auf in eine Lange nacht:-)
stefan wrote: > Bei TwinAVR gibt es die Möglichkeit im Setup festzulegen > ob der Reset-Eingang des AVR nach der Programmierung Hi-Aktiv oder > Lo-Aktiv sein soll. Nein. Der AVR gibt dir vor, wie der Pin9 reagiert. Du kannst in TwinAVR nur vorgeben, dass die Reset-Leitung vom ISP nach dem Programmieren LOW oder HIGH sein soll. Willst du haben, dass der AVR rennt und willst du den ISP Adapter nicht jedesmal nach dem Programmieren abziehen, dann darf die Reset-Leitung vom ISP aus nicht LOW sein. D.h. du machst in TwinAVR dort ein Häkchen, um die Leitung nach dem Ende des Programmierens HIGH zu halten. Besser ist es IMHO den Adapter nach dem Programmieren zu entfernen. Wer weiss, was Vcc und der Rest der Schaltung in Verbindung, dem AVR Programm mit der LPT-Schnittstelle deines PCs macht.
Ahhhhh, das war genau die Info die ich gesucht habe! Dankeschön! Da war ich dann auf dem Holzweg... Wie gesagt ich hab da nicht viel Plan von:-) Aber ich werd mich gleich nochmal dransetzten und alles was du in deinem Roman von vorhin geschrieben hast checken. Die Kabel des "Programmieradapters" sind ca.30cm lang. Ich werd sie nachher mal so kurz machen wie es eben geht.
Angehängte Dateien:
-
fuses.jpg
42 KB
Sooo... ich bin jetzt eine Menge Punkte durchgegangen.(Zur Hand dabei einen Logiktester und mein braves Multimeter) Also: Der Reset-Controller arbeitet. (Beim einschalten ca.1/4sec lo- dann hi pegel an Pin9 des AVR) Bei allen Programmiervorgängen ist zu beobachten, dass der Pegel des Reset Eingang brav auf Lo gezogen wird und da für die Programmierdauer verweilt. Der Quarzoszillator gibt laut meinem Multimeter auch brav die geforderten 8Mhz an pin 19 ab. Wenn ich den AVR nach dem Programmieren auslese entsprechen die Daten im PonyProg Fenster exakt denen die auf den AVR geschrieben wurden. (Das sollte doch die Gewissheit dafür sein, dass die Daten korrekt angekommen sind) Der AVR bekommt eine saubere und stabile Spannung von 5V an Pin40 (GND an Pin20) Die Fuse Bits wurde alle korrekt und laut eines Sceenshot von TwinAVR der der Bauanleitung beilag gesetzt und übertragen. (In PonyProg allerdings "negiert" weil Pony andersherum funkioniert) Den Sceenshot habe ich angehängt. Und trotz allem bekomme ich auf meinem Display immer noch keine Anzeige... Ich habe noch einen Wink bekommen, dass PonyProg nur Intel-Hex Dateien verabeitet kann. Könnte es eventuell sein das meine Datei "nur" Hex ist und PonyProg daraus falsche Daten generiert?? Messungen an dem unter Spannung stehenden AVR haben an keinem der LCD Ausgänge irgendwelche Spannungspegel (weder Hi noch Lo) ergeben. Inzwischen habe ich den AVR schon gegen einen zweiten getauscht. Genauso den Reset-Controller und das Display ebenso um eventuell vorhandene andere Fehlerquellen auszuschliessen. Alles ohne Erfolg....
stefan wrote: > Wenn ich den AVR nach dem Programmieren auslese entsprechen die Daten im > PonyProg Fenster exakt denen die auf den AVR geschrieben wurden. (Das > sollte doch die Gewissheit dafür sein, dass die Daten korrekt angekommen > sind) Hier kann die Programmiersoftware dich foppen, wenn der zuvor geschriebene Puffer beim Lesen aus irgendwelchen Gründen nicht aktualisiert wird. Sicherer ist die Diagnose, wenn du die Programmiersoftware nach dem Schreiben verlässt und neu startest und dann ausliest. > Die Fuse Bits wurde alle korrekt und laut eines Screenshot von TwinAVR > der der Bauanleitung beilag gesetzt und übertragen. (In PonyProg > allerdings "negiert" weil Pony andersherum funktioniert) Den Sceenshot > habe ich angehängt. Gleiches wie oben. Noch zu beachten: Vor dem Schreiben der Fuses den alten Zustand einlesen, dann Häkchen setzen, dann Schreiben. > Und trotz allem bekomme ich auf meinem Display immer noch keine > Anzeige... Das kann daran hängen, dass kein Programm auf dem ABR ausgeführt wird, oder dass ein fehlerhaftes Programm ausgeführt wird oder dass dein LCD nicht mit dem Programm "harmoniert" oder ein sonstiges Problem vorliegt. Du kannst mit deinem Multimeter feststellen, ob der AVR mit dem richtigen Programm arbeitet, ohne dass du auf das LCD angewiesen bist. Dazu überwachst du die Spannung an einem beliebigen Pin an PORTB gegen GND. Anfangs sollte dort LOW (Input ohne Pullup) vorhanden sein. Bei der Initialisierung des Programms werden an PORTB Pullups zugeschaltet und der Pegel sollte auf HIGH wechseln. Das LCD wird im Programm mit einer Initialisierungszeit von 15ms betrieben. Je nach LCD Controller auf dem LCD selbst kann das zu knapp sein. Und unbedingt an den klassischen Fehler bei LCDs denken: den Kontrast muss man Aufdrehen (Spannungseinstellung), damit man was sieht! > Ich habe noch einen Wink bekommen, dass PonyProg nur Intel-Hex Dateien > verabeitet kann. Könnte es eventuell sein das meine Datei "nur" Hex ist > und PonyProg daraus falsche Daten generiert?? Die originale Firmware.hex sieht tatsächlich nicht wie ein Intel-Hex File aus. Der Aufbau ist so Adresse Inhalt
1 | 000000:c607 |
2 | 000001:9518 |
3 | 000002:c022 |
4 | 000003:9518 |
5 | 000004:9518 |
6 | 000005:9518 |
7 | ... |
Der von mir probeweise übersetzte Quellcode aus dem Firmware-Ordner sieht so aus (Intel-Hex Format) Typ Adresse Inhalt....
1 | :020000020000FC |
2 | :1000000007C6189522C018951895189545C04EC07A |
3 | :100010001895B3C018951895189506EA002E00E0BB |
4 | :10002000102E1A94F1F70A94D1F7089504E6002EE1 |
5 | ... |
Ich habe im Anhang ein Archiv mit meiner Test-Intel-HEX-Version (ggf. damit flashen) und dem Binärfile, das ich aus obigem Firmware-File erzeugt habe. Letzteres kannst du benutzen, um es in einen Hexeditor zu laden und mit dem Inhalt des AVRs vergleichen. Wenn das nicht passt, dann meine HEX flashen oder den Quellcode mit dem AVRStudio selbst zu einem KEX assemblieren.
Stefan, wenn du jetzt hier wärst würde ich dich umarmen und übelst abknutschen :-) ES FUNKTIONIERT!!!! Es lag tatsächlich an einer "nicht Intel Hex" Datei! Mit deiner Übersetzten Version hat es auf anhieb geklappt! Ich bedanke mich aufs aller herzlichste!!!!! Sollte ich noch weitere Probleme haben weiß ich jetzt auf welches Forum (und auf wen im speziellen) verlass ist!!!!!
Thread beobachten
Seitenaufteilung abschalten
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.