kein Zugriff auf FTDI FT245 nach SW-Abbruch

[TImo (Gast)]

Hallo,

ich setzte einen FT245RL von FTDI ein und habe folgendes Problem in 
meinem Anwendungsporgramm (VB6) (ist sicher bei allen FTxxx das selbe) :

Sobald das Device einmal geöffnet ist (FT_GetNumDevices - 
FT_ListDevices-FT_Open) und die Software abbricht bevor der Port wieder 
ordentlich geschlossen werden kann (FT_Close), habe ich softwareseitig 
keine Chance auf einen neuen Zugriff. Ich muss dann erst das Gerät vom 
Bus abziehen und wieder einstecken.

Sicher ist das Problem nicht neu - kann jemand helfen?



Ach ja: FTDI-Support empfahl mir folgendes (leider ohne Erfolg)

Set the ResetPipeRetryCount to 100. This can be done in the drivers or in the application by using the function FT_SetResetPipeRetryCount. To change the driver by edit the INF file by following the instructions on page 11 of the following document http://www.ftdichip.com/Documents/AppNotes/AN232B-10_Advanced_Driver_Options.pdf 

 

Set the Dead mans timeout to 10000. This can be done in the driver or in the application by using the function FT_SetDeadmansTimeout. To change the driver by edit the INF file by following the instructions on page 17 of the following document http://www.ftdichip.com/Documents/AppNotes/AN232B-10_Advanced_Driver_Options.pdf  

 

There are also functions in the new driver that will try and recover the device programmatically. These functions are called FT_Rescan and FT_Reload.

Der Sourcecode sieht etwa so aus

Public Function USBOpen() As Boolean
Dim strDescription As String * 256
Dim strSerialNumber As String * 256

 

If FT_GetNumDevices(lngNumDevices, vbNullString, FT_LIST_BY_NUMBER_ONLY) <> FT_OK Then
    ' do Failoption

    Exit Function
End If

 

If FT_ListDevices(0, strDescription, FT_LIST_BY_INDEX Or FT_OPEN_BY_DESCRIPTION) <> FT_OK Then
    ' do Failoption

    Exit Function
End If

  

If FT_Open(0, lngNumDevices) <> FT_OK Then
    ' do Failoption

    Exit Function
End If

 

End Function

 

Public Function USBclose() As Boolean
If FT_Close(lngNumDevices) <> FT_OK Then
    ' do Failoption

End If

End Function

Danke,


Timo

[MM (Gast)]

Das ist leider so - dafür gibt es keine universelle Lösung.

Am einfachsten einen Shutdown Handler programmieren der die offenen
Verbindungen schließt wenn das Programm beendet wird.

Gruß, Marcus

[Ralf (Gast)]

Hallo,

@MM:
> Am einfachsten einen Shutdown Handler programmieren der die offenen
> Verbindungen schließt wenn das Programm beendet wird.

Timo hat geschrieben:

> ...und die Software abbricht bevor der Port wieder ordentlich geschlossen
> werden kann (FT_Close)

Wird denn dann ein Shutdown-Handler wirklich noch angesprungen? Sicher 
ist so ein Handler hilfreich, aber ich frag mich eben, ob der dann 
wirklich noch zum Zug kommt.

Ralf

[Andre T. (oldgrumpy)]

Ralf wrote:
>
> Wird denn dann ein Shutdown-Handler wirklich noch angesprungen? Sicher
> ist so ein Handler hilfreich, aber ich frag mich eben, ob der dann
> wirklich noch zum Zug kommt.
>
> Ralf

Nein, wird er nicht. Wenn ein Prozess gekillt wird, dann wird er 
gekillt, das hat nichts mit einem kontrollierten Shutdown zu tun. Ich 
hatte vor einiger Zeit praktisch das gleiche Problem, je nachdem wie 
rabiat man die eigene Software implementieren will, kann man allerdings 
mittels der vom FTDI Support angesprochenen Funktionen FT_Rescan bzw. 
FT_Reload einen Reload des USB-Treibers erzwingen. Da der aber unter 
Umständen nicht nur die eigene Hardware befeuert (die FTDI-Chips sind ja 
sehr verbreitet), könnte man damit eine breite Palette an 
Kollateralschäden verursachen...

[Ralf (Gast)]

Hi Andre,

ja, das könnte ein Problem geben. Bzgl. der FTDI Chips und einem 
gekillten Prozess müsste man aber mal probieren, ob man trotz geöffneter 
Devices diese nicht bei einem erneuten Programmstart einfach mittels der 
LocationID schliessen kann. Ich meine, dass man zumindest auch 
Informationen über alle angeschlossenen FTDIs bekommen kann, egal ob 
geschlossen oder geöffnet.

Ralf

[Andre T. (oldgrumpy)]

