USB Verbindung stürzt ab

[Rama (Gast)]

Hallo,
ich habe ein Problem mit der USB Verbindung zwischen meinem VB.net 
Programm und meinem PIC4553.
Die Messdaten die der PIC mißt schicke ich über USB an den PC und zeige 
sie dann dort in dem VB Program an, das ganze funktioniert auch. Lieder 
bricht die Verbindung dann aber irgendwann einfach ab, der Controller 
läuft aber weiter. Wann dies geschieht konnte ich leider nicht 
nachvollziehen, es scheint jedoch was damit zu tun zu haben wann ich die 
Netzspannung von meinem Gerät in dem der PIC verbaut ist zu- bzw. 
wegschalte.
Wenn ich nach dem Absturz der Verbindung Daten vom PC zum PIC senden 
möchte kommt die Fehlermeldung:

Unbehandelte Ausnahme in der Anwendung. Klichen Sie auf "Weiter", 
um den Fehler zu ignorieren und die Anwendung fortzusetzten. 
Wenn Sie auf "Beenden" klicken, wird die Anwendung sofort Beendet.
Das Gerät ist nicht angeschlossen.

Unter Details steht dann:

Informationen über das Aufrufen von JIT-Debuggen
anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.

************** Ausnahmetext **************
System.IO.IOException: Das Gerät ist nicht angeschlossen.

   bei System.IO.Ports.InternalResources.WinIOError(Int32 errorCode, String str)
   bei System.IO.Ports.SerialStream.EndWrite(IAsyncResult asyncResult)
   bei System.IO.Ports.SerialStream.Write(Byte[] array, Int32 offset, Int32 count, Int32 timeout)
   bei System.IO.Ports.SerialPort.Write(Byte[] buffer, Int32 offset, Int32 count)
   bei NPG.frmMain.cmdReadClock_Click(Object sender, EventArgs e) in D:\mst\Netzprüfgerät\vb_Software\Netzprüfgerät_V2\frmMain.vb:Zeile 297.
   bei System.Windows.Forms.Control.OnClick(EventArgs e)
   bei System.Windows.Forms.Button.OnClick(EventArgs e)
   bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   bei System.Windows.Forms.Control.WndProc(Message& m)
   bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
   bei System.Windows.Forms.Button.WndProc(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Geladene Assemblys **************
mscorlib
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll.
----------------------------------------
NPG
    Assembly-Version: 1.0.0.0.
    Win32-Version: 1.0.0.0.
    CodeBase: file:///D:/mst/Netzpr%FCfger%E4t/vb_Software/Netzpr%FCfger%E4t_V2/bin/Release/NPG.exe.
----------------------------------------
Microsoft.VisualBasic
    Assembly-Version: 8.0.0.0.
    Win32-Version: 8.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll.
----------------------------------------
System
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll.
----------------------------------------
System.Windows.Forms
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.
----------------------------------------
System.Drawing
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.
----------------------------------------
System.Runtime.Remoting
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll.
----------------------------------------
ZedGraph
    Assembly-Version: 5.1.5.28844.
    Win32-Version: 5.1.5.28844.
    CodeBase: file:///D:/mst/Netzpr%FCfger%E4t/vb_Software/Netzpr%FCfger%E4t_V2/bin/Release/ZedGraph.DLL.
----------------------------------------
Microsoft.VisualBasic.PowerPacks.Vs
    Assembly-Version: 9.0.0.0.
    Win32-Version: 9.0.30729.1.
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic.PowerPacks.Vs/9.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.PowerPacks.Vs.dll.
----------------------------------------
ZedGraph.resources
    Assembly-Version: 5.1.5.28844.
    Win32-Version: 5.1.5.28844.
    CodeBase: file:///D:/mst/Netzpr%FCfger%E4t/vb_Software/Netzpr%FCfger%E4t_V2/bin/Release/de/ZedGraph.resources.DLL.
----------------------------------------
System.Management
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Management/2.0.0.0__b03f5f7f11d50a3a/System.Management.dll.
----------------------------------------
System.Windows.Forms.resources
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.
----------------------------------------
mscorlib.resources
    Assembly-Version: 2.0.0.0.
    Win32-Version: 2.0.50727.3053 (netfxsp.050727-3000).
    CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll.
----------------------------------------

************** JIT-Debuggen **************
Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der
Konfigurationsdatei der Anwendung oder des Computers
(machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden.
Die Anwendung muss mit aktiviertem Debuggen kompiliert werden.

Zum Beispiel:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten
Ausnahmen an den JIT-Debugger gesendet, der auf dem
Computer registriert ist, und nicht in diesem Dialogfeld behandelt.

Vielleicht kann einer von euch damit was anfangen und mir einen Tip 
geben warum die Verbindung abstürzt.

Gruß Martin

[René K. (king)]

Das liegt an der Natur der Sache: Wenn der Port nicht mehr da ist, z.B. 
durch Verlust der Betriebsspannung am Gerät oder durch Abziehen der 
USB-Leitung, kannst Du eben nicht mehr mit diesem Arbeiten. Das gilt 
auch dann, wenn der Port, bzw. das Gerät, wieder verfügbar wird. Du 
musst in diesem Falle zunächst den bereits geöffneten Port schließen. 
Danach kannst Du ihn, so er wieder verfügbar ist, erneut öffnen.

[Rama (Gast)]

Moin René,
danke für deine Antwort. Die Versorgungsspannung bleibt vorhanden, auch 
wenn ich die Netzspannung zu- bzw wegschalte. Mit dem Oszilloskop kann 
ich zwar bei der 5V Versorgung einen Störimpuls messen, jedoch ist 
dieser ist in gleicher größe messbar wenn die Verbindung abbricht oder 
eben auch nicht abbricht.

[adfix (Gast)]

Wir hatten mal ähnliche Probleme.
Ab und zu Bluescreen. Absturz. An manchen Rechnern gings besser als an 
anderen.

Wir hatten am FTDI einen Resonator mit 1-2% Toleranz.
Gegen Quarz getauscht. Nie mehr Probleme.

Die 1-2% waren wohl zuviel Toleranz für USB.

[René K. (king)]

Woher kommt die Spannung am 1,5 kOhm PullUp-Widerstand? Bekommt dieser 
den Störer auch mit?

[oszi40 (Gast)]

Wundersame Effekte könnten auch bei schwächlicher 5V-Versorgung 
eintreten.
Zur Gegenprobe an anderm PC/USB-Port testen.

[Rama (Gast)]

Den Controller berteibe ich mit einem Quarz, es sollte also nicht an der 
Genauigkeit der Freqeunz liegen.

An den USB-Datenleitunge habe ich keinen externen Pull-Up dran sondern 
benutze den internen des PIC. Die nötige Spannung wird auch durch den 
internen 3,3V Regulator erzeugt. Wenn ich diese messe sind dort auch 
Störungen drauf wenn ich Die Netzspannung zu bzw abschalte. Diese sind 
aber nicht größer als wenn ich eine Messung starte und beim 
Messungsstart stürzt die Verbindung nie ab.

Das Gerät wurde auch schon an unterschiedlichen PCs getestet und auch 
mit an einem Hub mit extra Spannungsversorgung. Leider ohen 
Verbesserung. Ich habe sogar das gefühl das die Verbindung häufiger 
abstürzt wenn ich den Hub benutze.

[René K. (king)]

Ein Gerät wird als nicht angeschlossen erkannt, wenn Du den PullUp 
abnimmst. Wenn Du hier Störungen hast, wird er schnell mal als 
abgenommen erkannt. Je nach Host und Mondphase passiert es dann mal, mal 
auch nicht. Und das sich der Hub anders als der PC verhält, ist durchaus 
denkbar.

Hast Du den internen Regler denn wenigstens mit der Spannung des Busses 
verbunden (<-- Bedingung für den PullUp)? Vielleicht hast Du das 
automatisch so gemacht, aber da ich den Controller nicht kenne und die 
Suche nach "PIC4553" auf der Microchip-Site keine Treffer liefert...

Ansonsten: Pack doch einfach mal einen Kondensator zwischen Masse und 
dem Gehäuse Deiner USB-Buchse, z.B. 10 nF. Hast Du sonst noch 
Widerstände/Kondensatoren auf den Datenleitungen?

[Rama (Gast)]

Der interne Regler ist mit der Spannungsversorgung der Microcontrollers 
verbunden.
Hier ist ein Link zu dem Datenblatt des Controllers. Das ist zwar für 
den PIC18F4550 gilt aber auch für den 4553. In dem extra Datenbalatt für 
den 4553 steht nur der AD-Wandler beschrieben der rest ist gleich.
http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf

Die USB-Buchse ist direkt mit Masse verbunden. In den beiden 
Datenleitung ist jeweils ein Tiefpass mit einem 22 Ohm Widerstand und 
einem 47pF Kondensator. Auch der Controller selbst ist mit Kondesatoren 
gepuffert. Leider tretten dort trotzdem Störungen auf.

[René K. (king)]

Rama schrieb:
> Der interne Regler ist mit der Spannungsversorgung der Microcontrollers
> verbunden.

Wo kommt die Spannungsversorgung her, kommt die aus dem Bus? Für den 
PullUp gilt nach der Spezifikation 2.0 unter 7.1.5.1: "The voltage 
source on the pull-up resistor must be derived from or controlled by the 
power supplied on the USB cable..."

Rama schrieb:
> Die USB-Buchse ist direkt mit Masse verbunden.

Das ist allerdings ein Problem, das solltest Du schnellstens ändern. Auf 
diese Weise funktionieren meine Geräte auch nicht richtig.

[Rama (Gast)]

Ich hatte mich getäuscht, das Gehäuse der USB-Buchse war doch nicht mit 
Masse verbunden. Habe jetzt wie du vorgeschlagen hast einen Kondensator 
zwischen das Gehäuse und Masse gelötet und es scheint was gebracht zu 
haben. Kannst du mir vielleicht sagen was dieser bewirkt?

Wegen deinem zweiten Hinweis, die Spannungsversorgung für den Controller 
und damit auch für die 3,3V für die USB-Verbindung habe ich über eine 
Dioden-Oder-Schaltung realisiert, das heißt der Controller wird über 
USB-Versorgt wenn nur USB angeschlossen ist und über das Netzt wenn nur 
dies angeschlossen ist. Wenn beides da ist, ist nicht ganz klar über was 
er Versorgt wird. Nachdem was du geschrieben hast, ist diese Lösung je 
leider nicht ganz so geschickt.
Ich habe den Schaltplan der Controllerplatine mal angehängt. Diese 
Platine wird als Huckepackplatine aufgesteckt. Die 5V Spannung die aus 
dem Netz generiert wird kommt über den NPG Stamp (Verbinder zu 
Hauptpatine) über den Pin VCC, die Diode für die Oder Schaltung ist auf 
der Hauptplatine.

[Guido Körber (Gast)]

Spontan fallen mir die Fragen ein:
Was machen die Kondensatoren an den USB Signalleitungen? Die sollten 
eigentlich nicht da sein, oder ist das so vom Hertseller vorgeschlagen?

Wo ist der 100nF Kerko für den Prozessor platziert? Wenn der nicht am 
richtigen Ort ist sieht man häufig solche Effekte, wird nur von den 
meisten Leuten nicht wahrgenommen, da kriege ich immer abenteuerliche 
Stories zu hören bis die Leute dann ganz still werden wenn ich ihnen 
vorführe, dass ihre Probleme weg sind so bald der Kondensator ordentlich 
platziert ist.

Die Stromversorgung sieht abenteuerlich aus, da würde ich mich nicht 
wundern wenn da die Problem herkommen.

[Rama (Gast)]

Die Kondensatoren an den Datenleitungen dienen zusammen mit den 
Widerständen als Filter.

Der 100nF Kondensator ist direkt am Pin des Controllers platziert.

Was verstehst du unter abenteuerlich?

[Guido Körber (Gast)]

Na es ist etwas undurchsichtig was von wo kommt. Hat die zweite 
Stromquelle auch eine Diode?

Dann ist da ein Spannungsteiler der direkt an der USB Versorgung hängt, 
der soll detektieren ob USB Saft hat?

Sind die Filter auf den Datenleitungen so vom Chiphersteller vorgegeben? 
Und wenn nicht, mal durchgerechnet ob die Signale in der USB Spec 
bleiben?

Der Chip hat je zwei Masse und 5V Anschlüsse. Die meisten Chips die ich 
kenne bei denen das so ist brauchen unter dem Chip möglichst je eine 
Fläche um diese Pins miteinander zu verbinden, mindestens Leitungen die 
entlang der Luftlinie verlaufen, sonst werden sie instabil in der 
Funktion.

[Rama (Gast)]

Hallo Guido,
die zweite Versorgung, die aus der Netzspannung erzeugt wird, hat auch 
eine Diode. Habe das jetzt so gelöst, dass die Diode auf der 
Controllerpaltine eine Shottkydiode und die andere eine "normale" Diode 
ist. Dadurch ist sichergestellt, dass der Controller bei angeschlossenem 
USB auch hierüber versorgt wird.

Den Spannungsteiler ist dafür da, damit der Controller weiß ob eine 
USB-Verbindung vorhanden ist.

Die beiden Anschlüsse für 5V und Masse sind auf kurzestem Weg 
miteinander verbunden.

Dank des Tipps von René mit dem Kondensator und das der Regler für die 
3,3V  aus der USB-Versorgung versorgt werden muss funktionert die 
Verbindung zwischen Gerät und PC jetzt. WIr haben die Verbindung nicht 
mehr zum Absturtz gebracht. Danke nochmal für die Hilfe!