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

Reply to
ted
Loading thread data ...

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.

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:

formatting link

Mark Borgerson

Reply to
Mark Borgerson

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 :/

Reply to
Lewin A.R.W. Edwards

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

Reply to
ted

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

Reply to
Mark Borgerson

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

Reply to
Lasse Langwadt Christensen

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

Reply to
Mark Borgerson

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.