New approach to transfer exact data By FT2232H

Now either data is being repeated or data is being missed, both of which suggest driver or driver handling of transfers has timing issues. Either insufficient buffering, incorrect buffer handling or too bloated (in execution) to handle vagueries of your system.

Alternatively your system is choking.

Still could be the driver, your application, or too low a spec system.

Windows is NOT a real time operating system!

Two things to do while you are transferring correctly your data

a) Click and drag the window with your application about the screen (this also works when playing movies on PCs as they become 'jerky' due to missed frames/lines).

b) Put a known bad/scratched CD (or in some cases a blank CD-R) into your CDROM/DVD drive.

Your application WILL fail to transfer correctly!

Another thing that can show this is to use explorer to browse all computers on your network, with a clash between different systems wanting to be browser master on a workgroup setup.

If you want to GUARANTEE a large data transfer you will need some form of dedicated hardware (possibly larger buffer in your USB device) to do the guaranteed capture of data.

Windows CANNOT guarantee a timed capture of high speed data, and gets worse the larger the dataset size.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

The USB protocol is supposed to allow large transfers without data corruption.

I will not argue that Windows has a lot of room for improvement, but USB transfers of gigabytes of data at megabytes per second can be done accurately if the driver is written properly.

And I do know that the FTDI drivers are not written properly.

AL

Have you discussed it with FTDI?

Often assumes that the data is coming from something like a hard drive where pauses can be coped with. NO USB driver can buffer 10's or 100's MB of continuous data stream in a GUARANTEED manner on ANY windows platform,= =20 because the system is busy with another task, or some other driver like=20 CDROM or graphics is hogging the system.

Timed capture of continuous data streams cannot be guaranteed on ANY windows platform, with ANY driver. Not without sufficient external buffering which also has to be large to cope with ALL situations. =20

It is more likely to be achievable with better drivers, but guaranteeing continuous data streams (timed capture) without external buffering on=20 ANY windows system is impossible. =20

I know and any correspondence/contact them is met with disbelief that anything is wrong at all. They seem to believe everybody has=20 the exact same setup as they have, even their customers' customers.

At best FTDI is good for small data sets on non-continuous data streams, that can be paused. =20

--=20 Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services Timing Diagram Font GNU H8 - compiler & Renesas H8/H8S/H8 Tiny For those web sites you hate

Paul Ham schrieb:

It may be stupid, but it sounds to me like a problem with serial communication from the time before USB. Did you use any handshake between FPGA and FT2232H?

============================================================================

Thanks to your concern. Thanks.

But, actually, I don`t understand tha meaning of HANDSHAKE.

FPGA just send the data only when the TXE# pin becomes active low.

and then, if the TXE# goes to HIGH, FPGA will stop to send the data.

I`ve heard that there must be some delay time after TXE# becomes active low.

So I made FPGA sending the data both immediately and slowly after TXE# becomes low. Its result was same as I saw.

