FTDI D2XX Treiber C# Probleme / Lag / Freeze /.

[Mario K. (blu3r4y)]

Hallo!

Ich experimentiere gerade mit dem neuen FT230XS Baustein von FTDI. Da 
ich nur ungern einen emulierten COM Port für das zukünftige Plug'n'Play 
Gerät verwenden möchte, versuche ich mich gerade an den D2XX Treibern.

Ich programmiere in C# und habe beispielweise mal das LoopBack Example 
ausgetestet. 
(http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/CSharp.htm)

Das Ergebnis war so la la la. Der Treiber zickt bei mir ziemlich komisch 
herum. Das C# Programm bleibt an den unterschiedlichsten Stellen im Code 
hängen, das USB Gerät meldet sich ab und wieder an, etc.

Manchmal bleibt der Code bis zu einer Minute bei folgendem Statement 
hängen:

// Determine the number of FTDI devices connected to the machine
ftStatus = myFtdiDevice.GetNumberOfDevices(ref ftdiDeviceCount);

Manchmal auch hier:

// Populate our device list
ftStatus = myFtdiDevice.GetDeviceList(ftdiDeviceList);

Der über USB angeschlossene FTDI IC meldet sich bei Windows teilweise 
auch ab (Windows dü-düp Ton) und an. Ich habe es sogar schon "geschafft" 
das sich meine Konsolenanwendung nicht mal mehr über den Task Manager 
und Prozess beenden schließen lassen hat.

Ein paar wenige Mal hat der Chip aber auch sofort reagiert und die Daten 
wurden korrekt hinausgesendet! (siehe Bild)


Ich habe im Geräte Manager eingestellt, dass sich der VCP Treiber nicht 
mitlädt, scheint aber nichts zu ändern. Ansonsten bin ich eher ratlos 
wie ich an das Problem herantreten soll. Hatte schon mal jemand ähnliche 
Schwierigkeiten?

[Olek (Gast)]

Hört sich für mich eher danach an als wenn du den FTDI auf einem 
Steckbrett betreibst.

Stimmt alles mit der Energieversorgung des IC?

Etwas mehr Infos bitte, geht mal und geht mal nicht ist etwas 
zuwenig....

[Mario K. (blu3r4y)]

