FTDI parallel USB chip 245 problem

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