|
|
Forum: Mikrocontroller und Digitale Elektronik AtTiny2313 FlashproblemHallo Leute, ich flashe mit dem ehajo ateval (bisher immer den AtTiny45) und jetzt bin ich aufgrund mangelnder Pins auf den AtTiny2313 umgestiegen. Im Assembler Code hab ich sowohl
als auch
ausprobiert. Wie auch immer ich es reinschreibe es geht nicht. Ansonsten kann ich am Controller alles machen (löschen, fuses programmieren), nur wenn ich mein Programm flashen will bricht das Atmel Studio ab. Hat da wer ne Idee? Viele Grüße Michael Michael E. schrieb: > Hat da wer ne Idee? Versuch mal tn2313Adef.inc Wenn das auch nicht geht und keine weiteren Infos zur Verfügung stehen, wirst du wohl damit leben müssen. Michael E. schrieb: > .include "tn2313def.inc" So muss das aussehen für einen Tiny2313. > Wie auch immer ich es reinschreibe es geht nicht. Was heisst "geht nicht" denn genau? Vermutlich eigentlich: "läßt sich nicht assemblieren". Das ist wäre ziemlich normal, wenn man (schlechten) Code von einem Tiny45 verwendet. Zwischen den beiden Tinys gibt es doch recht erhebliche Unterschiede. > Ansonsten kann ich am Controller alles machen (löschen, fuses > programmieren), nur wenn ich mein Programm flashen will bricht das Atmel > Studio ab. Das findet wohl einfach nichts zum flashen, weil schon das Assemblieren fehlgeschlagen ist. Wie wäre es denn, wenn du einfach mal die Ausgabe beim Assemblieren liest. Da wird drinstehen, was ihm nicht passt. Es kann aber auch noch an etwas anderem liegen: Nämlich den Einstellungen der Programmersoftware. Der muss man extra mitteilen, dass das Ziel nunmehr ein Tiny2313 ist und kein Tiny45. Und nein: die Programmersoftware weiss rein garnix davon, was im Quelltext steht. Die kennt nur das Hexfile und sogar dessen Inhalt ist ihr weitgehend Wurscht. Hab ich jetzt mal probiert ändert aber nichts am Ergebnis. Die Fehlermeldung an sich ist auch nicht besonders hilfreich... "Could not read from libusb0 connection: libusb0-dll:err [_usb_reap_async] timeout error" c-hater schrieb: > Das ist wäre ziemlich normal, wenn man (schlechten) Code von einem > Tiny45 verwendet. Zwischen den beiden Tinys gibt es doch recht > erhebliche Unterschiede. Der Code um den es geht ist speziell für den Tiny2313 geschrieben und keine Portierung oder sowas. Das Assemblieren läuft problemlos durch. Hier der ganze Code um anderweitige Fehler auszuschließen.
Michael E. schrieb: > "Could not read from libusb0 connection: libusb0-dll:err > [_usb_reap_async] timeout error" Da liegt der Fehler in der Kommunikation mit dem Programmiergerät, nicht in dem Quelltext des Programmes. MfG Paul Paul B. schrieb: > Da liegt der Fehler in der Kommunikation mit dem Programmiergerät, nicht > in dem Quelltext des Programmes. Genau so ist das. @Paul Das befürchte ich leider auch... Aber das merkwürdige ist, dass es mit den Tiny45 einwandfrei klappt -_- Michael E. schrieb: > Aber das merkwürdige ist, dass es mit den Tiny45 einwandfrei klappt -_- Hast Du denn in der Programmiersoftware auch den richtigen Typ Kontroller, nämlich nun den Attiny2313 statt des Attiny45 eingestellt? Sind die Leitungen (Mosi, Miso, Sck, Reset und GND) auch richtig beschaltet? MfG Paul :
Bearbeitet durch User
In der Atmel Studio Flash Oberfläche ist der Tiny2313 ausgewählt und da ich ja den Ateval (https://www.ehajo.de/bausätze/bedrahtete-bausätze/ateval-atmel-evaluationsboard.html) verwende kann ich gar nichts falsch beschalten Viele Grüße Michael Hallo Michael, naja so ein AVR läuft erstmal mit dem RC Oszillator mit 1:8 Vorteiler. Hast Du deshalb auch die ISP Geschwindigkeit angepasst ? Ist alles geprüft ja. Die Fuse konnte ich ja sogar programmieren. Der läuft mit dem inernen RC bei 8MHz ohne Prescaler Karl M. schrieb: > naja so ein AVR läuft erstmal mit dem RC Oszillator mit 1:8 Vorteiler. > Hast Du deshalb auch die ISP Geschwindigkeit angepasst ? Das ist hier sicher nicht das Problem. Die Fehlermeldung besagt, das bereits die Kommunikation zwischen Programmer-Software und Programmer nicht klappt. Dafür spielt die Kommunikation zwischen Programmer und Target noch absolut keine Rolle. Das Problem wird in der Hardwareschaltung liegen. Vermutlich wird das Target vom Programmer versorgt, verbraucht aber viel mehr Strom, als dieser liefern kann, wodurch der Programmer selber nicht mehr genug Spannung hat, um korrekt arbeiten zu können. -> Irgendwo ist da in der Schaltung des Target ein Kurzschluss. Oder es braucht einfach wirklich mehr Strom, als der Programmer zu liefern vermag, also eine eigene, hinreichend leistungsfähige Stromversorgung. Dann muss aber die Einspeisung über den Programmer abgeschaltet werden. Hi Nicht, daß ich dort ein wirkliches Problem sehe: Michael E. schrieb: > ; (XTAL1) PA1 =| |= PB5 (MOSI / DI > ; (XTAL2) PA0 =| |= PB4 (OC1B / > ldi temp, (1 << PORTB7) | (1 << PORTB6) | (1 << PORTB5) | (1 << > PORTB4) | (1 << PORTB3) | (1 << PORTB2) | (1 << PORTB1) | (1 << PORTB0) > out PORTB, temp Wenn Du die Geräte an PB4/5 versuchsweise abklemmst? Dann noch eine Frage, rein Interesse halber: > ldi temp, (1 << PORTD6) | (1 << PORTD5) | (1 << PORTD4) | (1 << > PORTD3) | (1 << PORTD2) | (1 << PORTD1) > out PORTD, temp > > sbi PORTD, PORTD0 Warum setzt Du das Port 0 separat? MfG Wer hat etwas von Geräten an PB4/5 gesagt?? Hab das nochmal extra gesetzt weil das der einzige Ausgang is den ich momentan benutze und den erst auf HIGH setzen will, wenn die gesamte restliche Konfiguration abgeschlossen ist... Aber das tut eigentlich wenig zur Sache gerade Viele Grüße Michael Hi Da PB4/5 in Deinem Code explizit benutzt werden, ging ich davon aus, daß Du damit nicht nur Speicherplatz belegen willst - somit war meine Vermutung, daß dort angeschlossene Gerätschaften Dir die Programmier-Signale verfälschen - wobei ich solche Probleme bei mir noch nicht beobachten konnte - buche es unter 'externer Lösungsansatz' ab. Letzteres war auch nur rein interessehalber und nicht auf das Problem bezogen, wunderte mich nur, da diese Zeile durch die zwei Zeilen drüber ebenfalls entfallen könnte. MfG Michael E. schrieb: > Aber das tut eigentlich wenig zur Sache gerade dito ;) :
Bearbeitet durch User
Hi, nach meinen Erkenntnissen liegt es an der Stromversorgung. Hänge den Programmer an an aktiven HUB - da sollte es funktionieren. c-hater schrieb: Oder es braucht einfach wirklich mehr Strom, als der Programmer zu liefern .. Ich nutze das Evaluationsboard am Notebook nur mit einem USB3 Hub. Ohne Hub - Probleme!!! Gruß Kurt Es wird jeder Pin des Controllers benutzt... Das aktiviert einfach nur überall die Pull-Ups, damit die nicht alle etwas unvorhersehbares tun :D Du hast es auch mit einem anderen Tiny2313 getestet und es gibt den gleichen Fehler? Es soll ja schon vorgekommen sein, daß ein Controller einfach eine Macke hat. Ja, ich bin mir sicher, daß das schon vorgekommen ist. Genauso wie der Ehajo einen Fehler haben kann. Daß der Sockel für den 45er funkioniert, lässt zwar erwarten, daß die anderen Sockel das auch tun, garantiert ist das aber nicht. Schon gar nicht, wenn du das Ding selbst zusammengelötet hast und den 2313-Sockel heute zum ersten Mal testest. :
Bearbeitet durch User
Habs mit meinem zweiten Tiny2313 auch getestet => selber Fehler Selbst zusammengelötet is es ja... Was für originale Programmer kann man momentan empfehlen? Viele Grüße Michael Hi Um den Platinen-Fehler bestimmen oder ausschließen zu können, kannst Du doch die Programmier-Anschlüsse der ATtiny45 abgreifen und auf einem Breadbord den Tiny2313 damit testen. Wenn's hier funktioniert, hast Du wohl ne kalte Lötstelle oder so was in der Beschaltung des Sockel. Wenn nicht, hast Du immerhin schon zwei kaputte Steinchen :/ MfG Das ateval Board hat eigene Steckerleisten für ISP6 usw. Siehe: http://dokuwiki.ehajo.de/_media/bausaetze:evalboard-005.topnames.png http://dokuwiki.ehajo.de/bausaetze:ateval:anleitung Michael E. schrieb: > Was für originale Programmer kann man momentan empfehlen? Die empfehlenswerten Programmer sind nach wie vor die Originale von Atmel. Aber nur nicht gleich die Flinte ins Korn werfen. Ob es nun wirklich an dem Ehajo liegt, wissen wir ja gar nicht. Die Erfahrung zeigt nur, daß man im Fehlerfall nichts ausschließen darf. Nach dem Motto: Wenn das geht, muß das andere auch gehen. Abgehakt. Nein, das ist nicht so! Ich würde als erstes den Sockel des Ehajo nachlöten. Manchmal gibt es "unsichtbare" Lötspritzer, die Kurzschlüsse verursachen, nichtmal richtige Kurzschlüsse, sondern nur "mittelohmige" Verbindungen. Mit Nachlöten kriegt man die mit ziemlicher Sicherheit weg. Eventuelle kalte Lötstellen werden auf diesem Weg gleich mit beseitigt. Okay das hat mich jetzt doch sehr verwundert :D Ich habe das Board einfach mal an einen anderen USB-Port angeschlossen und dann hat der ganz ohne meckern geflasht. Danke für die Mühe an alle, manchmal lösen sich Probleme ganz von selbst Grüße Michael Ebel 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten