ftd2xx driver problem
in [Embedded]
|
Prev: Repurposing WinCE MIPS netbooks?
Next: International Journal of Electronics, Information and Systems (IJEIS) Call for Paper
From: Rob1 on 31 Dec 2009 09:58 Hi, I have problems with a program using ftd2xx library, to communicate with a ftd245 chip. I hope this is the right mailing list for this question. Problems are with both Windows and Linux. For Windows: Compile command: gcc ftdtest.c -o ftdtest -L. -lftd2xx seems to work fine. I have ftd2xx.dll in the compile directory; this an the other dll's are also in the system32 directory. FT_ListDevices works as expected. FT_OpenEx works as expected. FT_GetDeviceInfo too works as expected (returns correct serial number and description). However, a repeated call to FT_GetQueueStatus (no data pushed into the device) gives after 40 or so calls unexpected available bytes (amount: 4), and after a while the program crashes. Adding a FT_Read to catch these bytes doesn't help. Under Linux I have similar problems (Fedora 8); I did try here to transfer bytes to the PC which works fine for a few seconds, then the program crashes. The test program is available here: http://www.alblas.demon.nl/ftdproblem/ftdtest.c Anyone who can give me a hint? Rob. --------------------------------------- This message was sent using the comp.arch.embedded web interface on http://www.EmbeddedRelated.com
From: dalai lamah on 31 Dec 2009 11:00 Un bel giorno Rob1 digit�: > However, a repeated call to FT_GetQueueStatus (no data pushed into the > device) gives after 40 or so calls unexpected available bytes (amount: 4), > and after a while the program crashes. Perhaps gcc is using an incorrect calling convention for the FTDI DLL functions? If for example you use stdcall instead of cdecl (or vice versa), everything will look fine for a while, but eventually the stack will over- (or under-) flow. -- emboliaschizoide.splinder.com
From: Viktor on 31 Dec 2009 13:47 On Dec 31, 3:58 pm, "Rob1" <r...(a)alblas.demon.nl> wrote: > Hi, > I have problems with a program using ftd2xx library, to communicate with a > ftd245 chip. I hope this is the right mailing list for this question. > Problems are with both Windows and Linux. > > For Windows: > Compile command: > gcc ftdtest.c -o ftdtest -L. -lftd2xx > seems to work fine. I have ftd2xx.dll in the compile directory; this an > the other dll's are also in the system32 directory. > > FT_ListDevices works as expected. > FT_OpenEx works as expected. > FT_GetDeviceInfo too works as expected (returns correct serial number and > description). > > However, a repeated call to FT_GetQueueStatus (no data pushed into the > device) gives after 40 or so calls unexpected available bytes (amount: 4), > and after a while the program crashes. > Adding a FT_Read to catch these bytes doesn't help. > > Under Linux I have similar problems (Fedora 8); I did try here to transfer > bytes to the PC which works fine for a few seconds, then the program > crashes. > > The test program is available here:http://www.alblas.demon.nl/ftdproblem/ftdtest.c > > Anyone who can give me a hint? > > Rob. > > --------------------------------------- > This message was sent using the comp.arch.embedded web interface onhttp://www.EmbeddedRelated.com Could it be that your USB cable is picking up noise? We found out the hard way that FDTI drivers are very susceptible to noise and the whole thing becomes unresponsive. If the Reset and Cycle commands return an error code after Getqueuestatus returns the unexpected bytes, then this is probably what is happening. The file handle is now useless and the only way you can regain control of your USB device is with the newly implemented Reload and Rescan commands, which use the VID and PID instead of the file handle. Hope this helps.
From: Don McKenzie on 31 Dec 2009 16:06 Viktor wrote: > Could it be that your USB cable is picking up noise? We found out the > hard way that FDTI drivers are very susceptible to noise and the whole > thing becomes unresponsive. If the Reset and Cycle commands return an > error code after Getqueuestatus returns the unexpected bytes, then > this is probably what is happening. > The file handle is now useless and the only way you can regain control > of your USB device is with the newly implemented Reload and Rescan > commands, which use the VID and PID instead of the file handle. > > Hope this helps. Noise? The addition of two 47pF capacitors from the DP and DM lines to 0V on many devices removes the problem completely. read the full story at: http://www.dontronics-shop.com/canusb-module.html Please let me know if this fixes it. Cheers Don... BTW Happy New Year 2010 -- Don McKenzie Site Map: http://www.dontronics.com/sitemap E-Mail Contact Page: http://www.dontronics.com/email Web Camera Page: http://www.dontronics.com/webcam No More Damn Spam: http://www.dontronics.com/spam The World's First Large-Scale, Multi-User, Real Time System. http://www.dontronics.com/first_multi_user_real_time.html
From: Rob1 on 1 Jan 2010 16:19
>Un bel giorno Rob1 digit�: > >> However, a repeated call to FT_GetQueueStatus (no data pushed into the >> device) gives after 40 or so calls unexpected available bytes (amount: 4), >> and after a while the program crashes. > >Perhaps gcc is using an incorrect calling convention for the FTDI DLL >functions? If for example you use stdcall instead of cdecl (or vice versa), >everything will look fine for a while, but eventually the stack will over- >(or under-) flow. The functions I use are the mentioned ones starting with FT_, like FT_Read, FT_GetQueueStatus. I don't use/have seen functions like stdcall, cdecl etc., at least not directly. Nevertheless I was thinking in a direction like this, or a mandated gcc option etc. Noise on USB could be an issue, but I would expect corrupt data, never a program crash. I'll try to add the caps anyway. Btw, I am using a module USMOD4; schematics don't show caps at the USB lines. Rob. --------------------------------------- This message was sent using the comp.arch.embedded web interface on http://www.EmbeddedRelated.com |