And I am sorry that I didn`t mentioned I used 245 SYNC FIFO MODE with FT2232H

Module.

Paul

Paul Ham schrieb:

Hi Paul,

sorry about my late answer. Handshake means the flow control. I think, you will find it on google. Shortly: Your FPGA sends data, without examining whether the opposite side is still absorptive. On RS232 there are signals to handle this (RTS, CTS), or a software protocol can be used (XON/XOFF), if only RX and TX line are available.

HTH. Michael

Did you solve this problem ? Were you able to identify the time-(or data) separation between the issues ? Did you scope the TXE, to see how much it changes during USB frames, and block boundaries ? Could be useful to know the LONGEST wait time the device signals to the FPGA.

I did see Cypress claiming video streaming, on their CYStream drivers and their FX2 devices ?

-jg

Hi, I have some experience in dealing with FT2232 while programming JTAG adapter software. This may not be your problem but I found that timing is erratic if your transmit timer is set to a low value. This chip has transmit timer that causes data to be transmitted when this timer expires. If it is set too low the chip will initiate usb transaction whether there is a data to transmit or not. If there is no data chip will transmit an empty frame causing a delay until the next frame. If you set timer to higher value - like 10ms the operation of the chip becomes much more predictable.

Regards, Alex

Hi, I'm using a FT2232HQ connected to an Altera Cyclone III. The FTDI chip is in 245 Async mode. I am having the exact same problems: missing bytes or extra bytes and sometimes wrong bytes. I am not stressing the interface (not much data per second, under 100 Kbits), I am respecting the Async mode timings more than the holy cow.

First I tried making a loopback in the FPGA, data came in wrong as described before. Then I just counted up in the FPGA and every time a byte is received, a byte is sent. This led me to two conclusios: the number of bytes received by the FPGA is random and the counter bytes received at the PC are repeated/missing/wrong.

To test this last two and be sure my app wasn't the fault, I used the MS HyperTerminal to "send a text file" so I got the ascii table in front of my eyes continuously and could spot that almost always all the bytes were there but some were wrong, which leads me to believe the problem is RX and my data lines not being read ok (though they are tristated fine).

I am concerned about the voltage levels because I am communicating from

2.5V ports in the FPGA to this 3.3V device and the Voh_min of the FPGA is 2V, which is also Vih_min of the FTDI. This should be just fine, but these problems made me look for anything. The two chips are connected through a 40 pin IDE cable. Maybe some minor variations are making the FTDI chip not see a 1 where there is a 1, or missing bits of data. I don't have the instruments to verify this.

I've even tried applying a low pass filter to the RXF and TXE signals so I wouldn't catch any glitches and it seemed to help (though I am not sure). I overrespected all timings of the async mode and it looked like maybe it helped. Maybe my 2.5V WR and RD lines are glitching from the point of view of the 3.3V FTDI chip? That could explain the extra and the missing bytes.

I am going to try sending 32 bytes at 'A', 31 at 'b', 30 at 'C', and so on alternating cases. If the data signals' voltage levels are the problem then the last letters will show errors (i.e.: X becoming Y or Z, but not y or z).

I am using the serial port always to communicate (not the D2xxx usb drivers). What are you using? I'll try to also use the D2xxx drivers, if something changes in the received data then that's where it was.

Let's share our experiences here, it will lead us to some solution, which there must be. Regards,

Victor

I posted yesterday commenting I had the very same problems (extra/missing/wrong bytes) using FT2232HQ connected to 2.5V ports of Cyclone III FPGA , accessing it at the PC as a serial port, and the mode is

245 Async fifo.

I had tried just sending an incrementing counter from the FPGA to the PC. Today I got it to work, the problem was in the timings of the datasheet, they are terribly wrong as far as I can tell, at least in the Async mode I use. Try using Async mode and tripling the timings, it solved everything. Today I got 5 MBytes/s sustained throughput with 0 errors, perfect transmission (I left it transferring around 10 GB so I think it is reliable enough).

If you want to see my waveforms I invite you to plot them using the DrawTiming tool (google that name), the script for the TX waveform is:

CLK_50MHZ=tick,TXEn=0,WRn=1,DATA=00. DATA=01..WRn=0..TXEn=1......TXEn=0,WRn=1..DATA=02.

If you don't want to use that tool, these are the values in every cycle for the TX of a 00 after XX has been transmitted and before 01 is transmitted (repeating the process done with DATA=00):

TXEn: 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0 WRn: 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1 DATA: XX, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01

My system is a WinXP dual proc running other programs at the same time. If you see the graph it takes 11-12 cycles to get a transfer done, with the 50 MHz clock it adds up to 5MBps throughput so in this case the bottleneck is the FPGA, not the driver nor the PC.

Tomorrow I'll start cutting cycles out to get a TX in less and I'll then go berserk on RX (as I'll have a reliable TX to see what has been received on that end).

Regards everybody,

Victor

le

Can you clarify your setup ? - Does the 2232H clock the FPGA which streams always at 5MB/s, or does the FPGA clock the 2232H, and is paced to deliver always a 5MB/s data rate [and the PC/USB/2232H is able to 'keep up' at this rate, without losing data ?]

-jg