ftd2xx driver problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: ftd2xx driver problem
Un bel giorno Rob1 digiṭ:

Quoted text here. Click to load it

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

Re: ftd2xx driver problem

Quoted text here. Click to load it
4),

Quoted text here. Click to load it
versa),

Quoted text here. Click to load it
over-

Quoted text here. Click to load it

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


Re: ftd2xx driver problem
Un bel giorno Rob1 digiṭ:

Quoted text here. Click to load it

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

http://www.ftdichip.com/Support/Knowledgebase/index.html?ftd2xx_h.htm

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Re: ftd2xx driver problem
Quoted text here. Click to load it
here:http://www.alblas.demon.nl/ftdproblem/ftdtest.c
Quoted text here. Click to load it
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.





Re: ftd2xx driver problem

Quoted text here. Click to load it

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 is the fix.

Cheers Don...




--
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
We've slightly trimmed the long signature. Click to see the full one.
Re: ftd2xx driver problem
Quoted text here. Click to load it

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

Re: ftd2xx driver problem

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: ftd2xx driver problem
Quoted text here. Click to load it

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 http://www.EmbeddedRelated.com

Re: ftd2xx driver problem
Quoted text here. Click to load it


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.



Re: ftd2xx driver problem

Quoted text here. Click to load it
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 http://www.EmbeddedRelated.com

Site Timeline