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

Der Widerstand muss 1K5 groß sein.

lies hier, wies geht:
http://www.beyondlogic.org/usbnutshell/usb2.htm#Electrical

>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