Forums

FTDI parallel USB chip 245 problem

Started by ted December 30, 2003
I am having problems reading a FTDI 245 USB parallel chip into a PC.

In the PC, I am using GetQueueStatus(), which returns the number of
bytes in the rx queue, follwed by a read() which reads the bytes into
a buffer. All within a self contained thread. I am using Microsoft C
V7. The throughput rate is about 500Kbps, about half the maximum
realisable.

The problem is that every few seconds or so the software reads one
extra byte in the stream. This is always the last byte read twice.
Otherwise the stream is read correctly.

As a test rig, the transmitter (i.e. the FTDI module) consists of a
simple CMOS counter to generate data bytes, followed by a simple clock
timer to generate the write pulses (about 100nS wide), all gated by
the txe signals. On the scope all pulse shapes are well within specs,
so it is unlikely to be the transmitter that is generating the "extra
byte"

Any thoughs on solutions, or tests to prove/disprove where the problem
lies??

TIA

ted
In article <c54bf83f.0312301057.6fc69837@posting.google.com>, 
edaudio2000@yahoo.co.uk says...
> I am having problems reading a FTDI 245 USB parallel chip into a PC. > > In the PC, I am using GetQueueStatus(), which returns the number of > bytes in the rx queue, follwed by a read() which reads the bytes into > a buffer. All within a self contained thread. I am using Microsoft C > V7. The throughput rate is about 500Kbps, about half the maximum > realisable. > > The problem is that every few seconds or so the software reads one > extra byte in the stream. This is always the last byte read twice. > Otherwise the stream is read correctly.
I usually suspect the thread manager in cases like this---but then I'm just suspicious of threads in general. I also don't usually let the GetQueueStatus() return value dictate the number of bytes I read. Here is my read loop: ************** while(timeout > 0){ //timeout decremented in timer interrupt len = 200; // request a lot of bytes Application->ProcessMessages(); // catch up on message handling FT_Read(FTH, cp,len, &len); // Read whatever has arrived if(len > 0){ // if data has arrived, advance storage pointer cp += len; //advance buffer pointer timeout = 10; // reset timeout timer } } // end of while(timeout > 0) ************************ With this routine in the foreground loop, I get good data as fast as it can be sent by my embedded controller.
> > As a test rig, the transmitter (i.e. the FTDI module) consists of a > simple CMOS counter to generate data bytes, followed by a simple clock > timer to generate the write pulses (about 100nS wide), all gated by > the txe signals. On the scope all pulse shapes are well within specs, > so it is unlikely to be the transmitter that is generating the "extra > byte" > > Any thoughs on solutions, or tests to prove/disprove where the problem > lies??
I have no similar problems with the FTDI drivers in the main program loop of an unthreaded Borland C++ builder application. I suspect your problem lies in the receiving software or the transmitting hardware. One possibility is that your gating of the write signal may be generating glitches when it coincides with a change in the TXE status. You may need to run TXE and the write clock into a flip-flop to synch the outputs with an external clock so that there are no glitches in the write signal. Finding a glitch that happens only every few minutes is tough with only an oscilloscope. Have you read through the debugging app note at: http://www.ftdichip.com/knowledgebase/AppNotes/002/an232-245b-002.htm Mark Borgerson
> Any thoughs on solutions, or tests to prove/disprove where the problem > lies??
Not that this probably helps you much, but if this was a totally non-critical application, I'd packetize the data, add a retransmit protocol, and watch the errors correct themselves... I distrust USB deeply (mostly because of the layers of software horror on the host side and joyful lack of compliance in the USB world altogether; "if it works with today's version of Windows XP then it must be compliant"), so I figure almost any hack or kludge in a USB data stream is acceptable; the whole thing is kept afloat on a raft of kludges anyway :/
Mark Borgerson <m-a-r-k@oes.to> wrote in message news:<MPG.1a5b8bd6629203be989cea@Netnews.Comcast.net>...
> In article <c54bf83f.0312301057.6fc69837@posting.google.com>, > I have no similar problems with the FTDI drivers in the main program > loop of an unthreaded Borland C++ builder application. I suspect your > problem lies in the receiving software or the transmitting hardware. > One possibility is that your gating of the write signal may be > generating glitches when it coincides with a change in the TXE > status. You may need to run TXE and the write clock into a > flip-flop to synch the outputs with an external clock so that there > are no glitches in the write signal. Finding a glitch that happens > only every few minutes is tough with only an oscilloscope. > > > Have you read through the debugging app note at: > > http://www.ftdichip.com/knowledgebase/AppNotes/002/an232-245b-002.htm > > Mark Borgerson
Thanks Mark for all that! I managed to nearly eliminate the problem by adding a series 22ohm resistor on the wr line. The test TX hardware circuit I used was technically "crystal perfect" as far as I can gather and as seen on a Tek storage 300MHz scope. All signals were properly synchronised (all outputs were latched as you suggested) with plenty of gaps between txen and wr, etc etc and no glitches. So I suspect a timing problem as per specs was not the issue. I can only suspect that the FTDI module (maybe this particular one) is sensitive to wr pulse shape, I admit I saw some tiny -ve going ringing on the original waveform which dissapeared when the series resistor was added. Thanks again ted
In article <c54bf83f.0312311059.344c0c3a@posting.google.com>, 
edaudio2000@yahoo.co.uk says...
> Mark Borgerson <m-a-r-k@oes.to> wrote in message news:<MPG.1a5b8bd6629203be989cea@Netnews.Comcast.net>... > > In article <c54bf83f.0312301057.6fc69837@posting.google.com>, > > I have no similar problems with the FTDI drivers in the main program > > loop of an unthreaded Borland C++ builder application. I suspect your > > problem lies in the receiving software or the transmitting hardware. > > One possibility is that your gating of the write signal may be > > generating glitches when it coincides with a change in the TXE > > status. You may need to run TXE and the write clock into a > > flip-flop to synch the outputs with an external clock so that there > > are no glitches in the write signal. Finding a glitch that happens > > only every few minutes is tough with only an oscilloscope. > > > > > > Have you read through the debugging app note at: > > > > http://www.ftdichip.com/knowledgebase/AppNotes/002/an232-245b-002.htm > > > > Mark Borgerson > > > Thanks Mark for all that! > > I managed to nearly eliminate the problem by adding a series 22ohm > resistor on the wr line. > > The test TX hardware circuit I used was technically "crystal perfect" > as far as I can gather and as seen on a Tek storage 300MHz scope. All > signals were properly synchronised (all outputs were latched as you > suggested) with plenty of gaps between txen and wr, etc etc and no > glitches. So I suspect a timing problem as per specs was not the > issue. > > I can only suspect that the FTDI module (maybe this particular one) is > sensitive to wr pulse shape, I admit I saw some tiny -ve going ringing > on the original waveform which dissapeared when the series resistor > was added. > > Thanks again
I've heard of ringing and ground bounce problems where the problem was related to the data pattern on the input lines. Does your data duplication always occur when you have the same pattern on the data lines?? Good, solid grounds and ground plane and some attention to PCB layout may be necessary if the problem persists. If you're using a counter to generate the data, watch out for current spikes as the counter goes from 0xFF to 0x00. On my last design with the FTDI 245, I had series resistors on all the data and control lines. This was not only to avoid ringing, but to provide some port protection for my processor. Since the USB circuit is powered off the USB bus, it could be active when the processor is unpowered, or vice versa. It's the latter case that was of concern. When the USB is not plugged in, the processor senses the +5V level and, if zero, sets the data lines to inputs. In the microseconcds before it can do that, the resistors limit the current if the CPU is trying to drive the USB data port. Mark Borgerson
ted wrote:
> I am having problems reading a FTDI 245 USB parallel chip into a PC. > > In the PC, I am using GetQueueStatus(), which returns the number of > bytes in the rx queue, follwed by a read() which reads the bytes into > a buffer. All within a self contained thread. I am using Microsoft C > V7. The throughput rate is about 500Kbps, about half the maximum > realisable. > > The problem is that every few seconds or so the software reads one > extra byte in the stream. This is always the last byte read twice. > Otherwise the stream is read correctly. > > As a test rig, the transmitter (i.e. the FTDI module) consists of a > simple CMOS counter to generate data bytes, followed by a simple clock > timer to generate the write pulses (about 100nS wide), all gated by > the txe signals. On the scope all pulse shapes are well within specs, > so it is unlikely to be the transmitter that is generating the "extra > byte" > > Any thoughs on solutions, or tests to prove/disprove where the problem > lies?? > > TIA > > ted
I've just had the same problem, playing around with resistors on the signals in case it was glitches didn't help. Then I added an extra ~41ns(24MHz clock) delay from TxF going low to the write pulse and the problem went away. (no errors in a few gigabytes at ~750kbyte/sec) I don't think the datasheet specifies a minimum time. -Lasse
In article <402042E1.9090900@ieee.org>, langwadt@ieee.org says...
> ted wrote: > > I am having problems reading a FTDI 245 USB parallel chip into a PC. > > > > In the PC, I am using GetQueueStatus(), which returns the number of > > bytes in the rx queue, follwed by a read() which reads the bytes into > > a buffer. All within a self contained thread. I am using Microsoft C > > V7. The throughput rate is about 500Kbps, about half the maximum > > realisable. > > > > The problem is that every few seconds or so the software reads one > > extra byte in the stream. This is always the last byte read twice. > > Otherwise the stream is read correctly. > > > > As a test rig, the transmitter (i.e. the FTDI module) consists of a > > simple CMOS counter to generate data bytes, followed by a simple clock > > timer to generate the write pulses (about 100nS wide), all gated by > > the txe signals. On the scope all pulse shapes are well within specs, > > so it is unlikely to be the transmitter that is generating the "extra > > byte" > > > > Any thoughs on solutions, or tests to prove/disprove where the problem > > lies?? > > > > TIA > > > > ted > > I've just had the same problem, playing around with resistors on the > signals in case it was glitches didn't help. > Then I added an extra ~41ns(24MHz clock) delay from TxF going low to > the write pulse and the problem went away. (no errors in a few gigabytes > at ~750kbyte/sec) I don't think the datasheet specifies a minimum time. >
Interesting observation! The '245 generates an internal 48MHz clock by multiplying the 6MHz resonator frequency. Perhaps it needs a few of those clock cycles to transition from the TXF state to the Ready-for-data state. That would also explain why I never saw the problem. I check the transition of TXF on a 68K system at 16MHz, and there's no way I'm going to be presenting data in less than about 4 clock cycles, or 250nSec., after the transition. Mark Borgerson