ftd2xx driver problem
in [Embedded]
|
Prev: Repurposing WinCE MIPS netbooks?
Next: International Journal of Electronics, Information and Systems (IJEIS) Call for Paper
From: Viktor on 2 Jan 2010 03:44 On Dec 31 2009, 10:03 pm, Don McKenzie <5...(a)2.5A> wrote: > 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. > 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
From: dalai lamah on 2 Jan 2010 07:30 Un bel giorno Rob1 digit�: > 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. 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. > Noise on USB could be an issue, > but I would expect corrupt data, never a program crash. I would agree, but if I've experienced funny things with FTDI drivers, so you can't never say. :) > I'll try to add the > caps anyway. > Btw, I am using a module USMOD4; schematics don't show caps at the USB > lines. 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
From: Rob1 on 26 Jan 2010 16:32 >Viktor wrote: > >> Could it be that your USB cable is picking up noise? >> ...... > >Noise? >The addition of two 47pF capacitors from the DP and DM lines to 0V on >many devices removes the problem completely. > 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
From: Bill Davy on 27 Jan 2010 11:50 "Rob1" <r(a)n_o_s_p_a_m.alblas.demon.nl> wrote in message news:dq-dnYaSSs0XwsLWnZ2dnUVZ_vKdnZ2d(a)giganews.com... > >Viktor wrote: >> >>> Could it be that your USB cable is picking up noise? >>> ...... >> >>Noise? >>The addition of two 47pF capacitors from the DP and DM lines to 0V on >>many devices removes the problem completely. >> > > 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 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.
From: Rob1 on 30 Jan 2010 16:45
>"Rob1" <r(a)n_o_s_p_a_m.alblas.demon.nl> wrote in message >> 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.) >> 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 |