Ik heb hier een apparaatje (om carburateurs /throtttle bodies te synchroniseren) dat heeft wat issues. In het apparaat zit een FT232RL en die communiceert met de applicatie op een (WIN) PC. Apparaat is ontwikkeld door 2 duitse hobbyisten (ong 12 jr geleden) en die hebben weer ruzie gekregen dus er is geen ondersteuning of verdere gegevens hiervan. Aangezien het geen goedkoop apparaatje (en zeer mooi gebouwd / ontworpen) is wil ik zien het te repareren.
De configuratie van de FT232RL is dusdanig dat er niet met een (virtuele) COM poort gewerkt wordt maar gecommuniceerd wordt via de FTD2XX.DLL van FTDI.
Om wat meer inzicht in de communicatie te krijgen heb ik een soort van sniffer gevonden die de systemcalls van de DLL logt.
Hiervoor wordt een nieuwe DLL gebouwd (zie zip bestand in dit bericht) waarbij voor alle calls uit de originele DLL er een functie is die gewoon logt dat de functie is aangeroepen (eventueel met paramters) en dan dezelfde functie in de originele DLL aanroept voor de uitvoering hiervan.
Simpel en doeltreffend !
Zo als gezegd de nieuwe DLL diezelfde naam krijgt als de originele (FTD2XX.DLL) komt in de map bij de applicatie en de originele DLL moet hernoemd worden naar FTD2XX1.DLL.
Helaas gaat ergens iets niet goed want ik krijg bij elke aanroep van een functie voor de FT232 een (pop-up) foutmelding dat de functie niet gevonden is.
Mij ontbreekt ook de kennis om de fout vinden.
Heeft iemand hier een idee?

Zo als gezegd is het een soort van sniffer in de vorm van een te bouwen DLL waarvan de source in mijn openingspost staat als bijlage.
Wil graag weten welke DLL calls er gedaan worden met de parameters, aangezien ik niet weet hoe de USB communicatie naar de FT232R er uit hoort te zien zal een USB sniffer mij weinig helpen

De nieuwe dll moet een export table hebben met exact dezelfde dll function call names erin gelijk aan die in de oude dll export table. Als dit niet zo is dan vindt de FTD applicatie de dll function calls niet meer en krijg je de foutmeldingen zoals je die nu op je scherm ziet.

Functienamen van DLL exports zijn 'by default' ook case sensitive, dus daar moet je ook op letten...

Ik zou even de export table van de oude en nieuwe DLL uitlezen met dumpbin, met alleen de namen maar ook de zogenaamde "decoration" (extra tekens achter de naam, met informatie over de parameters) moet overeenkomen.

alvast dank voor deze aanwijzigingen !. Blijkt inderdaad dat de nieuwe DLL geen EXPORTS heeft. Nu de vraag hoe krijg ik dat voor elkaar ?

de bij het project horende ft2xx.def bestand bevat het volgende:

 
LIBRARY ftd2xx.dll

