Hallo.
Ich habe einen kleinen AVR910-Programmer gebaut. Er reagiert auf die
Hyperterminal-Befehle (bei 115200 Baud an COM1) "yy" (LED rot),
"xx" (LED grün) und "zz" ("??") auch wie er soll. Nur beim
Starten im Studio funktioniert er nicht: No supported board found!).
Ich habe mit dem Portmonitor mal die Kommunikation von avrprog.exe
mitgeschrieben (siehe Anhang). Ich kann aber mit dem Zeug rein gar nix
anfangen, weil ich nirgends finde, was nun eigentlich richtig und zu
erwarten wäre.
Kann mir jemand seinen (erfolgreichen) Mitschrieb überlassen oder, noch
besser, mir erläutern, was hier schief läuft?
mfg
gerd
Hallo Gerd, ich hole den Beitrag mal nach oben, denn mit dem Problem bist Du nicht alleine! Auch ich habe während des Wochenendes den kleinen AVR910 Programmer zusammengebaut und den gleichen Effekt festgestellt: Die serielle Kommunikation scheint zu laufen (LEDs wechseln korrekt die Farbe, mit einer Taste, ich glaube "i", erscheint die Signatur auf dem Terminal). Zielschaltung ist bei mir entweder ein STK200 oder ein Eigenbau, die beide mit dem STK200 Parallelportadapter funktionieren. Was mich interessieren würde: Braucht der Programmer spezielle Pegel an der ISP-Schnittstelle, um festzustellen, dass ein ISP-fähiger Baustein angesteckt ist? In meiner Zielschaltung läuft über PortB ein LC Display; "verwirren" den ISP-Adapter die wechselnden Pegel an MISO / MOSI, solange Reset noch nicht aktiv ist? Ab wann muss Reset des Zielsystems low sein? Vielleicht erbarmt sich Klaus Leidinger unseres Problems? Gruß Michael
Angehängte Dateien:
-
portmon-init.jpg
110 KB
@Gerd: Wenn das kein aus mehreren Mitschnitten zusammengestelltes Protokoll ist, stimmt etwas mit der seriellen Schnittstelle nicht, der Programmer reagiert auf mehrere Baudraten: Serial0 SUCCESS Rate: 115200 Serial0 SUCCESS Rate: 19200 Serial0 SUCCESS Rate: 38400 Im Anhang die korrekte Initialisierungssequenz. Die Befehle sind übrigens in der Sourcecodedoku beschrieben. AVRprog.exe sendet 4* ESC (1b) zum synchronisieren, dann 53 (S) und will die Software identifizieren. Er erwartet "AVR ISP" (41 56 ...) Bei Dir kommt dort 0D 05 00 00 00 00 00 0D ist ein Return, und daran verschluckt sich wohl AVRprog, jedenfalls initialisiert er die serielle Schnittstelle danach. Wenn Du am Source nichts geändert hast, kann es auch sein, das der Programmer nicht senden kann (probier mal i, wie Michael das gemacht hat) Auf meiner homepage sind alle bisher vorgekommenen Aufbaufehler beschrieben (was tun bei Fehlern), würde mich wundern wenn da nicht das passende dabei wäre. @Michael: was meinst Du mit "gleichem Effekt"? "No Programmer found" oder funktioniert das brennen nicht? No Programmer found bezieht sich ausschliesslich auf die serielle Kommunikation, zu diesem Zeitpunkt ist egal ob und was angeschlossen ist. Wenn ein LCD an MISO/MOSI angeschlossen ist, kann das die Ursache für ein nicht funktionierendes brennen sein. Der Reset geht auf Low wenn die LED auf rot wechselt. Alles was vorher an MISO/MOSI passiert interresiert den Programmer nicht. Also, schreib bitte mal genau was Dein Problem ist. HTH, Klaus http://www.mikrocontroller-projekte.de
@gerd: gerade ist mir noch was aufgefallen, anscheinend sendet der Programmer garnichts, ich tippe mal auf eine Unterbrechung oder der Transistor Q100 ist nicht wie erforderlich ein PNP Typ. Mit dem Kommando i wirst Du es sehen können. HTH, Klaus P.S. hattest Du nicht mal was von einem USB Wandler geschrieben? Ist der noch dazwischen?
Hallo Klaus, >Wenn das kein aus mehreren Mitschnitten zusammengestelltes Protokoll ist, stimmt etwas mit der seriellen Schnittstelle nicht, der Programmer reagiert auf mehrere Baudraten ... Nee, ist alles aus einem einzigen Aufruf. >Im Anhang die korrekte Initialisierungssequenz. Die Befehle sind übrigens in der Sourcecodedoku beschrieben. Danke. Ist doch mal ein Anfang. > AVRprog.exe sendet 4* ESC (1b) zum synchronisieren, dann 53 (S) und will die Software identifizieren. Er erwartet "AVR ISP" (41 56 ...) Bei Dir kommt dort 0D 05 00 00 00 00 00 0D ist ein Return, und daran verschluckt sich wohl AVRprog, jedenfalls initialisiert er die serielle Schnittstelle danach. Wenn Du am Source nichts geändert hast, kann es auch sein, das der Programmer nicht senden kann (probier mal i, wie Michael das gemacht hat) Ich habe die Software auf den Tiny2313 umgestellt. Wenn ich mich richtig erinnere, hat es mehrere Anläufe gebraucht, bis die Source kompilieren wollte. Ist aber jetzt schon ein paar einige Tage her und kann mich nicht mehr genau erinnern, was genau ich damals machen musste. Habe auch einen 2313 versucht, der ging auch nicht. Habe ihn aber damals nicht mitgeschrieben. Also senden tut er ja schon, nämlich "?" für "habe nix verstanden". Folgende Buchstaben werden mit folgenden Sequenzen beantwortet: A => "Y" R => " " D => " " P => "S" V => "12" Alle anderen Buchstaben werden mit "?" beantwortet, auch i. > Auf meiner homepage sind alle bisher vorgekommenen Aufbaufehler beschrieben (was tun bei Fehlern), würde mich wundern wenn da nicht das passende dabei wäre. Habe ich alle schon zwei Mal durchge-ixt, ist tatsächlich nix passsendes dabei. > gerade ist mir noch was aufgefallen, anscheinend sendet der Programmer garnichts, ich tippe mal auf eine Unterbrechung oder der Transistor Q100 ist nicht wie erforderlich ein PNP Typ. Zumindest sendet er reproduzierbar die "12" und die Fragezeichen. Der Transistor ist ein BC559, also einwandfrei PNP. > Mit dem Kommando i wirst Du es sehen können. Nur mit dem i scheint er es nicht zu haben. > P.S. hattest Du nicht mal was von einem USB Wandler geschrieben? Ist der noch dazwischen? Nö, das ist der Laptop. Übrigens findet das Studio dort einwandfrei das STK500 auf COM7. Ohne Verrenkungen. Der Mitschrieb ist vom Desktop und auf COM1. Mit dem gleichen Kabel auf der gleichen Schnittstelle kann ich das STK500 mit dem Studio ansprechen, daran liegt es also schon mal nicht. Mal sehen, was ich jetzt noch tun kann. Den Tiny noch mal frisch füttern? Mal mit der Baudrate auf 19k2 runtergehen? Noch ein Wochenende investieren? Mal sehen ... Wenn mein Mitstreiter nicht schon zwei Hochvolt-Programmer dafür gebaut hätte, würde ich das unter der Rubrik "gescheitert" ablegen. Aber so ... mfg gerd
Hallo Klaus, danke für Deine ausführliche Antwort. Der "gleiche Effekt" ist die Fehlermeldung beim Aufruf von avrprog.exe (Version 1.40): "No supported board found ..." Mit Deiner Erklärung komme ich weiter: Wechselt die LED auf rot, wird Reset der Zielschaltung aktiv. Es würde also genügen, den Programmer nur mit 5V zu versorgen und die Pegel der ISP-Schnittstelle zu prüfen. Mit Deiner Erklärung werde ich allerdings die Kommunikation der seriellen Schnittstelle noch einmal genauer untersuchen. Ich habe die Transistoren durch BC807 / BC817 und die Dioden durch Schottky BAT43 ersetzt. Ich melde mich heute Abend wieder. Danke Michael
Hallo Gerd: >Ich habe die Software auf den Tiny2313 umgestellt. Wenn ich mich >richtig erinnere, hat es mehrere Anläufe gebraucht, bis die Source >kompilieren wollte. Ist aber jetzt schon ein paar einige Tage her und >kann mich nicht mehr genau erinnern, was genau ich damals machen >musste. Du musst für den Tiny2313 nur die Fuses auf externen Quarz umstellen, der Originalcode geht dann ohne Änderung! Im ATTiny sind einige Register für die serielle Schnittstelle anders benannt, und es gibt zusätzliche Funktionen. Probier mal das Hexfile von meiner Seite (mit 7.328MHz Quarz und richtigen Fuses), die Fuses sind auch bei mir beschrieben. Die unterschiedliche Reaktion auf die verschiedenen Eingaben kann ich mir nur erklären, wenn beim portieren im Code was "durcheinander" gekommen ist, und nicht alle Eingaben abgefragt werden. Wenn Du willst schick mir mal Deinen Source per email, ich schau es mir dann mal an. Bis jetzt ist noch jeder Nachbau gelaufen ;-) Ciao, Klaus
Hallo Klaus, herzlichen Dank für Deine Tipps! Der Programmer läuft nach 1 Nacht schlafen und ein wenig Nachdenken. Ursache war meine Schlamperei: Ich habe statt des 1µF C100 versehentlich einen Elko mit 10µF eingebaut (falsch eingeordnet, Aufdruck nicht gelesen, untypisch kleine Bauform). Am Oszilloskop sah ich heute Abend den grausamen Kurvenverlauf, wechselte den Elko aus und der Programmer lief auf Anhieb mit der seriellen Schnittstelle des Notebooks und auch mit einem USB-RS232 Dongle. Offensichtlich reichte bei dem zu großen Elko die Ausgabe zwar für eine korrekte Terminalausgabe, für das vermutlich sehr zeitkritische avrprog.exe kam die Antwort aber zu spät. @Gerd: Als der Programmer lief, war es tatsächlich einfach zu verstehen, dass die Rückantwort zum PC sehr kritisch ist. Wenn die Firmware und die Fuses in Ordnung sind, solltest Du den Q100 (PNP) möglichst mit einem Oszilloskop genau ansehen. Die Flanken müssen sauber und steil sein. Ich könnte mir vorstellen, dass es PNP-Transistoren mit zu geringer Stromverstärkung auch noch gibt. Mit dem ATtiny2313 hatte ich mit der fertig assemblierten Hex-Datei keinerlei Probleme. Nochmals Danke, Michael
Hallo Michael, danke für die Nachricht, freut mich das der Programmer jetzt funktioniert. Allzu kritisch dürfte die Transistorlösung allerdings nicht sein, der Programmer ist ja inzwischen schon etliche mal nachgebaut worden. Die berichteten Probleme haben sich bisher alle als Aufbaufehler, Lötschluss oder -unterbrechung herausgestellt. (oder falscher Transistor). Halt alles, was in meiner Liste steht ;-) Bin mal gespannt was mit dem Programmer von Gerd los ist. Ciao, Klaus
Hallo Klaus, erst mal ein frustrierender Zwischenbericht. 1. tn2313-flash im STK500 ausgelesen und mit alter 38a-hex-Datei verglichen: alle Quersummen stimmen. 2. Fuses kontrolliert: War auf Quarz oberhalb 8 MHz eingestellt, cDiv8 war aus. Nach Umstellung auf Quarz zwischen 3 und 8 MHz weiterhin: "No supported noard found!". 3. Version 38b source frisch von Deiner Webseite geholt, mit Studio kompiliert und mit STK500 per ISP einprogrammiert: "No supported board found!". 4. In der source include 2313def.inc gegen tn2313def.inc gewechselt, PAGESIZE-Zeile auskommentiert, kompiliert und einprogrammiert: "No supported board found!". Die Antworten auf den Aufruf bei 115 kBd lauten jetzt übrigens nicht mehr 0D 05 00 00 00 00 ... wie vorher, sondern 05 00 00 ... Was man so softwareseitig machen kann, ist damit passiert. Als Nächstes ist dann die Hardware dran. mfg gerd
Hallo Gerd, warum nimmst Du denn nicht das original HEX File, wenn Du eh einen 7.32.. MHz Quarz einsetzt? Der tn2313 braucht wirklich keine Änderung ausser den richtigen Fuses. Einen Vorteil hast Du jetzt aber, es muss ein Hardwareproblem sein ;-) ziehe mal den Controller aus der Fassung und brücke Rx und Tx an der Controllerfassung. Schau dann nach ob ein ordentliches Echo für alle Eingaben am Terminal erscheint. Das erscheint mir am Erfolgversprechendsten. Viel Glück, Klaus
Hallo Klaus und alle Mitleser, das Problem ist gelöst: es war tatsächlich ein Hardware-Problem. Die Diode D100 war verkehrt herum eingelötet, und zwar bei allen beiden Geräten schön einheitlich. (Der Löter ist mir sonst als sehr zuverlässiger Verdrahter bekannt, deshalb habe ich in der Ecke erst mal gar nicht gesucht.) Da die Diode für die Gewinnung der negativen Spannung da ist, kam keine ordentliche Negativspannung an C100 zustande und das RS232-Sendesignal hat unzureichende Pegel gehabt. So konnte das ja nix werden. Beim Loopback- oder Brückentest (Rx und Tx verbinden) kamen übrigens trotz fehlender Negativspannung ordentliche Zeichen zurück, nur das erste nach längeren Pausen wurde verschluckt, sonst hat er brav alles geechoet. Dieser Test ist also KEINE ultimative Prüfung, ob die RX/TX-Hardware ok ist. Abschließend noch mal ein herzliches Danke an alle, die beim Debugging der zwei liebevoll gebauten Schächtelchen behilflich waren, insbesondere an Klaus. Ohne den Portmon hätte ich doch ziemlich im Regen gestanden. mfg, gerd
Thread beobachten
Seitenaufteilung abschaltenBitte 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.