1. Home
  2. Embedded Programming
  3. ftd2xx driver problem

ftd2xx driver problem

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:

formatting link

Anyone who can give me a hint?

Rob.

--------------------------------------- This message was sent using the comp.arch.embedded web interface on

formatting link

Reply to
Rob1
Loading thread data ...

Un bel giorno Rob1 digitò:

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
Reply to
dalai lamah

here:

formatting link

on

formatting link

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.

Reply to
Viktor

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:

formatting link

Please let me know if this is the fix.

Cheers Don...

--
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
Reply to
Don McKenzie

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:

formatting link

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
Reply to
Don McKenzie

4),

versa),

over-

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

formatting link

Reply to
Rob1

Not in our experience. We've had these caps in our USB devices from the start and this turned out to be a problem because the error never happened to us or to most of our customers until people started using our iButton readers in industrial environments.

Try putting a fluorescent lamp next to your USB cable, switch it on and off a few times and the USB device (with caps!) will become unresponsive to all API commands. Reloading the FDTI drivers with the two new commands I mentioned is the only solution I know of.

It is also possible for extra characters to appear in the receive queue and for the API commands to remain operational, but you shouldn't count on it.

Cheers,

Viktor

Reply to
Viktor

Un bel giorno Rob1 digitò:

The FTDI header files don't explicitly declare the calling convention for the functions prototypes:

formatting link

Therefore, it is a compiler responsability to decide which convention to use. If I remember correctly, Visual C++ use cdecl as default, so I suppose that FTDI functions are cdecl.

I would agree, but if I've experienced funny things with FTDI drivers, so you can't never say. :)

I usually don't add those two capacitors (which have mostly an "impedance matching" purpose rather than noise filtering), and I have never had a malfunction like yours.

--
emboliaschizoide.splinder.com
Reply to
dalai lamah

I have added 2 caps of 47pF as suggested, and communication is OK now! The problem seems not to be external noise, but self-generated noise (or bad signal shapes). Sending all-zeros or ones (just 00 or FF bytes) works fine, but sending 'real' data causes the program crash and other strange behaviour to happen. Since this is a communication problem between FTD chip and PC I can imagine that some PC's work fine without the caps, and others not. Maybe best is to add them always. Apart from that, it seems to me that the FTD drivers are not very robust. Causing program crash because of a bad connection is not a good thing... (and what about disconnecting during transmission? Should never cause a program crash. I have to look at this too.) Anyway, I can go on now with my project. Thanks for the responses.

Rob.

--------------------------------------- Posted through

formatting link

Reply to
Rob1

Which is why I prefer the MAX USB chips and then I can use the Win USB drivers. If the drivers I "supply" don't work, I get blamed.

Reply to
Bill Davy

robust.

thing...

An update: I have the same program now also running under Windows. No problems here with crashing program if I disconnect the USB-cable; this seems to be a Linux driver problem. Actually, a program with this driver crashes immediately at start in Fedora 5; in Fedora 8 it's OK apart from the crash-after-diconnect-USB-cable.

(Project info: HRPT/CHRPT weather satellite decoder, continuous 1.3Mbit/sec over 5 meter low-cost USB cable.)

Rob.

--------------------------------------- Posted through

formatting link

Reply to
Rob1

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.