Wir haben ein USB-Problem (Steuerung komplexer Meßtechnik von einem PC aus, der unter WinXP embedded läuft) und wissen nicht mehr weiter :-( Somit suchen wir evtl. einen "Externen", der sich in dieser Materie voll auskennt, der auch Analysemöglichkeiten auf Hardwareebene hat und ebenso die XPe-Kenntnisse mitbringt, um da wirklich alle Seiten betrachten zu können.
Wer jemanden kennt oder sich berufen fühlt und auch evtl. noch mehr Fakten wissen muß - bitte unbedingt bei mir melden, gerne hier oder per email.
"Ralph A. Schmid, DK5RAS" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com... ..
hi, welcher usb-chipset? welche art hub? bus-powered oder selfpowered?
das kann eine chipsatzabhaengige problematik sein. aber auch einfach ein stoerungsproblem. nehmt mal andere kabel, dediziert fuer usb2.0, solche, wo an beiden seiten die abschirmung an den stecker drangeloetet ist. kann man meist durchs plastik hindurch erkennen. und nicht zu lange kabel nehmen. und mal einen usb-hub, selfpowered, dazwischenhaengen. soein hub erspart einem viel aerger.
klingt irgendwie nach diesem usb-id#-kram, ne doppelbelegung vielleicht? bin dafuer nicht informiert genug, aber da gabs mal kuerzlich nen selbstbau fuer eine usb-anzeige inner ct, da haben die sowas erwaehnt. soein mini-tft als playerschirm. da wurde allerlei usb getellt.
--
unter allervorzüglichster Höchstachtung,
gUnther
Probiere doch mal, beiden USB+ und USB- Leitungen nahe Deiner Messeinheit kleine Kondensatoren gegen Masse zu spendieren, so 22..47pF.
Bei bestimmten populären USB Interface-Chips bewirkt das manchmal Wunder bei einem ähnlichen Fehlerbild.
Ansonsten hilft wohl nur, Hard- und Software systematisch auf den Kopf zu stellen und den USB mit einem DSO mit sehr tiefen Speicher zu überwachen, so die Hardware zickt. Auf der Softwareseite gibt es einige frei verfügbare Debug-Tools aus dem Netz.
USB Snoopy (Pro) hat mir schon sehr gute Dienste geleistet, ist auch das Standardtool für sämtliche Reverse Engineering zwecks Linux-Treibererstellung.
Insb. USB-Controller von VIA und SiS sind da mit Vorsicht zu geniessen. VIA hatte ewige Zeiten über viele Chipsatzgenreationen massive Probleme mit der rechtzeitigen PCI-Arbitrierung, sodass andauernd Daten verloren gegangen sind. Und SiS hat spontan alle Ports verloren und erst mit einem HC-Treiberreset wieder gefunden. Die einzige Abhilfe war ein Board mit Intel-Chipsatz.
Meine Erfahrungen seit 1999 zu USB insgesamt sind aber: Für zuverlässige Datenkommunikation (Monitoring, Mission-Critical) ist USB einfach ungeeignet. Man muss einen Sch....-Aufwand in der SW treiben (Treiber, Überwachung der Hostcontroller, etc.) treiben, damit es zumindest ohne manuellen Eingriff dauerläuft. Aber hakeln tuts immer.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Haben wir; ist aber kabelunabhängig, dahingehend haben wir bereits experimentiert.
50cm. Und richtig teures Markenzeugs, nix von Reichelt oder so. Wie gesagt, Industrieeinsatz, da wird an nix gespart.
Keine Ahnung, ob wir hier in der Firma sowas haben, es soll auch definitiv nicht noch ein hub rein.
Jedenfalls habe ich jetzt den offiziellen Auftrag, da mal weiterzuforschen. Somit bin ich nicht mehr auf Hörensagen angewiesen, sondern kann mir die betroffenen Geräte schnappen und mich daran austoben. Werde das heute oder morgen mal angehen und ggf. wieder berichten.
Ich hasse USB - das habe ich auch geäußert, worauf es gleich hieß, "dann bist Du der richtige Mann dafür" *grummel*
Hast Du denn mal das USB-Signalpaar mit einem guten DSO vermessen ?
Gerade USB ist eigentlich _die_ Anwendung für die Tek und LeCroy "DPO" bzw. "Analog"-Funktionen und Jitter-Analyse-Funktionen, um Störungen zu visualisieren.
Einfach die Bits "analog" aufeinander synchronisieren, Ausreisser werden dann sofort farblich sichtbar, durch das Bit-Stuffing gibt es auch sicher genügend Sync.-Möglichkeiten.
Nur zum Test. Versuch macht klug.
USB ist _eigentlich_ ein ziemlich simples Protokoll.
Leider hat man noch mehr an der HW als am Protokoll gespart. Standardreaktion auf ESD-Störungen oder sowas ist erstmal ein Disconnect mit anschliessender Re-Enumeration. Wenn man Glück hat (und gute Gerätetreiber samt Protokollstack) kann man nach einer Schaffenspause von 2-3s wenigstens weitermachen.
Und Windows hat die Marotte, jeden jemals in der Hub-Hierarchie benutzten Port samt Treiberinfos in der Registry zu merken und das dann auch noch für jede einzelne Seriennummer eines Gerätes. Schon das erneute, verwürfelte Anstecken von ca. 30 gleichen Geräten mit unterschiedlicher Seriennumer legt auch GHz-PCs sehr lange mit richtiger CPU-Last lahm, >50 Geräte sind indiskutabel.
Aus so einem Grund ist bei einem Gerät die Seriennummer im Deskriptor wieder rausgeflogen und muss (weil für die Anwendung wichtig) über ein proprietäreres Protokoll erfragt werden.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Das ist an der aktuellen Installation nur mal ansatzweise durch einen Kollegen geschehen, wird aber durchgeführt, sofern nicht andere Ursachen experimentell ermittelt werden können; erst mal auf die Schnelle, wer der Bösewicht ist.
Das kommt, sobald ich den Kram zerpflücke.
Ja, _eigentlich_ :-)
Noch am Rande, eben mal eruiert, mainboard Commell LV-671, der Chipsatz ist ein Intel GME855 (USB "kommt aus" dem DBM82801), und "unser" USB-Chip (im Messgerät) ist von Cypress. Funktioniert auch alles bestens, solange der PC nicht irgendwelche weiteren Geräte angeklemmt bekommt.
Interessant wäre ein Tool, das die Register des DBM82801 ausliest und anzeigt, der speichert offenbar in diversen Registern diverse Ereignisse am USB, und unsere ENtwicklers haben derzeit weder Zeit noch Nerv, da auch noch ein tool zu programmieren. Sollte man meinen, sowas gibt es bereits?! Bisher haben wir nix gefunden...werde da noch ein wenig forschen und googeln.
Es ist halt ein Ersatz für serielle Schnittstellen.
Mehr nicht. *
Dafür ist es relativ universell und eben so einfach, dass es selbst für die 3 Euro Maus taugt.
Wer mehr Leistung wünscht, sollte einen LAN-Port in das Gerät einbauen.
Ich weiß natürlich, dass für TCP/IP ungleich mehr Know How erforderlich ist. Irgendwann will man dann auch echtes Routing (*) und dann wird es lustig ;-/
Gruß Oliver
P.s.: (*) Dieses Posting wurde über ein Backbone Routing System "Made in Germany" per BGP4 geroutet :-)
"Georg Acher" schrieb im Newsbeitrag news:e9ibun$3br$ snipped-for-privacy@news.lrz-muenchen.de... ..
VIA hatte
hi, fuer usb2.o nec rulez :-)
sind.
naja, schon, dafuer sterben diese intel gerne an ueberstrom oder surges, manchmal reicht schon, ein selfpowered-usb-geraet waehrend der kommunikation vom eigenstrom zu trennen. man sollte es nicht glauben. und sis sind mit hubs sehr unzufriedenstellend, doch externe platten rennen damit wie schmitzens lizzie... via ist einfach nur lahm. und gelegentlich instabil. naja, wen wunderts. sind ja auch mit abstand die billigsten. wenn man ali mal ganz weglaesst.
ungeeignet. Man
ja. aber man kriegt ja auch was dafuer. wenn man wirklich stabile dauerverbindung haben muss, waere der aufwand fuer ethernet ja wohl nicht zuviel. oder i2c.
--
unter allervorzüglichster Höchstachtung,
gUnther
Die Entscheidung für USB vor ein paar Jahren wurde hier schon durchaus bereut :)
Nun ja, eine einfachste Verbindung erfordert zwar vielleicht urprünglich mehr Programmieraufwand, aber dafür benötigt man weniger workarounds im Nachhinein.
|> Interessant wäre ein Tool, das die Register des DBM82801 ausliest und |> anzeigt, der speichert offenbar in diversen Registern diverse |> Ereignisse am USB, und unsere ENtwicklers haben derzeit weder Zeit |> noch Nerv, da auch noch ein tool zu programmieren. Sollte man meinen, |> sowas gibt es bereits?! Bisher haben wir nix gefunden...werde da noch |> ein wenig forschen und googeln.
(Muss ich doch mal mein Wissen als Programmierer des Linux-UHCI-Treibers loswerden...)
Es kann da nichts sinnvolles geben, weil USB-Hostcontroller wie zB. UHCI von Intel/VIA per DMA-Chaining funktionieren und der gesamte DMA-Deskriptorbaum (jawohl, Baum, nicht nur Liste) ein sehr dynamisches Gebilde ist. Sowohl vom Treiber als auch vom Hostcontroller selbst werden da kontinuierlich Pointer umgehängt und Flags verändert. Der grösste Teil des Baums wird pro ms einmal durchlaufen. Das Endergebnis kommt dann von HC-Treiber in den URBs zurück. Wenn du damit den Fehler nicht siehst, brauchst du einen HW-Analyser.
Unter Linux ist es (oder war es mal) möglich, den Baum auszugeben, das war aber eher was fürs statische Debugging mit genau einem Problemdevice. Für alles andere war es untauglich.
Und die paar statischen Register sind da recht langweilig. Hauptsächlich der Portstatus des Root-Hubs. Der wirds aber wohl nicht sein, ausser du bekommst spontane Neu-Enumerierungen.
Falls dir mal langweilig ist, kannst du die UCHI-Spec durchlesen:
formatting link
;-)
Meine Meinung:
Wenn das Problem HC-übergreifend ist und mit anderen Mainboards mit anderen Controllern nicht auftritt, ist es ein HW-Bug. Nahezu aussichtslos, da was zu fixen. Eine extra USB-Karte kann helfen, muss aber nicht.
Wenn es auf anderen Mainboards auch auftritt, ist es wahrscheinlich ein Treiberproblem. Wenn's der Windows-Stack ist, dann Pech gehabt, da sind so manche Haken schon länger ungefixt. Wenn's der eigene Gerätetreiber ist, dann viel Spass beim Debuggen. Meistens stimmt was mit den Locks nicht, die Sampletreiber vom SDK sind da auch nicht fehlerlos...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
So, falls noch jemand etwas beizutragen hat, ich werde hier mal den Stand meiner Untersuchungen vermelden.
Nochmal zur Erinnerung, wenn ein USB-Port mit dem Meßgerät verbunden ist, dann funktioniert die Kommunikation mit dem Meßgerät wunderbar und fehlerfrei, aber weitere USB-Geräte (USB-sticks, die als externes Speichermedium dienen sollen) an den drei anderen herausgeführten Ports funktionieren nicht, nur zögerlich, oder nur eingeschränkt.
Der Fehler tritt an zwei Geräten auf, wo nicht (wie sonst üblich) Meßgerät und PC mechanisch zu einer Einheit verschraubt sind. Allerdings sitzen beide Einheiten in dem gleichen Stahlblechgehäuse, Erd-Potential ist somit eindeutig identisch, auch die Kabelwege sind identisch, nur eben etwas verlängert. Das USB-Kabel ist im einen Gerät eine standard-5m-Variante von Lindy (die Überlänge ist aufgerollt), im anderen Gerät 2-3m lang und von Phönix in CAT7 (taugt CAT7 für USB2.0??) ausgeführt, ausgestattet mit industriellen USB-Verbindern. Was mir von Anfang an Schmerzen bereitete, die USB-Kabel verlaufen parallel zu den Netzkabeln, so richtig "dicht an dicht".
Das Gerät mit dem Phönix-Kabel kann ich noch nicht begutachten, da komme ich erst später oder morgen ran. Das Gerät mit dem Lindy-Kabel habe ich gerade in der Mache und bin zu dem Ergebnis gekommen, daß der Fehler genau dann auftritt, wenn ich besagtes 5m-Kabel verwende. Nehme ich ein neues, baugleiches Kabel aus dem Regal und lege es lose ins Gerät, ähnlich der Verlegung des Originalkabels, dann tritt ebenfalls das Problem auf. Verändere ich die Lage des Kabels, dann kommt es mir vor, als würde sich das Verhalten ein wenig bessern, aber der Einfluß ist wenig spezifisch, und es kann Zufall sein, oder nur eine geringe Tendenz.
Nehme ich nun deutlich kürzeres Kabel, dann funktioniert alles. Nehme ich ein deutlich längeres Kabel, dann funktioniert alles. Verlängere ich das vorhandene Kabel mit Verlängerungen auf 10 oder 15 (!) m, dann funktioniert alles. Schalte ich zwischen Original-Kabel und Rechner einen hub, dann funktioniert alles, egal, ob mit oder ohne externer Stromversorgung.
Auf dem Mainboard befinden sich keine Filterelemente (Spulen etc.) in den USB-ports; die lötpads dafür sind vorhanden, aber mit vierfach-Null-Ohm-arrays. Reflexionsstelle? Übersprechen? Gefällt mir nicht. Ansonsten, die Verfolgung der Leiterbahnen ergab, daß keine rechten Winkel vorhanden sind, der Abstand paßt, leider wird mindestens einmal das layer gewechselt, und Einhalten von crossing planes-Konditionen kann nicht nachverfolgt werden.
Auf unserem Meßgerät gehen D+ und D- direkt aus dem Cypress Cy7C68013 zum connector zur backplane, auf welcher der USB-Anschluß sitzt. Ich kann es aufgrund der etwas rudimentären Doku gerade nicht verifizieren, aber laut Entwickler des Meßgeräts benötigt besagtes IC keine Serienwiderstände in D+ und D-, auch auf dem Evaluationsboard sind keine vorhanden.
Die Verbindung mit dem Meßgerät läuft zwingend mit 480mbit/sec, die Möglichkeit langsamerer Übertragung ist in der Firmware gar nicht erst vorgesehen, da die hohe Datenrate essentiell benötigt wird.
Am Lindy-Kabel mißfällt mir, daß keine specs des Kabelherstellers aufgedruckt sind, sondern nur "LINDY USB 2.0 High Speed Cable 5m //
formatting link
" - keine Angaben zu Kabelklasse, Drahtstärke, Schirmung etc.
Meine vorgeschlagene vorläufige Lösung des Problems: Einfach ein anderes Kabel verwenden, mit dem alles funktioniert. Bleibt die Frage: Warum zum Geier schafft es "irgendwas" auf einem USB-Port, die anderen Ports des mainboards lahmzulegen bzw. massiv zu behindern?
Es ist unbefriedigend, an den Symptomen herumzudoktern, ohne einen Blassen zu haben, woher das Problem kommt.
Diese Notiz in etwas, äähm, sachlicherer Form werde ich dann auch intern zur Diskussion stellen :-)
Dürfte eher nicht das Problem sein, da twisted pair.
Klassischer Ärger mit Reflexionen.
Ah, jetzt kommt Butter zum Fisch, Du nutzt USB High Speed ;-)
480MBit/s ist natürlich schon eine Datenrate, bei der man es mit der Impedanz sehr genau nehmen sollte.
Lass uns doch mal rechnen:
480 MBit/s sind ca. 2,1ns pro Bit.
Das Licht schafft in der Sekunde ca. 300000km, auf dem Kabel das Feld weniger, pi mal Daumen 200000km.
Dein Bit hat ergo eine Länge von ca. 42cm, auf 5m Kabel (f)liegen 12 Bits (!) gleichzeitig.
Wenn dann beispielsweise die Leiterbahnen zwischen dem USB-Stecker und dem IC nicht blitzsauber
*** mit der richtigen Impedanz *** geführt sind, gibt es Bitmix (eben mit reflektierten Bits, es sind ja mehrere gleichzeitig auf dem Kabel). Ein längeres Kabel kann diese Reflexion dämpfen.
=> Vergiss die Kondensatoren, die braucht es für kleinere Datenraten.
=> Prüfe, ob die USB+/- Leiterbahnen unter Berücksichtigung des epsilon_r des Basismaterials und des Abstandes zur Power-Plane die richtige _Breite_ für 45 Ohm Wellenwiderstand nach Masse haben.
=> Messe mit einem _guten_ DSO, ob Reflexionen auftreten ( Das DSO hatte ich schon mal erwähnt, gut heißt hier gut und heißt und meint nicht 1500 ? Billigware. Mit DSO rede ich von LeCroy oder _großen_ Tek. ) In Figure 7-12 des USB 2.0 Standards ist eine mögliche Messschaltung beschrieben, oder Du gehst mit einer *echten* High Speed Probe (ggf. differential) auf das Kabel.
Eigentlich möchtest Du GigE nutzen ;-)
... bis das Wetter umschlägt.
Wie schon beschrieben: Datenfehler können zu einem kompletten Neuaufsetzen des USB führen.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.