Ja, es ist schwer mehr Infos zu geben. Weil es sich eben genauso komisch 
verhält, sry ;(

Wie gesagt, ich hatte schon verschiedenste Szenarien:

* Der Code hängt komplett oder verzögert oft bis zu einer Minute beim 
Zählen der angeschlossenen FTDI Devices

ftStatus = myFtdiDevice.GetNumberOfDevices(ref ftdiDeviceCount);

* Der Code hängt komplett oder verzögert oft bis zu einer Minute beim 
Holen der Device List

ftStatus = myFtdiDevice.GetDeviceList(ftdiDeviceList);

* Der Code funktioniert auf Anhieb und ohne Verzögerung

Wenn der Code schon hängt, höre ich oft das dü-düp Geräusch für ein 
abgemeldetes USB Gerät in Windows. Gleich darauf aber meist wieder ein 
(oder zwei!) dü-düps für ein wieder angemeldetes Gerät.

Ich habe es sogar schon mal geschafft das mir der FTDI mit dem 
gestarteten Programm einen Bluescreen provozierte!!

Und ja, ich betreibe den IC auf einem Steckbrett. Das war auch meine 
zuerst vermutete Fehlerquelle. Ich habe schon 2 verschiedene USB Kabel 
ausprobiert und auch unterschiedliche USB Ports, welche mit jedem 
anderen Gerät korrekt funktionieren.

Ich habe den FTDI beschalten wie im Datenblatt, d.h. mit zahlreichen 
Kondensatoren und allem für eine mögliche Entstörung. Das einzige was 
mir fehlt wäre der Ferrit Bead in Serie, weil ich so etwas leider nicht 
zu Hause habe.

Im Konkreten habe ich jetzt den FT231XS (!) in der USB Bus Powered 
Configuration beschalten. (siehe Foto)

Der Virtual COM Emulator funktioniert einwandfrei übrigens!!! Die 
Probleme treten nur im Zusammenhang mit dem D2XX Treiber auf.

OS: Win7 64-bit
Auch als Administrator ausgeführt ändert sich der Programmablauf nicht 
positiv.

... Ich überprüfe nochmals die Beschaltung und vor Allem die 
Spannungsversorgung am Steckbrett.

[Ralf (Gast)]

Wie schon geschrieben wurde, ist es sinnvoll die Schaltung und das 
Layout zu posten, ebenso den kompletten Code.

Wichtig kann hier auch folgendes sein: Bis zur Chiprevision C gibt's 
Probleme, wenn mehrere aufeinanderfolgende Nullen auf dem USB-Bus 
gesendet werden (Achtung: damit ist nicht nur das gemeint, was man auf 
dem Tx-Pin sehen möchte!).
In dem Fall kann es evtl. vorkommen, dass der Chip in den Suspend 
wechselt, wenn ich mich recht erinnere. Abhilfe schafft hier, einen der 
CBUS-Pins so zu konfigurieren, dass der Suspend-Modus unterdrückt wird.

Ralf

[Ralf (Gast)]

> Ich habe schon 2 verschiedene USB Kabel ausprobiert und auch
> unterschiedliche USB Ports, welche mit jedem anderen Gerät korrekt
> funktionieren.
Shield mit GND verbunden?

> Der Virtual COM Emulator funktioniert einwandfrei übrigens!!! Die
> Probleme treten nur im Zusammenhang mit dem D2XX Treiber auf.
Und die Samples von FTDI funktionieren?

Ralf

[Mario K. (blu3r4y)]

Okay, hier poste ich euch nochmal den Code und das derzeitige Layout auf
dem Steckbrett. Die Schaltung entspricht exakt der oben geposteten. Es
wurden nur noch RxD, TxD und die RxLED und TxLED zusätzlich
angeschlossen. Einen genaueren Schaltplan habe ich derzeit leider nicht.

Ich kann das mal probieren, das ich den Chip nicht in den Suspend Modus
gehen lassen, durch den Keep_Awake# Pin. Ich werde dann schauen wie ich
den CBUS umkonfigurieren kann.

Und nein, ich habe SHIELD derweil NICHT mit Ground verbunden, ich werde
das machen, oder?

Und ich hoffe doch das der Chip von FTDI nicht defekt ist. Ich könnte
morgen eventuell ein neues Breakout Board suchen und einen FT230XS
ausprobieren, von denen habe ich auch noch 2 Stück.

[Rufus Τ. F. (rufus)]

Mario Kahlhofer schrieb:
> und das derzeitige Layout auf dem Steckbrett

Das USB-Signal auch über das Frickelboard zu führen halte ich für gar 
keine gute Idee. Eine weitere Fehlersuche erübrigt sich da meiner 
Ansicht nach.

Der Abblockkondensator für die Stromversorgung des FT231x gehört ebenso 
direkt auf die Adapterplatine wie die restliche USB-Beschaltung auch, 
sprich, alles, was in Deiner obigen Schaltungsskizze zu sehen ist.

[Mario K. (blu3r4y)]

Okay, danke, dann hab ich mir das doch etwas zu einfach vorgestellt. 
Dann werde ich nicht drum herumkommen eine neue Platine zu ätzen, wo ich 
die Bauteile gleich direkt knapp an den IC setze.

Mich wundert nur das sich der Fehler erst mit dem D2XX Treiber zeigt? 
Ist doch komisch wenn der Virtual COM Port sich ohne Probleme nutzen 
lässt, wenn aktiviert.

[Arc N. (arc)]

Wird das C# Projekt für "Any CPU" übersetzt oder für x86 oder x64?
Wenn das für Any CPU oder x64 übersetzt wird, dass ganze als x86 
übersetzen lassen.

[Mario K. (blu3r4y)]

Any CPU. Habe ich gerade auf x86 geändert, leider keine Veränderung.

Kann ich die CBUS Pins direkt mit dem C# D2XX Treiber umkonfigurieren 
(d.h. den MTP memory beschreiben)? Dann würde ich nämlich einen Pin als 
Keep_Awake# Pin setzen, damit der FTDI nicht in den Suspend Mode geht.

[Mario K. (blu3r4y)]

Schon geschafft. Hab einen CBUS jetzt auf KeepAwake programmiert mit FT 
Prog. Und den VCP Treiber komplett deaktiviert.

Leider habe ich bei meinem LoopBack Code immernoch das gleiche 
Verhalten. Selbst beim Programmieren brauchte ich 3x Anläufe bis mir der 
FTDI angezeigt wurde.

Ich hoffe es liegt nur an der Spannungsversorgung und unsauberen 
Verdrahtung am Steckbrett. Wundert mich allerdings das der VCP Treiber 
so reibungslos funktioniert hat. >.>

[Mario K. (blu3r4y)]

Triple Post aus gutem Grund!!!

Ich habe jetzt nur leicht das Layout auf meinem Steckbrett verändert. 
Unnötigen Kabeln entfernt. Kondensatoren weiter zum IC ran.
Unnnnd ich habe das Kabel an einen USB 3.0 Port direkt am PC hinten 
angeschlossen.

Und siehe da! Das Programm hat gerade 10 mal in Folge erfolgreich 
funktioniert! ;) freu :D

Also liegt es wirklich "nur" an EMV-technischen Problemen.