Hallo, ich habe ein AT90USB647, der soweit Problemlos funktioniert (USB - Bootloader, I/O, Timer, etc.). Nun habe ich das Problem, dass ich gerne eine USB Verbindung zum PC herstellen würde und dazu die Firmware von Herrn Salewski raufgespielt habe, nur tut sich bei mir am USB leider nichts, kein Piep beim einstecken, nichts im Gerätemanager oder anderen USB Browsern. Hab die Firmware mehrmals (verändert) probiert, unter anderem : - unverändert - mit angepasstem Makefile ( MCU, etc.) - mit angepassten Configs, Interfaces, EP´s, etc. leider führte bisher kein Weg zum Ziel. Das Ziel vorläufig ist nur, dass er das Gerät am USB erkennt, keine Daten senden etc. ( Nächster Schritt =) ) Board und USB müssten funktionieren, da der USB Bootloader auch problemlos funktioniert. Hat jemand ein Tipp was ich ändern könnte um eine Verbindung herzustellen bzw. was ich falsch gemacht habe ? Danke. Matthias PS.: Der Compiler bringt keine Fehler oder so =)
Wenn sich überhaupt nichts tut, würde ich mal darauf tippen, dass du den Widerstand von D+/D- nach Vcc vergessen hast. Sobald man den einbaut muss sich irgendwas tun, egal ob da noch irgendwelche Logik dranhängt oder nicht.
Bei den PICs ist das so, dass - sobald man die USB-Interface-Hardware im PIC aktiviert, der Host direkt den Enumerierungsprozess startet (und ziemlich schnell eine Fehlermeldung sendet, wenn man nicht rechtzeitig richtig antwortet). Bei den PICs gibt es auch eine Option, dass für die Datenleitungen interne oder externe Pullups verwendet werden können... kein Plan ob der AT90USB647 diesbezüglich auch so komfortabel ist ;-) ...also wie Philipp Burch schon schrieb, sobald Pullups an den Datenleitungen hängen gehts ab... Also würde ich Dir vorschlagen dieser Sache mal nachzugehen...
Hallo, ja stimmt ich habe keine Pullup Widerstände in D+ bzw. D-, ich hab die USB Buchse so angeschlossen, wie es im Datenblatt für 5V Self Powered Geräte gestanden ist ( mit 22R Serien Wid. ). Hab allerdings vorher im Forum auch gerade was bzgl. eines Pullup gelesen. Weisst jem. da genaueres dazu? Brauche ich den Pullup, ist der nicht intern? USB-Bootloader funktioniert ja auch(?) Wenn ich ihn brauche, auf welche Leitung muss ich ihne legen und wie groß sollte der ca. sein? danke für die Hilfe Matthias
Also einfach D+ und D- über Wid. auf VCC. wie groß sollte der Wid. sein? ( 10k Pullup )? sorry, hab vorher deine Antwort grad nicht mehr gesehen =) danke
>dazu die Firmware von Herrn Salewski raufgespielt
Stimmt die Quarzfrequenz?
Autor: Philipp Burch (philipp_burch) Datum: 24.03.2008 17:57 >Wenn sich überhaupt nichts tut, würde ich mal darauf tippen, dass du den >Widerstand von D+/D- nach Vcc vergessen hast. Der AT90USB benötigt nicht diesen externen Widerstand nach Vcc.
ok, danke für die hilfe und den link. Quarz F stimmt ;) also wenn ich Lowspeed betreibe, dann 1k5 von D- auf 3V3 und bei Fullspeed 1k5 von D+ auf 3V3. Zusätzlich an beiden Leitungen 15k auf Masse. Was mach ich nun wenn ich keine 3V3 habe? Habe 5V Vcc brauch ich da jetzt extra eine Spgregler oder kann ich denn Widerstand zw. D+/- und VBUS schalten? ( Betrieb Selfpowered ) Danke soweit. mfg Matthias
>ok, danke für die hilfe und den link. >Quarz F stimmt ;) >also wenn ich Lowspeed betreibe, dann 1k5 von D- auf 3V3 und bei >Fullspeed 1k5 von D+ auf 3V3. >Zusätzlich an beiden Leitungen 15k auf Masse. >Was mach ich nun wenn ich keine 3V3 habe? >Habe 5V Vcc brauch ich da jetzt extra eine Spgregler oder kann ich denn >Widerstand zw. D+/- und VBUS schalten? ( Betrieb Selfpowered ) >Danke soweit. ??? Nun mal langsam. Wenn der USB-Bootloader funktioniert, dann ist die Hardware ok. Und dann sollten wir meine Firmware auch zum laufen bekommen. Weiters später.
Ok, dann werd ich da mal nichts überstürzen =) Also im Sinn von stimmt die Quarzfrequenz meinte ich ob ich Fuses au extern habe und VT 0 und so. Habe 16MHz Quarz, extern, ohne VT. Oder hast du gemeint die freq. im Makefile ? Hatte es zuerst im Makefile nicht drinn, dann wusste ich nicht an welche Variable ich es "anhängen" sollte und dann hab ichs einfach mal so hinten ans cflags rangehängt ( -DF_CPU=16000000UL ).
@Matthias T. So, ich bin wieder da. USB-Bootloader funktioniert also? Du kannst per USB von Deinem PC ein Testprogramm (LED blinken oder so) auf den uC übertragen und ablaufen lassen? Dann ist die (USB) Hardware OK. Hast Du einen 16 MHz Quarz bzw. Quarz-Ozillator? Welches Betriebssystem läuft auf Deinem PC?
Und nochmal die Frage: Welches Betriebssystem läuft auf Deinem PC?
Hallo, USB Bootloader funktioniert mit FLIP, scho mehrfach programmiert. 16 MHz Quarz ( nicht Oszillator ). WinXP SP2. danke für die hilfe
Gut. 16 MHz hatte ich für meine Platinen auch verwendet, soweit braucht man nichts verändern. Ich hatte allerdings den AT90USB1287, im Makefile solltest Du die Zeile MCU = at90usb1287 durch MCU = at90usb647 ersetzen. Ich persönlich habe meine Firmware bisher nur unter Linux eingesetzt. Aber es sollte im Prinzip schon unter Windows funktionieren. Hast Du die Möglichkeit mal mit Linux zu Testen? Bei Windows kann man sich nie so recht sicher sein was es macht. Evtl. erkennt es das Gerät, versucht es anzusprechen -- das schlägt fehl und dann meldet Windows das Gerät sofort ab? Wäre eine Vermutung, ich habe mit Windows nichts an Hut. Soweit ich mich erinnere hatten mir einige Leute geschrieben, dass Sie meine Firmware auch unter Windows einsetzen, aber ich weiß nicht was sie genau verändert haben. Ein Test unter Linux wäre daher gut. Es könnte natürlich auch sein, dass sich der AT90USB647 doch anderes verhält als der AT90USB1287. Glaube ich aber nicht. Welche Compiler-Version setzt Du ein? Hast Du an den Fuses irgend etwas umgestellt? Hat Dein Board eine Serielle Schnittstelle für Debugging? Wie ist Dein Kenntnisstand bezüglich uC und USB?
So, ich habe mal Windows XP gebootet, mich als normaler Nutzer angemeldet und eine meiner Platinen angestöpselt: Wie erwartet öffnet sich ein Fenster "Neue Hardware gefunden..." und im Gerätemanager wird ein unbekanntes USB-Gerät mit VID_03EB (Atmel) angezeigt. Der VID-Code 03EB stammt von meiner Firmware (Atmel Code), d.h. Windows kann mit dem Gerät kommunizieren. Nun ist es aber so: Ich nutze Windows praktisch nie, so dass auf meinem Windows XP praktisch keinerlei zusätzliche Treiber installiert sind. Bei Dir wird es anders aussehen, Du hast vermutlich AVR-Studio und FLIP installiert. Nun wäre meine Vermutung, dass bei Dir Windows den VID_03EB liest und dann das Gerät mit irgend einem Treiber ansprechen will. Das geht nicht und Windows meldet das Gerät ab. Von all dem bekommst Du evtl. nichts mit. Ich habe die Atmel VID einfach verwendet, da es ja ein Atmel uC ist. Im Prinzip hätte ich mir eine VID kaufen können, aber da ich keine Platinen mit dem AT90USB kommerziell vertreibe werde ich keine 2000 Dollar dafür ausgeben. Und mit Linux gibt es ja eh keine Probleme. Wenn dies die Ursache für das Problem ist, könntest Du einfach mal eine andere VID ausprobieren (Datei com_def.h). Allerdings: Prinzipiell wäre es möglich, dass Windows Deine Platine dann für ein anderes Gerät hält, und evtl. abstürzt oder andere schlimme Dinge macht. Wenn Du wenig USB Kenntnisse hast, eh nur Windows nutzen willst und es Dir auch egal ist, ob die Software frei (GPL) ist oder nicht, solltest Du vielleicht doch lieber Atmels USB-Software nutzen. Gruß Stefan Salewski
Hallo, Danke für die Antworten. Also die MCU im Makefile hatte ich ersetzt. Hab mom. leider nicht die Möglichkeit unter Linux zu testen ( bei mir ). Habe mir die aktuellste Version vom AVR Studio und WinAVR heruntergeladen ( vor 2 Wochen ). Momentan hab ich leider nicht die Möglichkeit zum Debuggen, hab das aber auf der nächsten Platine schon vorgesehen ( MAX232 ). Fuses hab ich glaub nur den Clockvorteiler rausgenommen. Hab natürlich schon Treiber installiert, aber es müsste ja nach Anstecken des Geräts mindestens ein "Tüdüt" kommen. Werd das mit der VID morgen mal probieren und stecks mal zum schauen an einen älteren Computer an, der nur Grundprogramme installiert hat. Ich probiers morgen bei einem Kolleg auch mal unter LINUX, brauch ich da bestimmten Treiber oder so ? Die LibUsb oder so brauch ich dann ja nur zum Datenaustausch, oder, bin mit Linux leider nicht so vertraut. Würde gerne eine freie Firmware wie deine verwenden, da es mich auch interessiert was im Hintergrund abläuft. danke gruß Matthias
>Würde gerne eine freie Firmware wie deine verwenden, da es mich auch >interessiert was im Hintergrund abläuft. Gut, dann sollten wir das auch hinbekommen. Notfalls können wir ja unsere Platinen per Post tauschen. >Fuses hab ich glaub nur den Clockvorteiler rausgenommen. Das könnte evtl. das Problem sein. Meine Firmware funktioniert mit den AT90USB so wie sie ausgeliefert werden. Der AT90USB sollte intern mit 16 MHz laufen. Es wäre schon gut zu wissen das er das tut. Man kann ihn irgendwie so programmieren, dass er den Takt ... Ah, da fällt mir gerade was ein: Das alte Datenblatt des AT90USB1287 hatte ja eine Reihe von Fehlern. Drin stand auch, dass der uC vorgabemäßig auf internen Takt eingestellt ist. Das ist natürlich offensichtlich Unfug (sonst würde der USB-Bootloader nicht funktionieren), aber dass hat dich evtl. dazu bewogen an den Fuses zu drehen... Seit einigen Wochen ist aber ein neues Datenblatt verfügbar. Wie gesagt, den Takt sollte man überprüfen. Man kann den uC so programmieren, dass er den Takt an einem Pin ausgibt, dann kann man ihn mit einem Frequenzzähler oder Oszilloskop messen. >Hab natürlich schon Treiber installiert, aber es müsste ja nach >Anstecken des Geräts mindestens ein "Tüdüt" kommen. Weiß ich nicht. Wenn Windows meint das Gerät sei defekt? >Ich probiers morgen bei einem Kolleg auch mal unter LINUX, brauch ich da >bestimmten Treiber oder so ? Treiber brauchst Du nicht (der PC/Linux sollte aber USB unterstützen) Wenn Du die Platine eingestöpselt hast (und natürlich auch mit Strom versorgt, wenn self-powered), gib mal in der Shell das Kommando "dmesg" ein. Ganz unten als neuer Eintrag sollte dann zu lesen sein etwas wie: usb 1-8.1: new full speed USB device using ehci_hcd and address 6 usb 1-8.1: configuration #1 chosen from 1 choice Mehr Informationen bekommst Du mit (musst aber evtl. als root/Administrator angemeldet sein): lsusb oder cat /proc/bus/usb/devices liefert etwas wie T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs= 1 P: Vendor=03eb ProdID=0001 Rev= 0.01 S: Manufacturer=SALEWSKI S: Product=AT90USB S: SerialNumber=001 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms >Die LibUsb oder so brauch ich dann ja nur zum Datenaustausch Ja. Unter Linux ist LibUSB meist eh installiert, unter Windows wird man LibUSB wohl separat installieren müssen. Ich weiß leider nicht, ob LibUSB unter Vista funktioniert -- unter XP schon. Gruß Stefan Salewski
> Das könnte evtl. das Problem sein. Meine Firmware funktioniert mit den > AT90USB so wie sie ausgeliefert werden. Der AT90USB sollte intern mit 16 > MHz laufen. Es wäre schon gut zu wissen das er das tut. Man kann ihn > irgendwie so programmieren, dass er den Takt ... intern mit RC Osz. oder halt die Freq. im Baustein ? Hab ext. Osz. 16 MHz ohne Prescaler ( CKDIV8 deaktiviert ). Habs mal einen Pin Toggeln lassen - der "blinkt" mit 1Mhz also Toggelt mit 2 MHz, könnte ja passen, 8 Befehle für Schleife Port setzen etc., oder ? > Weiß ich nicht. Wenn Windows meint das Gerät sei defekt? Ok, das Teste ich morgen mit der anderen VID danke für die Hilfreichen Tipps und Infos werde morgen wieder von mir hören lassen. Grub Matthias Trieb
Mir fiel gerade noch etwas ein, evtl. habe ich die Lösung: Dein AT90USB647 hat ja nur 4kByte RAM, mein AT90USB1287 8kByte. Ich habe ja einen Haufen Debugging Code mit Textausgaben drin, die RAM belegen. Außerdem einen Pufferspeicher für die Datenerfassung. Mit 4 kByte RAM muss es eigentlich Probleme geben. Evtl. gibt avr-gcc keine Warnung wenn der Speicher überläuft. Probier mal den Debugging-Code abzuschalten: Ersetze in defines.h #define DEBUG // send debug messages over serial port //#undef DEBUG //#define NOUART // do not use usart_drv.c at all #undef NOUART durch das Gegenteil //#define DEBUG // send debug messages over serial port #undef DEBUG #define NOUART // do not use usart_drv.c at all //#undef NOUART und in ringbuffer.h #define BufElements 1024 durch #define BufElements 256 Weiteres morgen.
Morgen, habs kurz vorm Weggehen nochmal probiert mit der Debug aus und so => Hex File 2/3 kleiner. Sonst hat sich aber leider nichts getan, auch der kleinere Buffer nicht. Habs dann noch schnell mit der VID probiert => keine Reaktion. Werde in diesem Fall nachher noch den LINUX test durchführen. danke Matthias
>Sonst hat sich aber leider nichts getan
Schade.
Der Debugging-Code muss in jedem Fall für den AT90USB647 abgeschaltet
werden, sonnst reicht der RAM nicht aus.
Als ich im Herbst 2006 die Firmware geschrieben habe war nur der
AT90USB1287 verfügbar und ich habe nicht dran gedacht, dass der
AT90USB647 nur halb so viel RAM hat. Das Problem sind die Text-Strings,
die ich normal definiert habe, wie es in C üblich ist. Dann belegen sie
aber RAM. Man kann sie irdend wie anders anlegen -- das müsste ich
vielleicht mal umschreiben.
Wenn das Gerät mit meiner Firmware unter Linux auch nicht erkannt wird
gibt es zwei mögliche Ursachen:
- Dein Gerät ist self-powered (meins Bus-powered)
- Du hast den AT90USB647 (ich den AT901287)
Ich wüsste zwar nicht, dass das einen Unterschied macht, aber wäre ja
möglich.
Naja, warten wir mal ab was Linux sagt (bei abgeschalteten
Debugging-Code)
Gruß
Stefan Salewski
so, habs grad getestet. Leider hat sich die Platine auch unter Linux nicht gemeldet. Hab für die nächste Platine ein Umschalter zw. Self und Bus Powered vorgesehen. Soll ich mir dann eher ein at90usb128 zulegen, kann es echt an den nur 4KB Ram liegen, bei amgeschaltetem Debugging. Kann man den RAM über den Programmer auslesen? ( zum größe feststellen ) oder so. danke Matthias
Matthias T. (maette) schrieb am 25.03.2008 um 12:53 Uhr: >Leider hat sich die Platine auch unter Linux nicht gemeldet. Ich habe es schon befürchtet. Meine Vermutung ist, dass es am self-powered liegt. Da ist das Timing wohl etwas anders. Ich vermute, dass der ganze Kram zur Aktivierung der USB-Einheit bei Dir gar nicht erst ausgeführt wird. Das Datenblatt, zumindest das Alte, erklärt die Aktivierung nicht sehr genau. Daher war ich damals froh, dass ich es hin bekommen hatte, und habe nicht weiter darüber nachgedacht, dass es bei self-powered anders sein könnte. Mir haben zwar einige Leute geschrieben, dass meine Firmware bei ihnen funktioniert, aber vermutlich war das stets Bus-Powered Betrieb. Ich hatte schon dran gedacht, eine meiner Platinen auf self-powered umzubauen, aber leider befinden sich die Versorgungsleitungen unter dem Prozessor. Und ich habe derzeit auch nur bestückte Platinen. >Hab für die nächste Platine ein Umschalter zw. Self und Bus Powered >vorgesehen. Soll ich mir dann eher ein at90usb128 zulegen Bus-Powered mit AT90USB1287 sollte ich jedem Fall funktionieren, zumindest mit Linux. Wenn Du eh noch eine Platine machen willst, würde ich sie in der Tat umschaltbar self/bus-powered machen und mit einem AT90USB1287 bestücken, möglichst auch mit MAX232 für serielle Schnittstelle. Als Alternative könnte ich Dir leihweise eine meiner Platinen (entsprechend meiner Internetseite) schicken. Vielleicht kannst Du Deine Platine ja auch einfach umbauen -- externe Spannungsversorgung abklemmen und durch einen Draht von VBUS ersetzen? Ich werde mich um die Probleme mit self-powered bzw. AT90USB647 kümmern, aber das kann etwas dauern, evtl. auch etwas länger. >Kann man den RAM über den Programmer auslesen? ( zum größe feststellen ) >oder so. Unter Linux/avr-gcc gibt es ein Kommando "avr-size file.hex" oder ähnlich, bei WinAVR weiss ich nicht. Aber wenn der Debugging-Code deaktiviert ist hast Du mit der RAM-Größe ganz sicher keine Probleme. Es könnte natürlich sein, dass sich 647 und 1287 noch in anderen Punkten unterscheiden, das glaube ich aber nicht. Gruß Stefan Salewski
ok, dann werde ich mal mit einem Draht brücken ( von VBUS auf VCC ), hatte eigentl. vor den AT90USB647 von der alten Platine auszulöten, dass ich nicht einen neuen kaufen muss, scheint aber erforderlich zu sein, oder ? Was mache ich wenns gebrückt auch nicht geht ? gruß Matthias T.
so gerade schnell getestet ... ( VBUS auf VCC ) Es funktioniert !! =) Windows meldet ein Unbekanntes USB - Gerät :D Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx) USB hat sich beklagt, dass das USB Device zu viel Strom verbraucht und deshalb abgehängt werden sollte. Jetzt erkennt ers nicht mehr, warsch. mit anderer VID wieder.
Matthias T. (maette) schrieb am 25.03.2008 um 14:14 Uhr: >so gerade schnell getestet ... ( VBUS auf VCC ) >Es funktioniert !! =) Gut! Übrigens, mir fiel gerade ein: Self- oder Bus-powered sollte ja nur einen Unterschied machen, wenn das Gerät neu eingesteckt wird. Wenn es schon eingesteckt ist und man dann per Reset-Taster einen Reset macht, sollte es eigentlich auch Self-powered funktionieren Aber egal, nun wissen wir, dass sich ein AT90USB self-powered beim Aktivieren des USB-Teils anders verhält. Ich werde das untersuchen. >USB hat sich beklagt, dass das USB Device zu viel Strom verbraucht und >deshalb abgehängt werden sollte. Jetzt erkennt ers nicht mehr, warsch. >mit anderer VID wieder. Der AT90USB selbst sollte doch nur einige 10 mA verbrauchen? USB liefert zunächst maximal 100, später wenn sich das Gerät korrekt angemeldet hat bis zu 500 mA. Naja, evtl. baust Du wieder auf self-powered zurück und löst dann einen Reset per Taster aus. Achtung: beim Reset muss Pin PE2 (HWB) auf Vcc liegen (über einen Widerstand), sonst springt er in den Bootloader, siehe meine HTLM-Seite. Du müsstest im Gerätemanager oder so eigentlich alles zurücksetzen können, so dass er das Gerät wieder erkennt. (Einige Leute hängen an den USB-Port sogar Kaffeewärmer oder Leuchten ohne korrekte Anmeldung -- bei einigen PCs geht das, bei einigen nicht.) >Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per >C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx) Da kann ich Dir nicht helfen. Mit LibUSB sollte es auch unter Windows recht einfach sein, da kannst Du dich an den Funktionsaufrufen in meinem Beispielprogramm orientieren. HID wird aber von meiner Firmware (noch) nicht unterstützt. Gruß Stefan Salewski
Müssten/sollten nicht die Einträge im InterfaceDescriptor für bInterfaceClass auf vendor-specific voreingestellt werden (oder gleich für's ganze Gerät)? "A value of zero is reserved for future standardization." "If this field is set to FFH, the interface class is vendor-specific. All other values are reserved for assignment by the USB-IF" > Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per > C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx) Wenn LibUSB verwendet wird: Beitrag "C# .lib (libusb) Libary einbinden"
> Müssten/sollten nicht die Einträge im InterfaceDescriptor für > bInterfaceClass auf vendor-specific voreingestellt werden (oder gleich > für's ganze Gerät)? > "A value of zero is reserved for future standardization." > "If this field is set to FFH, the interface class is vendor-specific. > All other values are reserved for assignment by the USB-IF" wie meinst du das bzw. um was zu erreichen, allgemein oder als hid? >> Wie verfahre ich nun weiter, wenn ich die USB mit der USBLibrary.dll per >> C# ansprechen möchte ? (http://www.codeproject.com/KB/cs/USB_HID.aspx) > > Wenn LibUSB verwendet wird: Beitrag "C# .lib (libusb) Libary einbinden" Danke für den Link, sieht sehr gut aus. >Du müsstest im Gerätemanager oder so eigentlich alles zurücksetzen >können, so dass er das Gerät wieder erkennt. Weisst du zufällig wie das geht, brings irgendwie net her, hab self und bus powered nochmal getestet und mit anderer VID, nicht funktioniert. Bootloader mit der Atmel VID funktioniert einwandfrei...
Autor: Arc Net (arc) Datum: 25.03.2008 16:29 >Müssten/sollten nicht die Einträge im InterfaceDescriptor für >bInterfaceClass auf vendor-specific voreingestellt werden (oder gleich >für's ganze Gerät)? Ich habe in meinem Code: #define UsbNoInterfaceClass 0xFF #define UsbNoInterfaceSubClass 0xFF #define UsbNoInterfaceProtokoll 0xFF #define UsbNoDeviceClass 0xFF #define UsbNoDeviceSubClass 0xFF d->bDeviceClass = UsbNoDeviceClass; d->bDeviceSubClass = UsbNoDeviceSubClass; i->bInterfaceClass = UsbNoInterfaceClass; i->bInterfaceSubClass = UsbNoInterfaceSubClass; Und cat /proc/bus/usb/devices liefert I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Soweit sollte das schon ok sein. Aber Windows wird wohl versuchen, jedes neue USB-Gerät als HID anzusprechen oder einen Treiber dafür zu laden. Aber wie wir schon herausgefunden haben ist das nicht das eigentliche Problem des Threadstarters. Derzeit wird der USB-Teil des AT90USB nicht korrekt gestartet, wenn zunächst der uC mit Strom versorgt wird, und erst dann der USB-Stecker eingesteckt wird (self-powered). Wie ich schon schrieb, ich werde das untersuchen.
Hab auch scho alle möglichen Varianten Durchprobiert, mit Self/Bus Powered, Strom zuerst, dann anstecken, Reset´s und so. Hab grad am anderen Laptop angesteckt ( auch WinxP ) und da hat sich auch nichts getan, also liegt nicht daran, dass ich bei mir im Gerätemanager verstellt habe, sondern dass wieder am Programm was nicht stimmt. Seits funktioniert hat, hab ich aber eigentl. nichts neus runtergeladen. Wo könnte das Problem liegen?
> Soweit sollte das schon ok sein. Hatte nur diesen Teil http://www.ssalewski.de/USB-Sources/usb_spec.c überflogen...
Matthias T. (maette) schrieb am 25.03.2008 um 17:37 Uhr: >Hab auch scho alle möglichen Varianten Durchprobiert, mit Self/Bus >Powered, Strom zuerst, dann anstecken, Reset´s und so. >Hab grad am anderen Laptop angesteckt ( auch WinxP ) und da hat sich >auch nichts getan, also liegt nicht daran, dass ich bei mir im >Gerätemanager verstellt habe, sondern dass wieder am Programm was nicht >stimmt. >Seits funktioniert hat, hab ich aber eigentl. nichts neus runtergeladen. >Wo könnte das Problem liegen? Also das verstehe ich jetzt nicht mehr: Du hattest geschrieben, dass es Bus-Powered funktioniert hatte, bloß das Windows über zu hohe Stromentnahme gemeckert hatte. Wenn Du natürlich noch andere große Stromverbraucher auf der Platine hast ist es klar das Windows meckert -- hättest evtl abklemmen sollen. Aber die Firmware im uC ändert sich ja nicht von allein -- wenn es einmal funktioniert hat sollte es auch wieder funktionieren. Wie man ein deaktiviertes USB-Gerät unter Windows wieder aktiviert weiß ich nicht, da musst Du die Windows-Leute fragen. Das Problem gibt es aber öfter mit USB-Festplatten an Notebooks. Ich werde versuchen eine meiner Platinen auf self-powered umzubauen und dann berichten. Zum Schluss noch ein wichtiger Hinweis: Kürzlich habe ich von einem anderen USB-Projekt für AT90USB erfahren: http://www.fourwalledcubicle.com/MyUSB.php Ich habe mir das noch nicht näher angesehen, macht aber einen guten Eindruck. Das unterstützt wohl auch HID und ist damit für Dich und andere Windows-Fans vielleicht besser geeignet. Gruß Stefan salewski
Stefan Salewski wrote: > Aber die Firmware im uC ändert sich ja nicht von allein -- wenn es > einmal funktioniert hat sollte es auch wieder funktionieren. Wie man ein > deaktiviertes USB-Gerät unter Windows wieder aktiviert weiß ich nicht, > da musst Du die Windows-Leute fragen. Das Problem gibt es aber öfter mit > USB-Festplatten an Notebooks. Geräte-Manager -> Eintrag auswählen -> "Deinstallieren" (Oder einfach auf Delete hauen) Beim nächsten Einstecken sollte es dann wieder korrekt enumieriert und installiert werden.
Der Stromverbrauch war glaub nur kurz, hab nicht viel mehr dran als denn uC, braucht sicher nicht mehr als 100 mA. Was für einen Eintrag soll ich denn auswählen? Die Platine wird mir ja nicht angezeigt? Ist ja sonst nur noch Root Hub da, aber es funktioniert ja ma anderen PC auch nicht ??? Das Projekt MyUSB hab ich mir auch schon ein wenig angeschaut gehabt, aber nachdem ich die DLL nicht in C# einbinden konnte habs ichs gelassen, hoff eigentl. immer noch, dass das hier funktioniert. HID oder nicht HID ist kein Problem.
Autor: Matthias T. (maette) Datum: 25.03.2008 18:21 >Der Stromverbrauch war glaub nur kurz, hab nicht viel mehr dran als denn >uC, braucht sicher nicht mehr als 100 mA. Hast Du evtl. einen dicken Kondensator auf der Platine? Für den USB-Bus sind maximal 10uF erlaubt, sonst ist der Strom beim Einstecken zu groß. >Was für einen Eintrag soll ich denn auswählen? Die Platine wird mir ja >nicht angezeigt? Ist ja sonst nur noch Root Hub da, aber es funktioniert >ja ma anderen PC auch nicht ??? Der Atmel-USB-Bootloader funktioniert aber weiterhin? Da müsstest Du die Plaine ja im Gerätemanager sehen. >Das Projekt MyUSB hab ich mir auch schon ein wenig angeschaut gehabt, >aber nachdem ich die DLL nicht in C# einbinden konnte habs ichs >gelassen, hoff eigentl. immer noch, dass das hier funktioniert. HID oder >nicht HID ist kein Problem. Ich bin momentan etwas ratlos. Fehler, wo es mal geht, dann wieder nicht, sind mit die unangenehmsten. (Bei meiner Platine muss ich leider einen Pin hochbiegen für den Umbau auf self-powered, daher ist meine Begeisterung nicht so groß. Ich werde es aber probieren, evtl. aber erst am Wochenende. Bist Du denn sicher, dass Du LibUSB mit C# verwenden kannst? Sonst nützt Dir die funktionierende Hardware ja eh nicht viel. Wie ich weiter oben schon schrieb, ich könnte Dir eine meiner Platinen schicken (ich habe zur Zeit zwei im Schrank liegen die ich nicht benötige.). Gruß Stefan Salewski
> Hast Du evtl. einen dicken Kondensator auf der Platine? > Für den USB-Bus sind maximal 10uF erlaubt, sonst ist der Strom beim > Einstecken zu groß. hatte einen 3,3uF vom 7805 noch dra, aber der ist jetzt auch weg und es hat sich nichts geändert. > Der Atmel-USB-Bootloader funktioniert aber weiterhin? > Da müsstest Du die Plaine ja im Gerätemanager sehen. Habe den Bootloader nicht Standardmäßig drauf, lade ihn nur hin und wieder rauf zum schauen ob USB funktioniert. Programmiere normal InSystem mit SPI. > Ich bin momentan etwas ratlos. Fehler, wo es mal geht, dann wieder > nicht, sind mit die unangenehmsten. (Bei meiner Platine muss ich leider > einen Pin hochbiegen für den Umbau auf self-powered, daher ist meine > Begeisterung nicht so groß. Ich werde es aber probieren, evtl. aber erst > am Wochenende. Ich gaube das heute morgen war auch keine wirkliche Erkennung der Hardware sondern eher ein kurzer Abrutscher von mir und dadurch ein Kurzschluss am USB, weshalb dann auch die Fehlermeldung kam. Habs grad nochmal probiert => gleiche Meldung. > Bist Du denn sicher, dass Du LibUSB mit C# verwenden kannst? Sonst nützt > Dir die funktionierende Hardware ja eh nicht viel. Wie ich weiter oben > schon schrieb, ich könnte Dir eine meiner Platinen schicken (ich habe > zur Zeit zwei im Schrank liegen die ich nicht benötige.). Die USB Verbindung ist ein Teil eine Projektes das ich mom. in der Schule mache, sollte es deshalb schon selber machen, aber danke für das Angebot - sehr nett =) Wenn ich Probleme mit ESD hätte ( Statische Aufladung hat dem uC was getan ), dann würde der ganze uC nicht gehen, oder? Oder kann es sein, dass es nur Teile ( z.b. USB ) zerstört hat oder dass dies halt nun fehlerhaft funktioniert. Werde mir nun ein AT90USB1287 bestellen und auf der neuen Platine aufbringen, MAX hab ich natürlich nun integriert. danke für die ausführliche hilfe gruß Matthias T.
>Das Projekt MyUSB hab ich mir auch schon ein wenig angeschaut gehabt, >aber nachdem ich die DLL nicht in C# einbinden konnte habs ichs >gelassen, hoff eigentl. immer noch, dass das hier funktioniert. HID oder >nicht HID ist kein Problem. Es gibt auch eine .net Implementierung von libUSB, nennt sich LibUsbDotNet. Hab ich selber schon verwendet mit meinem at90usb162 ... Aber so schwer isses auch nicht das ganze in C++ direkt zu machen ... Gruß Micha
Ja, ich verwende auch die LibUsbDotNet. Das Problem ist ja nicht ein feriges Programm in C++ ein wenig anzupassen, sondern da kommt dahinter ja ein größeres Programm mit Auswertung, Diagrammen, Tabellen etc., da möchte ich gerne bei der vertrauten Programmiersprache bleiben =) Das Problem ist nach wievor, dass es den Controller nicht annähernd am USB erkennt. gruß
Hast du eine Möglichkeit, das Geplänkel auf den Datenleitungen zu verfolgen? Damit könntest du wenigstens mal überprüfen, ob sich überhaupt was tut wenn du das Teil einsteckst, oder ob evtl. die Pull-Ups deaktiviert sind, bzw. die Pins vom Controller aktiv auf Low gezogen werden. Komisch ist ja, dass der Bootloader funktioniert, also scheint die USB-betreffende Hardware ja durchaus in Ordnung zu sein. Ein Defekt durch ESD wäre aber natürlich durchaus denkbar, damit können die seltsamsten Fehler produziert werden (Daher ist es ja auch so problematisch - manchmal). Hast du denn nur diesen einen Chip?
werd mir mal ein oszi besorgen un "schauen". hab leider kein anderen chip, bestelle aber auf die nächste platine ein at90usb1287 der müsste ja layout und programm mäßig voll kompatibel zum 64-er sein, oder ? die PullUp´s/Down´s müssten ja eigentl. durch die Firmware gesteuert werden und die funktioniert ja. mfg
Hast du mal die Beispiele von Atmel probiert (z.B. HID und MS Device). Die ließen sich bei mir ohne Probleme kompilieren und wurden auch korrekt unter WIndows erkannt etc. Manchmal sind die Beispiele von Atmel nicht so toll, aber in dem Fall haben Sie wie gesagt alle ohne Probleme geklappt. Gruß Micha
@ Matthias T. (maette) Ich habe mal eben ein Hexfile für den AT90USB647 erzeugt und auf www.ssalewski.de/tmp abgelegt. Du kannst ja mal testen ob das funktioniert. Das ist meine Firmware, mit deaktiviertem Debugging-Code für AT90USB647. Und probier sonst mal, wie Michael Kentschke schrieb, ob Du den Atmel Code zum laufen bekommst. Gruß Stefan Salewski
hallo, danke für das File, hat leider nicht funktioniert. Dein sudd.hex und mein sudd.hex sind fast exakt gleich groß ( 16Byte unterschied ). Hab ein paar kleine Unterschiede beim Port. Das mit den Atmel Programmen hatte ich davor schon vergeblich versucht und habs jetzt nochmal probiert, leider keine Reaktion.
Was ich nur nicht so richtig verstehe ist, das es mit dem Bootloader über Flip funktioniert. Das weißt doch eindeutig auf eine funktionierende Hardware hin. Dementsprechend ist es wirklich komisch das selbst die einfachsten Beispiele von Atmel nicht erkannt werde. Hast du es mal an einem anderen Rechner probiert ??? Gruß Micha P.S. hab jetzt nich alles im Detail gelesen .. aber bei Software USB (obdev) hatte ich früher auch immer mal die Meldung von Windows wecken überspannungsschutz ... soll heißen da reicht schon der kleinste Wackler ... :) .. und z.b. reicht ja schon der widerstand an d+ (oder d-, je nach dem ob full oder low speed) das windows sagt "unbekanntes gerät" ...
>Das mit den Atmel Programmen hatte ich davor schon vergeblich versucht >und habs jetzt nochmal probiert, leider keine Reaktion. Na dann liegt es ja wohl nicht an meiner Firmware. Gut für mich, insbesondere gut für mich, dass ich noch nicht versucht habe, eine meiner Platinen mit Gewalt auf self-powered umzubiegen. Passen würde jetzt noch, dass Dein Takt nicht 16 MHz ist. Denn Atmels Bootloader past sich dem Takt an, meine Firmware nicht. Bei den Atmel-Beispielen weiss ich es nicht, aber ich würde denken, dass man dort auch die richtige Taktfrequenz einstellen muss. Daher meine Frage nach Taktfrequenz ganz zu Anfang. Aber Du sagst ja 16 MHz, was ok wäre. Du schreibst was wie "LED toggled mit 2 MHz" -- naja, kommt drauf an wie die Schleife programmiert ist. Könnte auch mit 8 MHz gehen. Wenn der Quarz falsch bedruck wäre? Oberwellenquarz wird es wohl nicht sein, da hat man ja 8 statt 24 MHz. Vielleicht doch ein exotischer Hardwaredefekt, der aus irgend welchen Gründen beim Bootloader nicht auftritt? Ich habe jetzt keine weiteren Ideen mehr. Solche Ferndiagnosen sind schon recht schwierig.
> Hast du es mal an einem anderen Rechner probiert ??? Ja, habs an einem anderen Laptop und unter Linux probiert. > P.S. hab jetzt nich alles im Detail gelesen .. aber bei Software USB > (obdev) hatte ich früher auch immer mal die Meldung von Windows wecken > überspannungsschutz ... soll heißen da reicht schon der kleinste Wackler > ... :) .. und z.b. reicht ja schon der widerstand an d+ (oder d-, je > nach dem ob full oder low speed) das windows sagt "unbekanntes gerät" Windows meldet eben nicht unbekanntes Gerät, sondern zu hoher Energieverbrauch, das kommt auch schon wenn nur was Kabel dort hängt und man einen Kurzen macht. >Passen würde jetzt noch, dass Dein Takt nicht 16 MHz ist. Ich werde das heute nochmal mit dem Oszi betrachten, es gibt ja ein Port an dem man den Clock ausgeben lassen kann. Ferndiagnosen sind in der Tat sehr schwirig, aber danke für die hilfe. Habe mit jetzt den 128-er bestellt und werde den auf mein neues Board montieren. Vielleicht wars einfach nur ein blöder Fehler. Danke an alle für die Hilfe Matthias
So, habe heute mit dem Oszi am Usb geschaut, da tut sich einfach nichts. Schätze ein Hardware defekt, oder sonst was verzwicktes =) Habe heute meinen neuen at90usb1287 bekommen, der wird gleich morgen Verbaut und dann teste ich das ganze nochmal ;) danke nochmal für die Hilfe melde mich morgen wieder. gruß Matthias
hallo, hab jetzt das Board mit dem AT90USB1287 aufgebaut, eingesteckt und hat sofort einwandfrei funktioniert =)
Matthias T. (maette) schrieb am 29.03.2008 um 12:47 Uhr: >hallo, >hab jetzt das Board mit dem AT90USB1287 aufgebaut, eingesteckt und hat >sofort einwandfrei funktioniert =) Das freut mich (für Dich). Es wäre natürlich schon interessant, herauszufinden was das Problem mit dem anderen Board/Chip war. Das Atmels USB-Bootloader funktioniert hat, alles andere aber nicht, ist schon höchst eigenartig. Es gibt ja eine Reihe von Berichten (auch hier im Forum) von Leuten, die mit selbst gebauten Boards für AT90USB1287 seltsame Probleme hatten. Leider haben die dann nichts mehr von sich hören lassen. Gruß Stefan Salewski
puh, schwierig zu sagen, vielleicht wars ja ein seltsamer Hardware defekt ? Noch eine neue Frage kann es sein, dass ich für meinen uC einen Kühlkörper brauche, ich weiss klingt komisch, aber hab ihn grad ( ausversehen ) ein paar Stunden laufen lassen und der war so heiss, dass man ihn nicht mehr angreifen konnte. Wie gehts euch wenn er mehrere Stunden läuft ? Schätze sind so um die 12 std gewesen. gruß Matthias
Also ich kann nur für den AT90USB162 reden, und der wird auch nach einigen Tage nicht annähernd warm, so wie man es von fast allen AVRs gewohnt ist ;-). Soll heißen irgendwas stimmt da bei dir nicht, weswegen vielleicht auch der 64er ne Macke bekommen hat :) Gruß Micha
>Noch eine neue Frage kann es sein, dass ich für meinen uC einen >Kühlkörper brauche Nein. Bei mir wird der AT90USB1287 nicht merklich warm. P=20mA*5V=100mW, damit sollte er nicht warm werden. Wenn permanent Datenübertragung über USB stattfindet wird er evtl. etwas wärmer werden, aber heiß sollte er nicht werden. Da stimmt etwas in Deiner Schaltung nicht.
wird deiner nicht warm weil er quasi von der umgebungsluft gekühlt wird oder sollte allgemein nicht war werden? Meiner ist auf der unterseite der Platine und hat ein paar Millimeter Abstand zur Unterlage, kann das sein, dass das zu wenig ist ? mfg PS.: Daten sollten nicht gesendet worden sein - normal hat er dann genug abstand, ist mom nur zu test zwecken.
Also ich würde mal sagen der wird einfach nicht warm. Ich kann mir nicht vorstellen das das io ist wenn deiner so warm wird das man ihn fast nicht mehr anfassen kann, egal wieviel platz da nach unten oder oben ist. Da stimmt meiner Meinung nach irgendwas nicht. Meiner läuft wie gesagt Tage im Dauerbetrieb mit Aktivitäten und da wird nie irgendwas warm. Wie auch bei allen anderen AVRs die ich benutze. Gruß Micha
wie kann ich eigentl. einfach 64 Byte über EP02 schicken, also wenn ich die Daten auf einmal zur Verfügung habe und sie nicht durch einen Timer gefüllt werden?
Kann es sein, dass die Temperatur stark von der aktivität abhängig ist? Ich weiss nicht genau wann, aber abundzu ist er einfach so heiss, dass man ihn nicht mehr angreifen kann ( kurz nach dem einstecken ) und manchmal einfach nur lauwarm. Hat jemand eine Idee, kann das mit der USB auslastung zusammenhängen ?
>Ich weiss nicht genau wann, aber abundzu ist er einfach so heiss, dass >man ihn nicht mehr angreifen kann ( kurz nach dem einstecken ) und >manchmal einfach nur lauwarm. >Hat jemand eine Idee, kann das mit der USB auslastung zusammenhängen ? Was der USB Datentransfer an zusätzlicher Leistung verbraucht weiß ich so aus den Kopf nicht. Aber ich denke wie Michael Kentschke, dass in deiner Schaltung ein Fehler sein wird. Hast Du wie im Datenblatt angegeben auch den AVCC Pin angeschossen (an VCC)? Wird er im self- oder im Bus-powered Betrieb so heiß?
Er wird im Bus-Powered betrieb so heiss, den AVCC hab ich über den LC Tiefpass angeschlossen.
>Er wird im Bus-Powered betrieb so heiss, den AVCC hab ich über den LC >Tiefpass angeschlossen. Du hast ihn also angeschlossen wie im Datenblatt angegeben (bzw. so wie auch meine Platine beschaltet ist) und Du hast auch sonst nichts auf der Platine, das für den uC eine große Last darstellen könnte? Dann sollte er wie gesagt nicht sehr warm werden. Möglich wäre, dass er intern einen Fehler hat, oder dass Du einen Pin als Ausgang programmiert hast und diesen irgendwie kurz geschlossen hast. Wenn Eingangspins auf undefinierten Potential liegen ist das auch ungünstig. Aber wenn Du sie nicht explizit anders programmiert hast, sollten die IO-Pins als Eingang mit aktiviertem Pullup programmiert sein, das sollte unkritisch sein. Eigentlich hat das heiß-werden nicht direkt etwas mit USB Funktionalität zu tun -- vielleicht suchst Du mal selbst nach Stichworten wie "AVR heiß" oder startest einen neuen Thread zum Thema. (Hier lesen wohl nicht mehr so viele mit.)
1 | |
2 | RB_Init(); |
3 | uint16_t w = 2007; |
4 | for(uint8_t j = 0; j <= 64(32); j++) |
5 | {
|
6 | |
7 | RB_Write(w); |
8 | |
9 | |
10 | UsbDevSelectEndpoint(2); |
11 | if (UsbDevTransmitterReady()) |
12 | {
|
13 | |
14 | w = RB_Read(); |
15 | //w = cnt; dump counter to FIFO for testing
|
16 | UsbDevWriteByte(LSB(w)); |
17 | UsbDevWriteByte(MSB(w)); |
18 | |
19 | if ( j == 64(32) ) |
20 | {
|
21 | UsbDevClearTransmitterReady(); |
22 | UsbDevSendInData(); |
23 | }
|
24 | |
25 | }
|
26 | |
27 | }
|
müsste das so eigentl. nicht funktionieren Daten über EP02 zu schicken? ist ungefähr das von daq_dev.c nur hab ich eben auf einmal zur Verfügung. Dass es nicht stimmt und warsch. ziemlicher blödsinn ist, was ich da geschrieben habe weiss ich, kann mir jemand bitte kurz ein Anhaltspunkt geben, wie ich mehr daten ( > 40 Byte ) über EP02 schicken kann. Es sollte ja am PC auch ein Recived Event erzeugen oder? EP01 funktioniert einwandfrei. danke für jede Hilfestellung
EDIT: hab oben das switch innerhalb vom if transmready vergessen :
1 | switch (UsbDevGetByteCountLow()) |
2 | {
|
3 | default:
|
4 | w = RB_Read(); |
5 | UsbDevWriteByte(LSB(w)); |
6 | UsbDevWriteByte(MSB(w)); |
7 | break; |
8 | case 64: |
9 | UsbDevClearTransmitterReady(); |
10 | UsbDevSendInData(); |
11 | }
|
ändert aber nichts :(
da kann ich lang probieren, problem lag software seitig beim OnDataReceivedDelegate, tztz =) danke, danke jetzt funzts grüße
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.