Ralf wrote:
> ja, das könnte ein Problem geben. Bzgl. der FTDI Chips und einem
> gekillten Prozess müsste man aber mal probieren, ob man trotz geöffneter
> Devices diese nicht bei einem erneuten Programmstart einfach mittels der
> LocationID schliessen kann. Ich meine, dass man zumindest auch
> Informationen über alle angeschlossenen FTDIs bekommen kann, egal ob
> geschlossen oder geöffnet.

Ja, und genau das ist auch das einzige was geht - zumindest zum 
Zeitpunkt meiner letzten Tests, das war die Treiberversion vor der 
momentan aktuellen, hab die Nummer gerade nicht parat. Wenn die Jungs 
von FTDI da nix geändert haben, dann bekommt man gerade noch die Anzahl 
der angeschlossenen Devices, aber kaum mehr - ist alles vom vorherigen 
FT_Open gesperrt. :( Habe momentan leider ganz andere Sorgen (siehe mein 
Posting in Sachen M16C und CrossView von gestern abend) so dass ich 
keine Zeit zum Ausprobieren habe, ich wäre aber durchaus an den 
Testresultaten interessiert :)

[TImo (Gast)]

Ich habe jetzt einen langen Mailverkehr mit der FTDI-Hotline, leider 
führt das aber auch nicht zum Erfolg bei mir.
Letzlich wird im oben beschriebenen Fehlerfall folgendes vorgeschlagen, 
wodurch der Handle wieder hergestellt werden soll.


Vielleicht kann das jemand mal gegenprüfen.....

Timo

// FTDI.cpp : Defines the entry point for the console application.

//

 

//#include "stdafx.h"

#include <windows.h>

#include <stdio.h>

#include "ftd2xx.h"

 

FT_HANDLE fthandle;

FT_STATUS status;

 

void Reload()

{     

FT_Reload(0403,6010);

FT_Rescan();

Sleep(1000);

 

status = FT_Open(0, &fthandle);

 

while(status!=0)

{

status = FT_Open(0, &fthandle);

 

}

printf("Device Open %d\n", status);

}

 

int main(int argc, char* argv[])

{

 

      

Reload();

 

 

 

 status = FT_ResetDevice(fthandle);

              if(status != FT_OK)

 {

              printf("reset status not ok %d\n", status);

                    //Reload();

 }

 

/************************************************************/                  

                   

 

 status = FT_SetTimeouts(fthandle,500,500);

 

                   if(status != FT_OK) 

 {

               printf("timeout status not ok %d\n", status); 

                     //Reload();

}

 

/************************************************************/                  

 

 

 status = FT_SetBaudRate(fthandle,38400);

 

                   if(status != FT_OK)

 { 

               printf("baud status not ok %d\n", status);

                     //Reload();

 }

/************************************************************/                  

printf("Program paused.... Press return to Start Again!\n");

getchar();

 

//CBUS BITBANG

                     

UCHAR MaskA = 0xFF;

UCHAR modeA = 0;

 

 

 status = FT_SetBitMode(fthandle, MaskA, modeA);

 

                     if(status != FT_OK) 

               printf("mode A status not ok %d\n", status);

                    

 

                    

MaskA = 0x00;

modeA = 0x20;

 

 

 status = FT_SetBitMode(fthandle, MaskA, modeA);

 

                     if(status != FT_OK) 

                              printf("mode A status not ok %d\n", status);

 

UCHAR Bitmode;

UCHAR KeyChar;

 

KeyChar = 0x6F;

 

do

{

 

 status = FT_GetBitMode(fthandle, &Bitmode);

 

                     if(status != FT_OK) 

               printf("data read failed\n", status);

}

while (Bitmode != KeyChar);

 

 printf("Key Press detected\n");

 

 status = FT_Close(fthandle);

 

               return 0;

 

}

[Lutz (Gast)]

Hat das inzwischen jemand ausprobiert?
Es würde mich auch interessieren. Ich habe es versucht und bisher nicht 
geschafft das ganze in VB6 erfolgreich umzustezen, habe aber auch nur 
ein so ähnliche Problem.

Also beim Software-Crash ist die Sache einfach. Ich stöpsel den 
USB-Adapter einfach aus und wieder ein und schon funktionert der handle 
wieder.
Ausserdem kann ich einen Software-Crash ja verhindern.

Mein Problem ist folgendes, wenn ich meine Schreibtischlampe ein- oder 
ausschalte, stört das die USB-Kommunikation und ich bekomme Fehler 4 
(allgemeiner I/O error).
Wie kann ich diesen Fehler zurücksetzen ohne danach (zB bei FT_close) 
Fehler 1 zu bekommen (invalid handle)? Den ich dann wie oben für den 
Programm-Crash beschrieben nicht weg bekomme.
Stöpsel ich den USB-Port dann aus und ein, kann ich danach auch 
problemlos den alten handle benutzen. Der erzeugte Zustand ist also 
einem Crash sehr ähnlich