EXPORTS
        FT_Close = _I_FT_Close @2
        FT_ClrDtr = _I_FT_ClrDtr @11
        FT_ClrRts = _I_FT_ClrRts @13
        FT_CreateDeviceInfoList = _I_FT_CreateDeviceInfoList @70
        FT_CyclePort = _I_FT_CyclePort @69
        FT_EE_Program = _I_FT_EE_Program @37
        FT_EE_ProgramEx = _I_FT_EE_ProgramEx @67
        FT_EE_Read = _I_FT_EE_Read @38
        FT_EE_ReadEx = _I_FT_EE_ReadEx @68
        FT_EE_UARead = _I_FT_EE_UARead @39
        FT_EE_UASize = _I_FT_EE_UASize @40
        FT_EE_UAWrite = _I_FT_EE_UAWrite @41
        FT_EraseEE = _I_FT_EraseEE @34
        FT_GetBitMode = _I_FT_GetBitMode @32
        FT_GetComPortNumber = _I_FT_GetComPortNumber @80
        FT_GetDeviceInfo = _I_FT_GetDeviceInfo @61
        FT_GetDeviceInfoDetail = _I_FT_GetDeviceInfoDetail @72
        FT_GetDeviceInfoList = _I_FT_GetDeviceInfoList @71
        FT_GetDriverVersion = _I_FT_GetDriverVersion @75
        FT_GetEventStatus = _I_FT_GetEventStatus @20
        FT_GetLatencyTimer = _I_FT_GetLatencyTimer @30
        FT_GetLibraryVersion = _I_FT_GetLibraryVersion @76
        FT_GetModemStatus = _I_FT_GetModemStatus @14
        FT_GetQueueStatus = _I_FT_GetQueueStatus @18
        FT_GetStatus = _I_FT_GetStatus @21
        FT_IoCtl = _I_FT_IoCtl @5
        FT_ListDevices = _I_FT_ListDevices @28
        FT_Open = _I_FT_Open @1
        FT_OpenEx = _I_FT_OpenEx @27
        FT_Purge = _I_FT_Purge @16
        FT_Read = _I_FT_Read @3
        FT_ReadEE = _I_FT_ReadEE @35
        FT_Reload = _I_FT_Reload @79
        FT_Rescan = _I_FT_Rescan @78
        FT_ResetDevice = _I_FT_ResetDevice @6
        FT_ResetPort = _I_FT_ResetPort @66
        FT_RestartInTask = _I_FT_RestartInTask @64
        FT_SetBaudRate = _I_FT_SetBaudRate @7
        FT_SetBitMode = _I_FT_SetBitMode @31
        FT_SetBreakOff = _I_FT_SetBreakOff @23
        FT_SetBreakOn = _I_FT_SetBreakOn @22
        FT_SetChars = _I_FT_SetChars @15
        FT_SetDataCharacteristics = _I_FT_SetDataCharacteristics @8
        FT_SetDeadmanTimeout = _I_FT_SetDeadmanTimeout @73
        FT_SetDivisor = _I_FT_SetDivisor @26
        FT_SetDtr = _I_FT_SetDtr @10
        FT_SetEventNotification = _I_FT_SetEventNotification @19
        FT_SetFlowControl = _I_FT_SetFlowControl @9
        FT_SetLatencyTimer = _I_FT_SetLatencyTimer @29
        FT_SetResetPipeRetryCount = _I_FT_SetResetPipeRetryCount @65
        FT_SetRts = _I_FT_SetRts @12
        FT_SetTimeouts = _I_FT_SetTimeouts @17
        FT_SetUSBParameters = _I_FT_SetUSBParameters @33
        FT_SetWaitMask = _I_FT_SetWaitMask @24
        FT_StopInTask = _I_FT_StopInTask @63
        FT_W32_CancelIo = _I_FT_W32_CancelIo @62
        FT_W32_ClearCommBreak = _I_FT_W32_ClearCommBreak @47
        FT_W32_ClearCommError = _I_FT_W32_ClearCommError @48
        FT_W32_CloseHandle = _I_FT_W32_CloseHandle @43
        FT_W32_CreateFile = _I_FT_W32_CreateFile @42
        FT_W32_EscapeCommFunction = _I_FT_W32_EscapeCommFunction @49
        FT_W32_GetCommMask = _I_FT_W32_GetCommMask @77
        FT_W32_GetCommModemStatus = _I_FT_W32_GetCommModemStatus @50
        FT_W32_GetCommState = _I_FT_W32_GetCommState @51
        FT_W32_GetCommTimeouts = _I_FT_W32_GetCommTimeouts @52
        FT_W32_GetLastError = _I_FT_W32_GetLastError @53
        FT_W32_GetOverlappedResult = _I_FT_W32_GetOverlappedResult @46
        FT_W32_PurgeComm = _I_FT_W32_PurgeComm @54
        FT_W32_ReadFile = _I_FT_W32_ReadFile @44
        FT_W32_SetCommBreak = _I_FT_W32_SetCommBreak @55
        FT_W32_SetCommMask = _I_FT_W32_SetCommMask @56
        FT_W32_SetCommState = _I_FT_W32_SetCommState @57
        FT_W32_SetCommTimeouts = _I_FT_W32_SetCommTimeouts @58
        FT_W32_SetupComm = _I_FT_W32_SetupComm @59
        FT_W32_WaitCommEvent = _I_FT_W32_WaitCommEvent @60
        FT_W32_WriteFile = _I_FT_W32_WriteFile @45
        FT_WaitOnMask = _I_FT_WaitOnMask @25
        FT_Write = _I_FT_Write @4
        FT_WriteEE = _I_FT_WriteEE @36
        FT_GetQueueStatusEx = _I_FT_GetQueueStatusEx @84

[Bericht gewijzigd door driessens_nl op (94%)]

Ga hier zeker mee aan de slag. Maar denk dat dit alleen API calls van windows DLL's logt en niet de calls naar FTD2XX.DLL. Verder zou het makkelijk zijn als mijn eerst bedoelde poging zou werken omdat ik hier de sources van heb en ik dus zelf nog wat te loggen data zelf kan bepalen.

Of dit eens proberen...

FTD2XX.dll proxy.

Place in directory of executable using ftd2xx.dll, rename original ftd2xx.dll to ftd2xx1.dll.
When run, the proxy will write a debug.txt file in the current directory.

https://github.com/jgrip/ftd2xx

Dit is net het programma waar ik nu mee bezig ben.
Inmiddels is het me gelukt een DLL te bouwen met EXPORTS, heb wat moeten veranderen in de project eigenschappen. Verder werd er gelinkt naar een functie die niet bestaat. Ook deze heb ik toegevoegd.
Vanavond kijken of dit werkt.

edit: helaas nu crash het programma direct bij aanroep DLL functie. Nog maar eens verder zoeken.

[Bericht gewijzigd door driessens_nl op (15%)]

Inmiddels ben ik zo ver dat als ik de nieuw gebouwde DLL in dezelfde map zet als de applicatie dat deze ook gebruikt wordt.
Als de applicatie een functie voor de FT232 aanroept wordt deze eerst aangeroepen in de nieuw gebouwde DLL. Echter lukt het niet om vanuit de nieuwe DLL de gelijke functie aan te roepen uit de originele DLL.
Heb de originele DLL hernoemd naar ftd2xx1.dll en in de map van de applicatie getzet als ook in de map \windows\system32. met de volgende aanroep in de nieuwe DLL


	gs_hDLL = LoadLibrary("ftd2xx1.dll");

ook geprobeerd de originele DLL te laden middels


	gs_hDLL = LoadLibrary("c:\windows\system32\ftd2xx.dll");

ook geen succes.
Iemand nog een suggestie?

Een logic analyser lijkt me dan beter, maar nog steeds niet heel eenvoudig.

Ik zou verwachten dat je met Wireshark wel de pakketten kunt zien, maar waarschijnlijk met wat overhead die je niet begrijpen om het juiste stuk eruit te kunnen halen.

Ik vind een man-in-the-middle met die DLL wel een leuk plan.