Ich bräuchte also eine Funktion, mit der ich den Fehler 4 zurücksetzen 
kann, ohne dass der Treiber vergisst, dass man die Berechtigung hat, den 
handle zu benutzen. Denn nach dem ein- und ausstöpseln funktioniert ja 
genau dieser falsche handle wieder und wird als richtig erkannt. Der 
handle ist also gar nicht falsch. Der CDM-Treiber hat nur vergessen, 
dass man das Recht hat, ihn zu benutzen.

Wie kommt man da softwaremässig raus, ohne ein und auszstöpseln?
Oder wie kann man Fehler 4 zurücksetzen ohne Fehler 1 zu erhalten.

Weiss jemand eine Lösung?

Vielen Dank
Lutz





Weiss jemand eine Lösung?

[NLB (Gast)]

Wie sich die Fehler gleichen. Das ist nun gut 1,5 Jahre her. Ich 
versuche genau diesen Fehler auf Vorstads-Ebene mit FTDI zu klären. 
Falls ich was herausbekomme gibt es ein FeedBack

mfg NLB

[Lutz (Gast)]

Hab mal wieder vorbei geschaut. Ja es ist schon über 1.5 Jahre her.

Das Problem habe ich immer noch. Und noch immer gibt es keine Lösung.
Schade.

Wie schaffen es alle anderen FTDI-Chip Nutzer den EMV-Test zu bestehen, 
wenn sie Fehler 4 nach eine elektrischen Störung nicht rücksetzen 
können?

Was mache ich falsch?

Alle von FTDI vorgeschlagenen Lösungen z.B. FT_SetResetPipeRetryCount, 
Schaltungsverbesserung... verringern nur die Fehlerquote, aber lösen das 
Problem nicht. Wenn ich Fehler 4 zurücksetzen könnte, ohne Fehler 1 zu 
erhalten, hätte ich das Problem komplett vom Tisch.
Warum kann ich das nicht? Wie machen das alle anderen Nutzer?
Ich will das die USB-Verbindung monatelang problemlos funktioniert.
Ist das zuviel verlangt?

Lutz

[Edefix (Boss vom BugFix) (Gast)]

Nun ja. Auch ich kämpfe mit dem Problem bei einer Automatenkassa, wo die 
ccTalk-Komponentne via seriellem USB angesprochen werden, alle 2 bis 3 
Tage ist der USB-Device weg, also ausstöpseln, einstöpseln, wunderbar 
8-(

Habe nun eine Geschichte in VB6 herausgefunden: Der Handle, welchen man 
beim Öffnen des Devices erhält, wird ja auch wieder zum Schließen 
benötigt. Es gibt da allerdings eine mir mittlerweile bekannte Funktion, 
die diesen Handle zerstört: FT_EE_Read(lngHandle, EEData). Diese 
Funktion liest diue Seriennummer, Hersteller, etc. Der dabei übergebene 
Handle lngHandle wird bei der Ausführung auf 0 gesetzt, wobei das 
Schließen des Devices logischerweise schief geht. Also unbedingt den 
Device-Handle zwischenspeichern, weiß ja nicht wo das sonst noch 
passiert.

Aber jetzt kommt es dicker. Nachdem der Device geöffnet ist, kann er 
nicht wieder geöffnet werden >> Error. Schließen kannst Du ihn auch 
nicht mehr, hast ja keinen Handle mehr. Gut. Also zyklisch prüfen und 
dann resetten.

1. Versuch: Den Device resetten
FT_ResetDevice(lngHandle) ->> kein Ergebnis

2. Versuch: Den USB-seriellen FTDI-Device mit der internen Funktion 
reloaden
FT_Reload(&H403, &H6001) ->> kein Ergebnis

3. Versuch: Alle FTDI-Devices reloden
FT_Reload(&H0, &H0) ->> kein Ergebnis
(ausser daß wirklich alle betroffene Treiber aus der 
Hardwarekomponenten-Liste rausfliegen und dann auch wieder schön brav 
eingelesen werden)
Kann also den Device wieder auflisten, aber NICHT ÖFFNEN. Musst Du 
einfach ausstöpseln, einstöpseln, geht doch.

Kann doch nicht sein, oder?

Hat da irgend wer noch ne echt gute Idee?


Ed

[ab (Gast)]

Auch wenn der Thread uralt ist, bin ich heute auch auf das gleiche 
Problem gestoßen..!! Hat es einer von euch irgendwie lösen können? Das 
manuelle raus und wieder reinstecken des USB Steckers kommt bei mir gar 
nicht in Frage, da das FTDI Device zum Zwecke einer Automatisierung 
eingesetzt wird. Daher muss ich es softwaretechnisch lösen.

[Felix Adam (Gast)]

Ich denke, nach dem Lesen dieser Beiträge werde ich im Mikrocontroller 
eine Routine vorsehen, die nach Abbruch der Kommunikation (mit Timeout) 
den FTDI einmal eigenständig resettet. Der FTDI hat dafür ja einen Pin.

Hat das schonmal jemand gemacht und weiß, ob das geht? Es sollte ja wie 
ein Abziehen vom Bus sein...

Vielleicht hilft das auch dem Gast "ab".